From report at bugs.python.org  Sat Nov  1 00:00:11 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Oct 2014 23:00:11 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414796411.74.0.291234573162.issue22725@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The first argument of enumerate is 'iterable' in the 2.7 docstring also.

"enumerate(iterable[, start]) -> iterator for index, value of iterable

Return an enumerate object.  iterable must be another object that supportsniteration.  The enumerate object yields pairs containing a count (from\nstart, which defaults to zero) and a value yielded by the iterable argument.  enumerate is useful for obtaining an indexed list:   (0, seq[0]), (1, seq[1]), (2, seq[2]), ..."

We should update at least that part of the doc entry.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 3.6

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

From report at bugs.python.org  Sat Nov  1 00:01:19 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Oct 2014 23:01:19 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1414796479.41.0.0207054088675.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Nevertheless, that is the behavior if NotImplemented is returned by a method.  Here's some code to demonstrate:

--8<---------------------------------------
from collections import Counter

class Spam(int):
    "for sake of example"
    def __radd__(self, other):
        other[self] = other[self] + 1
        return other

s = Spam(5)
c = Counter()
print(c)
c += s
print(c)
c += 9
--8<---------------------------------------

before the patch
-------------------------------------------
Counter()
Traceback (most recent call last):
  File "blah.py", line 13, in <module>
    c += s
  File "/home/ethan/source/python/issue20284/Lib/collections/__init__.py", line 738, in __iadd__
    for elem, count in other.items():
AttributeError: 'Spam' object has no attribute 'items'
-------------------------------------------

after the patch
-------------------------------------------
Counter()
Counter({5: 1})
Traceback (most recent call last):
  File "blah.py", line 13, in <module>
    c += 9
TypeError: unsupported operand type(s) for +=: 'Counter' and 'int'
-------------------------------------------

As you can see, we get better support for other objects that know how to add themselves to the container in question, and a nicer and more correct error message for objects that do not.

As I said earlier, the only decision we should have to make here is whether to check for a Counter, or just something with a .items attribute, but either way we should be returning NotImplemented.

----------

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

From report at bugs.python.org  Sat Nov  1 00:06:14 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 31 Oct 2014 23:06:14 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1414796774.98.0.326325970198.issue22766@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, it's true that the message is better. If we don't want to change behaviour, we should simply catch the AttributeError and return NotImplemented from there.

----------

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

From report at bugs.python.org  Sat Nov  1 00:07:29 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Oct 2014 23:07:29 +0000
Subject: [issue22737] Provide a rejected execution model and implementations
 for futures.
In-Reply-To: <1414377539.49.0.348706562954.issue22737@psf.upfronthosting.co.za>
Message-ID: <1414796849.96.0.926137571118.issue22737@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  1 00:11:11 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Oct 2014 23:11:11 +0000
Subject: [issue22780] NotImplemented doc section needs update
Message-ID: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>


New submission from Ethan Furman:

https://docs.python.org/3/library/constants.html

current
-------
    Special value which can be returned by the ?rich comparison? special methods (__eq__(), __lt__(), and friends), to indicate that the comparison is not implemented with respect to the other type.


more accurate
-------------
    Special value which should be returned by the __dunder__ methods to indicate the requested operation is not implemented with respect to the other type.

----------
messages: 230412
nosy: eric.araujo, ethan.furman, ezio.melotti, georg.brandl
priority: normal
severity: normal
stage: needs patch
status: open
title: NotImplemented doc section needs update

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

From report at bugs.python.org  Sat Nov  1 00:47:49 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Oct 2014 23:47:49 +0000
Subject: [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414799269.66.0.880149902051.issue22738@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On Win7, current Firefox, '-c' looks the same (definitely lowercase) for 2.7,8, 3.4.2, and 3.5.0a0,

I agree both that the sys.argv entry should be left as is and that 'interpret' is better than 'feed' or the current verbiage.  I think 'cmd' should be left as is because it is more descriptive than the generic 'str' and because the latter implies to me that cmd must always (as opposed to often) be quoted, which is not true.  The result would be
  -c cmd : interpret cmd as a program (terminates option list)

For 3.5, the current line is repository\Modules\main.c: 55.  If we agree on the above, I am willing to make the patch and push it.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.4

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

From report at bugs.python.org  Sat Nov  1 00:49:13 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 31 Oct 2014 23:49:13 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <20141031234903.111408.70936@psf.io>


Roundup Robot added the comment:

New changeset 26d0a17affb5 by Ethan Furman in branch 'default':
issue22780: update NotImplemented description
https://hg.python.org/cpython/rev/26d0a17affb5

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

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

From report at bugs.python.org  Sat Nov  1 00:50:56 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Oct 2014 23:50:56 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1414799456.37.0.992428944904.issue22780@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.5

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

From report at bugs.python.org  Sat Nov  1 01:13:49 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 00:13:49 +0000
Subject: [issue22739] "There is no disk in the drive" error
In-Reply-To: <1414392827.56.0.571948062757.issue22739@psf.upfronthosting.co.za>
Message-ID: <1414800829.15.0.277547673501.issue22739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Lachian, I am closing this because I agree with Tim.  This tracker is for bug fixes (and enhancements) to the code at hg.python.org/cpython (and a couple of the sibling repositories). Bugs need to be demonstrated with a .py or .c program. This is almost certain a bug somewhere else. In the meanwhile, this report will remain here and be searchable.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Nov  1 01:36:20 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 00:36:20 +0000
Subject: [issue22742] IDLE shows traceback when printing non-BMP character
In-Reply-To: <1414426704.85.0.168243800807.issue22742@psf.upfronthosting.co.za>
Message-ID: <1414802180.08.0.0386772209739.issue22742@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think Idle should consistently display astral chars with their \U escape.  It sometimes does, just not always.

>>> s='\U0001f680'
>>> s
'\U0001f680'
>>> str(s)
'\U0001f680'
>>> repr(s)
"'\U0001f680'"
>>> print(s) # gives error above.
>>> print(str(s))  #ditto

I thought that implicit print of expression and overt print of the same expression were supposed to be the same.

#21084 is also about this general issue.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  1 01:50:19 2014
From: report at bugs.python.org (Michael Kuss)
Date: Sat, 01 Nov 2014 00:50:19 +0000
Subject: [issue22701] Write unescaped unicode characters (Japanese, Chinese,
 etc) in JSON module when "ensure_ascii=False"
In-Reply-To: <1414004123.6.0.971106689488.issue22701@psf.upfronthosting.co.za>
Message-ID: <1414803019.42.0.300527124369.issue22701@psf.upfronthosting.co.za>


Michael Kuss added the comment:

Pardon the delay - this json dump function is embedded in a much larger script, so it took some untangling to get it running on Python 3.3, and scrub some personal identifying info from it. This script also does not work in Python 3.3:


  File "C:/Users/mkuss/PycharmProjects/TestJSON\dump_list_to_json_file.py", line 319, in dump_list_to_json_file
    json.dump(addresses, outfile, indent=4, separators=(',', ': '))
  File "C:\Python33\lib\json\__init__.py", line 184, in dump
    fp.write(chunk)
TypeError: 'str' does not support the buffer interface



In python 2.7, I still get escaped unicode when I try writing this dictionary using json.dump, so the work-around that I pasted originally is how I'm choosing to accomplish the task for now.

I'd you'd like, I can spend more time debugging this issue I'm running into running the script in python 3.3, but it maybe be til next week when I have sufficient time to solve. THANKS  --mike

----------
status: pending -> open

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

From report at bugs.python.org  Sat Nov  1 01:50:36 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 00:50:36 +0000
Subject: [issue22761] Catching StopIteraion inside list comprehension
In-Reply-To: <1414617541.45.0.218818215506.issue22761@psf.upfronthosting.co.za>
Message-ID: <1414803036.51.0.245023213468.issue22761@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  1 02:04:22 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 01:04:22 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414803862.16.0.552820399567.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The "sequence" parameter name is an unfortunate hold-over from olden times were many things that accepted iterables were marked as taking sequences.

This was fixed in Python 3, but it can't be changed in Py2.7 because the parameter name is exposed as a keyword argument:

    >>> list(enumerate(sequence='abc', start=2))
    [(2, 'a'), (3, 'b'), (4, 'c')]

The rest docs for Python 2.7 read just fine, "Return an enumerate object. sequence must be a sequence, an iterator, or some other object which supports iteration."   I think that is sufficient to clarify any confusion caused by the unfortunate choice of keyword argument name.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  1 02:29:58 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 01:29:58 +0000
Subject: [issue22761] Catching StopIteraion inside generator expression.
In-Reply-To: <1414617541.45.0.218818215506.issue22761@psf.upfronthosting.co.za>
Message-ID: <1414805398.05.0.680606685635.issue22761@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(One copy of a message is enough; I unlinked the duplicate.)

I am not sure what you mean by you initial sentence, but I do not think it is correct.  In any case, "next(it) for it in iters" is a generator expression, not a list comprehension. The tuple call swallows the StopIteration, so the behavior is correct.

If you want to discuss further, please ask on python-list, also accessible at news.gmane.com either as a web page or as newsgroup gmane.comp.python.general.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Catching StopIteraion inside list comprehension -> Catching StopIteraion inside generator expression.

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

From report at bugs.python.org  Sat Nov  1 02:32:48 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 01:32:48 +0000
Subject: [issue22763] load_tests chaining into discover from non-discover
 entry point gets top_level_dir wrong
In-Reply-To: <1414638787.38.0.74873076868.issue22763@psf.upfronthosting.co.za>
Message-ID: <1414805568.62.0.866718969549.issue22763@psf.upfronthosting.co.za>


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


----------
components: +Tests
stage:  -> test needed
versions: +Python 3.5

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

From report at bugs.python.org  Sat Nov  1 02:42:29 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 01:42:29 +0000
Subject: [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414806149.17.0.411293917606.issue22738@psf.upfronthosting.co.za>


R. David Murray added the comment:

I am hard pressed to come up with anything useful you can do with the argument to -c without quoting it.

----------

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

From report at bugs.python.org  Sat Nov  1 02:47:03 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 01:47:03 +0000
Subject: [issue22701] Write unescaped unicode characters (Japanese, Chinese,
 etc) in JSON module when "ensure_ascii=False"
In-Reply-To: <1414004123.6.0.971106689488.issue22701@psf.upfronthosting.co.za>
Message-ID: <1414806423.18.0.954565600435.issue22701@psf.upfronthosting.co.za>


R. David Murray added the comment:

That error message indicates you've opened the output file in binary mode instead of text mode.

----------

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

From report at bugs.python.org  Sat Nov  1 02:57:52 2014
From: report at bugs.python.org (Cormac O'Brien)
Date: Sat, 01 Nov 2014 01:57:52 +0000
Subject: [issue20069] Add unit test for os.chown
In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za>
Message-ID: <1414807072.47.0.396301975515.issue20069@psf.upfronthosting.co.za>


Cormac O'Brien added the comment:

The unit test has changed significantly since R. David Murray posted his suggestions, but I've at least moved the test over to the new format as noted in the last comment of the v5 patch.

----------
nosy: +cormac-obrien
Added file: http://bugs.python.org/file37093/unittest_os_main.patch

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

From report at bugs.python.org  Sat Nov  1 02:58:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 01:58:05 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414807085.64.0.782853064601.issue22725@psf.upfronthosting.co.za>


R. David Murray added the comment:

We have a suggestion for a wording improvement (that does not change the sentence to which you refer) that has been accepted as better than the existing wording by a couple of committers.  This improvement is actually independent of what the variable is named.  The 2.7 docstring should also be fixed to show the actual argument name, IMO.

----------
resolution: rejected -> 
status: closed -> open
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  1 03:06:08 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 02:06:08 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1414807568.51.0.240262856668.issue22780@psf.upfronthosting.co.za>


R. David Murray added the comment:

The replacement of the term  'special methods' and the examples with the jargon (used nowhere else in the docs that I'm aware of) of '__dunder__' makes the text very confusing.  Please restore 'special methods' and the examples...you could include non-comparision methods in the list of examples.

Oh, I see, you use __dunder__ in the enum docs as well.  It should be replaced with our standard terminology there, as well.

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

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

From report at bugs.python.org  Sat Nov  1 03:17:36 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 02:17:36 +0000
Subject: [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414808256.63.0.793124281436.issue22738@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Semi-useful: print a numeric expression without spaces
C:\Users\Terry>python -c print(2**50)
1125899906842624

Less useful: print a string expression without spaces or double quotes
C:\Users\Terry>python -c print('*'*50)
**************************************************

----------

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

From report at bugs.python.org  Sat Nov  1 03:35:33 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 02:35:33 +0000
Subject: [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414809333.0.0.042596981548.issue22738@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  Those don't work in my shell, since the '*' gets interpreted as a globbing character.  I didn't know it worked on Windows.

----------

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

From report at bugs.python.org  Sat Nov  1 04:28:40 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 03:28:40 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414812520.56.0.445006650142.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Can you attach a proposed patch and I will make a decision.  

FWIW, I'm very happy with the current documentation at https://docs.python.org/2.7/library/functions.html#enumerate  Between the text, example, and pure python equivalent, it does a great job communicating what enumerate is supposed to do.

Proposed improvements to the docstring should match the main documentation as much as possible.

----------

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

From report at bugs.python.org  Sat Nov  1 04:41:42 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 03:41:42 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1414813302.76.0.350223379869.issue22609@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/issue22609>
_______________________________________

From report at bugs.python.org  Sat Nov  1 05:18:47 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 01 Nov 2014 04:18:47 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1414815527.66.0.905029416517.issue22417@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

New version of the patch based on feedback from benjamin, should make it easier to do the 3.4 branch stuff.

----------
Added file: http://bugs.python.org/file37094/issue22417.diff

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

From report at bugs.python.org  Sat Nov  1 07:42:44 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 06:42:44 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1414824164.74.0.662213033475.issue22766@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry, I don't want to change the kind of exception being raised (an API change from AttributeError to TypeError) without a really good reason.

In general, in-place methods are not required to return NotImplemented (for example, (3).__iadd__(4.5) raises an AttributeError).

Also, I prefer the current AttributeError with its clear indication that an items() method is needed for duck-typing.  These kind of error messages are very helpful when you're trying to figure-out how to duck-type on-purpose (for example, {}.update(1) and {}.update([[]]) both provide the information about what you would need to do to get update() to work).

The current duck-typeable behavior was an intended part of the design and is no different from a number of other methods that update in-place.

FWIW, I do recognize that in the specific case of "counter += 1" a TypeError is clearer than an AttributeError.  However, for duck-typeable methods, an AttributeError can sometimes be useful to indicate what is actually being required of the "other" argument (for example, Python 2 old-style classes raise an AttributeError with an informative message when calling an instance without a __call__ method or indexing an instance without a __getitem__ method).

At any rate, I want to avoid unnecessary API churn (and avoid contributing to what Guido has called "a death by a thousand cuts" for the growing list of tiny semantic differences between Python 2 and Python 3).

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

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

From report at bugs.python.org  Sat Nov  1 08:08:57 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 07:08:57 +0000
Subject: [issue22755] contextlib.closing documentation should use a new example
In-Reply-To: <1414536052.52.0.0865505363528.issue22755@psf.upfronthosting.co.za>
Message-ID: <1414825737.94.0.227075206231.issue22755@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Can a different example be chosen?

The traditional examples (urllib, socket, StringIO) grow context manager support as soon as the need becomes apparent.  So, that leaves only user-defined classes, third-party classes, generators, and cases where we already have a competing context manager that does something other than close.

A reasonable candidate is an sqlite connection.  It is a legitimate use case for contextlib.closing() since connections need to be closed after use, and because they already are context managers that do something different than closing (the commit or rollback transactions).

A generator example would work, but closing generators is a rare and esoteric need (not many people even realize than you *can* close a generator), so this would make a bad example.

A user defined class can add its own __enter__ and __exit__ to close if needed, so it isn't common to use contextlib.closing() on your own classes.   The primary use case is for third-party classes where you don't control the source code and a closing context manager isn't present; however, those make for bad examples because they aren't in the standard library (i.e. aren't familiar) and because the better maintained modules are also adding context manager support.

Out of all of these, only the sqlite connection example seems to be durable (won't go away) and familiar (in the standard library and not an exotic feature).

That said, I think it would be best to stick with the simplest and most familiar possible examples even if they are no longer needed.   The purpose of the example is to show how closing() works.  We can use the surrounding text to indicate that the example is no longer necessary and that the most common remain uses are to add closing() behavior to third-party code you don't control (if you do control the code, then adding CM support directly to the class would be preferable).

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sat Nov  1 08:11:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 07:11:18 +0000
Subject: [issue22721] pprint output for sets and dicts is not stable
In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za>
Message-ID: <1414825878.82.0.819764031498.issue22721@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger
versions:  -Python 3.4

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

From report at bugs.python.org  Sat Nov  1 08:20:23 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 07:20:23 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1414826423.96.0.732452235239.issue21650@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

To me, "--unsorted" implies arbitrary ordering such as the order generated by regular dictionaries.  I think the option should be "--order-preserving" or some such.  The option name needs to make it clear that the output is in the same order an the input.

As side from the option name, I'm +1 on the patch.  It is very annoying to look at scrambled JSON when the original presentation order made more logical sense.

----------

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

From report at bugs.python.org  Sat Nov  1 09:02:13 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 08:02:13 +0000
Subject: [issue22718] pprint not handline uncomparable dictionary keys,
 set members well
In-Reply-To: <1414165649.11.0.50429325469.issue22718@psf.upfronthosting.co.za>
Message-ID: <1414828933.91.0.754692955962.issue22718@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Complex numbers also aren't sortable.

> I'm not sure this is worth fixing in 2.7.

I agree.  That ship sailed a long time ago.

----------
nosy: +rhettinger
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sat Nov  1 09:12:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 08:12:02 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1414829522.71.0.617381879665.issue21650@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be make sorting keys not default?

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

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

From report at bugs.python.org  Sat Nov  1 09:16:33 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 08:16:33 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1414829793.46.0.812397711089.issue21650@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Maybe make sorting keys not default?

If you mean preserve order by default, then yes that would be a nice default.

----------

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

From report at bugs.python.org  Sat Nov  1 09:17:44 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 08:17:44 +0000
Subject: [issue22721] pprint output for sets and dicts is not stable
In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za>
Message-ID: <1414829864.97.0.142661664331.issue22721@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> fdrake

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

From report at bugs.python.org  Sat Nov  1 09:23:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 08:23:42 +0000
Subject: [issue22777] Test pickling with all protocols
In-Reply-To: <1414793093.86.0.888366361477.issue22777@psf.upfronthosting.co.za>
Message-ID: <1414830222.17.0.173214662653.issue22777@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed two bugs found by Antoine. Thank you Antoine.

Berker suggest to use the subTest() context manager inside loops. I thought about this, but this will increase blocks indentations on yet 4 spaces, and some code already is too indented. On other hand this truly helps when tests fail.

Large part of the patch is related to the code maintained by Raymond (collections and itertools modules, builtin collections and iterators), so it would be good if Raymond will look on it.

----------
Added file: http://bugs.python.org/file37095/tests_pickling_2.patch

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

From report at bugs.python.org  Sat Nov  1 09:39:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 08:39:28 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1414831168.39.0.672578615996.issue22775@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Test pickling with all protocols (see issue22777), not only with HIGHEST_PROTOCOL.

----------

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

From report at bugs.python.org  Sat Nov  1 09:46:04 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 08:46:04 +0000
Subject: [issue6623] Lib/ftplib.py Netrc class should be removed.
In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>
Message-ID: <20141101084600.101694.34755@psf.io>


Roundup Robot added the comment:

New changeset ec196a99af8d by Berker Peksag in branch 'default':
Issue #6623: Remove deprecated Netrc class in the ftplib module.
https://hg.python.org/cpython/rev/ec196a99af8d

----------

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

From report at bugs.python.org  Sat Nov  1 09:52:37 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Nov 2014 08:52:37 +0000
Subject: [issue6623] Lib/ftplib.py Netrc class should be removed.
In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>
Message-ID: <1414831957.3.0.40428751102.issue6623@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Matt. Have you signed a contributor's agreement? You can find it at https://www.python.org/psf/contrib/contrib-form/

----------
assignee:  -> berker.peksag
priority: release blocker -> normal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Nov  1 09:57:51 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Nov 2014 08:57:51 +0000
Subject: [issue22665] shutil.__all__ incomplete
In-Reply-To: <1413609253.18.0.504077117345.issue22665@psf.upfronthosting.co.za>
Message-ID: <1414832271.85.0.679839923113.issue22665@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with Martin. Plus, this method already used by other tests (see Lib/test/test_nntplib.py and Lib/test/test_warnings.py for example).

----------

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

From report at bugs.python.org  Sat Nov  1 10:05:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 09:05:43 +0000
Subject: [issue22665] shutil.__all__ incomplete
In-Reply-To: <1413609253.18.0.504077117345.issue22665@psf.upfronthosting.co.za>
Message-ID: <20141101090538.109262.35098@psf.io>


Roundup Robot added the comment:

New changeset 232520144c6c by Berker Peksag in branch '3.4':
Issue #22665: Add missing get_terminal_size and SameFileError to shutil.__all__.
https://hg.python.org/cpython/rev/232520144c6c

New changeset 193ac288bc7f by Berker Peksag in branch 'default':
Issue #22665: Add missing get_terminal_size and SameFileError to shutil.__all__.
https://hg.python.org/cpython/rev/193ac288bc7f

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

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

From report at bugs.python.org  Sat Nov  1 10:06:38 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Nov 2014 09:06:38 +0000
Subject: [issue22665] shutil.__all__ incomplete
In-Reply-To: <1413609253.18.0.504077117345.issue22665@psf.upfronthosting.co.za>
Message-ID: <1414832797.99.0.398411356929.issue22665@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Martin.

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

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

From report at bugs.python.org  Sat Nov  1 10:12:08 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 01 Nov 2014 09:12:08 +0000
Subject: [issue20069] Add unit test for os.chown
In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za>
Message-ID: <1414833128.69.0.175544253764.issue20069@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch based on R. David Murray's review. Thanks!

Thanks also for the work of Cormac O'Brien.

----------
Added file: http://bugs.python.org/file37096/add_unit_test_os_chown_v6.patch

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

From report at bugs.python.org  Sat Nov  1 10:54:55 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Nov 2014 09:54:55 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1414835695.69.0.604987022048.issue19610@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Updated patch. I've tweaked tests and documentation a bit. Alternatively, I can leave Doc/distutils/setupscript.rst untouched and add a whatsnew entry to Doc/whatsnew/3.5.rst.

----------
Added file: http://bugs.python.org/file37097/issue19610_v2.diff

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

From report at bugs.python.org  Sat Nov  1 10:57:38 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 01 Nov 2014 09:57:38 +0000
Subject: [issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on
 OS X when run with regrtest -j option
In-Reply-To: <1414710344.61.0.884489180713.issue22770@psf.upfronthosting.co.za>
Message-ID: <1414835858.31.0.373937885209.issue22770@psf.upfronthosting.co.za>


Ned Deily added the comment:

Ah, Issue18604! Thanks for the reminder (and for the patch), Serhly! Focusing on these more recent occurrences of segfaults, I hadn't been thinking about those earlier ones.  Now, after digging into Tk and identifying the problem there, it's clear that those earlier segfaults reported in Issue18604 were a result of the same Tk bug, just caused slightly differently from the tkinter tests.  The #18604 changes also caused a Tcl interpreter instance to be created and destroyed without actually causing Tk to do enough to cause the "open application" Apple event to be fired and received. _is_gui_available is the right place and adding the additional Tk activity there does it at the right time.  And it appears that root.update() is sufficient, as you suggested.  I want to do some additional testing but, assuming no problems are found, I'll plan to apply the simplified patch.

----------
assignee:  -> ned.deily
stage:  -> patch review

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

From report at bugs.python.org  Sat Nov  1 11:16:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 10:16:18 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
 lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1414836978.27.0.251053108041.issue12458@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is yet one example.

x = 1; y = 0; z = 0
(
    1/x +
    1/y +
    1/z
)

The traceback looks correct:

Traceback (most recent call last):
  File "1.py", line 4, in <module>
    1/y +
ZeroDivisionError: division by zero

But for following code:

x = 0; y = 1; z = 0
(
    1/x +
    1/y +
    1/z
)

the traceback is the same and it is totally wrong.

This is because generated bytecode is:

  1           0 LOAD_CONST               0 (0)
              3 STORE_NAME               0 (x)
              6 LOAD_CONST               1 (1)
              9 STORE_NAME               1 (y)
             12 LOAD_CONST               0 (0)
             15 STORE_NAME               2 (z)

  4          18 LOAD_CONST               1 (1)
             21 LOAD_NAME                0 (x)
             24 BINARY_TRUE_DIVIDE
             25 LOAD_CONST               1 (1)
             28 LOAD_NAME                1 (y)
             31 BINARY_TRUE_DIVIDE
             32 BINARY_ADD

  5          33 LOAD_CONST               1 (1)
             36 LOAD_NAME                2 (z)
             39 BINARY_TRUE_DIVIDE
             40 BINARY_ADD
             41 POP_TOP
             42 LOAD_CONST               2 (None)
             45 RETURN_VALUE

1/x and 1/y have the same line number.

----------

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

From report at bugs.python.org  Sat Nov  1 14:08:13 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 13:08:13 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1414847293.32.0.796871274907.issue22766@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with Raymond about the value of the more specific error message.  And the point about the in-place operators being qualitatively different from the non-inplace operators is a good one.

----------

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

From report at bugs.python.org  Sat Nov  1 15:25:01 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 01 Nov 2014 14:25:01 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1414851901.72.0.0877329722913.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Here's the actual change:

+   Special value which should be returned by the special methods
+   (:meth:`__eq__`, :meth:`__lt__`, :meth:`__add__`, etc.) to indicate
+   that the operation is not implemented with respect to the other type.

I'll update the Enum docs as well.

----------

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

From report at bugs.python.org  Sat Nov  1 15:25:27 2014
From: report at bugs.python.org (Dmitry Sivachenko)
Date: Sat, 01 Nov 2014 14:25:27 +0000
Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol
 "ffi_call_win32"
In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za>
Message-ID: <1414851927.99.0.979293194703.issue22521@psf.upfronthosting.co.za>


Dmitry Sivachenko added the comment:

On modern FreeBSD version (10/stable) on i386 arch it fails with the following error:
build/temp.freebsd-10.0-RELEASE-p10-i386-3.4/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `.LBB4_4':
/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.c:(.text+0x661): undefined reference to `ffi_closure_THISCALL'
build/temp.freebsd-10.0-RELEASE-p10-i386-3.4/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `.LBB4_3':
/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.c:(.text+0x673): undefined reference to `ffi_closure_FASTCALL'
build/temp.freebsd-10.0-RELEASE-p10-i386-3.4/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.o: In function `.LBB4_5':
/usr/ports/lang/python34/work/Python-3.4.2/Modules/_ctypes/libffi/src/x86/ffi.c:(.text+0x685): undefined reference to `ffi_closure_STDCALL'
/usr/bin/ld: build/lib.freebsd-10.0-RELEASE-p10-i386-3.4/_ctypes.so: hidden symbol `ffi_closure_FASTCALL' isn't defined

There is no such a problem on amd64.

--with-system-ffi it works fine (system libffi is the same version: 3.0.13)

----------
nosy: +Dmitry.Sivachenko

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

From report at bugs.python.org  Sat Nov  1 15:54:07 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 01 Nov 2014 14:54:07 +0000
Subject: [issue19031] Make help() enum aware
In-Reply-To: <1379289794.97.0.994378932185.issue19031@psf.upfronthosting.co.za>
Message-ID: <1414853647.54.0.0772042814667.issue19031@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Closing this as a duplicate of issue19404.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Simplify per-instance control of help() output

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

From report at bugs.python.org  Sat Nov  1 16:27:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 15:27:02 +0000
Subject: [issue14260] re.groupindex is available for modification and
 continues to work, having incorrect data inside it
In-Reply-To: <1413299625.77.0.485523981054.issue14260@psf.upfronthosting.co.za>
Message-ID: <3566304.kqLxnvgyWk@raxxla>


Serhiy Storchaka added the comment:

Here are two patches which implement two alternative solutions. They are based on regex code.

Dict copying patch matches current regex behavior and needs modifying other code to avoid small slowdown. Artificial example:

$ ./python -m timeit -s 'import re; n = 100; m = re.match("".join("(?P<g%d>.)" % g for g in range(n)), "x" * n); t = ",".join(r"\g<g%d>" % g for g in range(n))' -- 'm.expand(t)'

Without patch: 7.48 msec per loop
With re_groupindex_copy.patch but without modifying _expand: 9.61 msec per loop
With re_groupindex_copy.patch and with modifying _expand: 7.41 msec per loop

While stdlib code can be modified, this patch can cause small slowdown of some third-party code.

Dict proxying patch has no performance effect, but it is slightly less compatible. Some code can accept dict but not dict-like object.

----------
keywords: +patch
Added file: http://bugs.python.org/file37098/re_groupindex_copy.patch
Added file: http://bugs.python.org/file37099/re_groupindex_proxy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14260>
_______________________________________
-------------- next part --------------
diff -r 193ac288bc7f Lib/csv.py
--- a/Lib/csv.py	Sat Nov 01 11:05:36 2014 +0200
+++ b/Lib/csv.py	Sat Nov 01 16:58:33 2014 +0200
@@ -231,20 +231,21 @@ class Sniffer:
         quotes = {}
         delims = {}
         spaces = 0
+        groupindex = regexp.groupindex
         for m in matches:
-            n = regexp.groupindex['quote'] - 1
+            n = groupindex['quote'] - 1
             key = m[n]
             if key:
                 quotes[key] = quotes.get(key, 0) + 1
             try:
-                n = regexp.groupindex['delim'] - 1
+                n = groupindex['delim'] - 1
                 key = m[n]
             except KeyError:
                 continue
             if key and (delimiters is None or key in delimiters):
                 delims[key] = delims.get(key, 0) + 1
             try:
-                n = regexp.groupindex['space'] - 1
+                n = groupindex['space'] - 1
             except KeyError:
                 continue
             if m[n]:
diff -r 193ac288bc7f Lib/sre_parse.py
--- a/Lib/sre_parse.py	Sat Nov 01 11:05:36 2014 +0200
+++ b/Lib/sre_parse.py	Sat Nov 01 16:58:33 2014 +0200
@@ -783,6 +783,7 @@ def parse_template(source, pattern):
             del literal[:]
         groups.append((len(literals), index))
         literals.append(None)
+    groupindex = pattern.groupindex
     while True:
         this = sget()
         if this is None:
@@ -806,7 +807,7 @@ def parse_template(source, pattern):
                     if not name.isidentifier():
                         raise error("bad character in group name")
                     try:
-                        index = pattern.groupindex[name]
+                        index = groupindex[name]
                     except KeyError:
                         msg = "unknown group name: {0!r}".format(name)
                         raise IndexError(msg)
diff -r 193ac288bc7f Lib/test/test_re.py
--- a/Lib/test/test_re.py	Sat Nov 01 11:05:36 2014 +0200
+++ b/Lib/test/test_re.py	Sat Nov 01 16:58:33 2014 +0200
@@ -493,6 +493,13 @@ class ReTests(unittest.TestCase):
         self.assertEqual(re.match("(a)", "a").regs, ((0, 1), (0, 1)))
         self.assertTrue(re.match("(a)", "a").re)
 
+        # Issue 14260.
+        p = re.compile(r'abc(?P<n>def)')
+        self.assertEqual(sorted(p.groupindex), ["n"])
+        self.assertEqual(p.groupindex["n"], 1)
+        p.groupindex["n"] = 0
+        self.assertEqual(p.groupindex["n"], 1)
+
     def test_special_escapes(self):
         self.assertEqual(re.search(r"\b(b.)\b",
                                    "abcd abc bcd bx").group(1), "bx")
diff -r 193ac288bc7f Modules/_sre.c
--- a/Modules/_sre.c	Sat Nov 01 11:05:36 2014 +0200
+++ b/Modules/_sre.c	Sat Nov 01 16:58:33 2014 +0200
@@ -1371,12 +1371,24 @@ static PyMethodDef pattern_methods[] = {
     {NULL, NULL}
 };
 
+/* PatternObject's 'groupindex' method. */
+static PyObject *
+pattern_groupindex(PatternObject *self)
+{
+    return PyDict_Copy(self->groupindex);
+}
+
+static PyGetSetDef pattern_getset[] = {
+    {"groupindex", (getter)pattern_groupindex, (setter)NULL,
+      "A dictionary mapping group names to group numbers."},
+    {NULL}  /* Sentinel */
+};
+
 #define PAT_OFF(x) offsetof(PatternObject, x)
 static PyMemberDef pattern_members[] = {
     {"pattern",    T_OBJECT,    PAT_OFF(pattern),       READONLY},
     {"flags",      T_INT,       PAT_OFF(flags),         READONLY},
     {"groups",     T_PYSSIZET,  PAT_OFF(groups),        READONLY},
-    {"groupindex", T_OBJECT,    PAT_OFF(groupindex),    READONLY},
     {NULL}  /* Sentinel */
 };
 
@@ -1409,6 +1421,7 @@ static PyTypeObject Pattern_Type = {
     0,                                  /* tp_iternext */
     pattern_methods,                    /* tp_methods */
     pattern_members,                    /* tp_members */
+    pattern_getset,                     /* tp_getset */
 };
 
 static int _validate(PatternObject *self); /* Forward */
-------------- next part --------------
diff -r 193ac288bc7f Lib/test/test_re.py
--- a/Lib/test/test_re.py	Sat Nov 01 11:05:36 2014 +0200
+++ b/Lib/test/test_re.py	Sat Nov 01 16:48:22 2014 +0200
@@ -493,6 +493,13 @@ class ReTests(unittest.TestCase):
         self.assertEqual(re.match("(a)", "a").regs, ((0, 1), (0, 1)))
         self.assertTrue(re.match("(a)", "a").re)
 
+        # Issue 14260.
+        p = re.compile(r'abc(?P<n>def)')
+        self.assertEqual(sorted(p.groupindex), ["n"])
+        self.assertEqual(p.groupindex["n"], 1)
+        self.asserRaises(TypeError):
+            p.groupindex["n"] = 0
+
     def test_special_escapes(self):
         self.assertEqual(re.search(r"\b(b.)\b",
                                    "abcd abc bcd bx").group(1), "bx")
diff -r 193ac288bc7f Modules/_sre.c
--- a/Modules/_sre.c	Sat Nov 01 11:05:36 2014 +0200
+++ b/Modules/_sre.c	Sat Nov 01 16:48:22 2014 +0200
@@ -1371,12 +1371,24 @@ static PyMethodDef pattern_methods[] = {
     {NULL, NULL}
 };
 
+/* PatternObject's 'groupindex' method. */
+static PyObject *
+pattern_groupindex(PatternObject *self)
+{
+    return PyDictProxy_New(self->groupindex);
+}
+
+static PyGetSetDef pattern_getset[] = {
+    {"groupindex", (getter)pattern_groupindex, (setter)NULL,
+      "A dictionary mapping group names to group numbers."},
+    {NULL}  /* Sentinel */
+};
+
 #define PAT_OFF(x) offsetof(PatternObject, x)
 static PyMemberDef pattern_members[] = {
     {"pattern",    T_OBJECT,    PAT_OFF(pattern),       READONLY},
     {"flags",      T_INT,       PAT_OFF(flags),         READONLY},
     {"groups",     T_PYSSIZET,  PAT_OFF(groups),        READONLY},
-    {"groupindex", T_OBJECT,    PAT_OFF(groupindex),    READONLY},
     {NULL}  /* Sentinel */
 };
 
@@ -1409,6 +1421,7 @@ static PyTypeObject Pattern_Type = {
     0,                                  /* tp_iternext */
     pattern_methods,                    /* tp_methods */
     pattern_members,                    /* tp_members */
+    pattern_getset,                     /* tp_getset */
 };
 
 static int _validate(PatternObject *self); /* Forward */

From report at bugs.python.org  Sat Nov  1 16:52:54 2014
From: report at bugs.python.org (Wouter van Heyst)
Date: Sat, 01 Nov 2014 15:52:54 +0000
Subject: [issue22753] urllib2 localnet Changed test to lookup IP-address of
 localhost
In-Reply-To: <1414507628.78.0.884878705537.issue22753@psf.upfronthosting.co.za>
Message-ID: <1414857174.85.0.797002299857.issue22753@psf.upfronthosting.co.za>


Wouter van Heyst added the comment:

What the patch does is replace the hard-coded address 127.0.0.1 for the loopback interface with a one-time lookup.  I'd argue the hunk @@ -315,7 +316,7 @@ should be dropped.

The two arguments that motivate this change are:

  1) The address of the loopback interface is not always 127.0.0.1, binding to it may fail.
  2) The tests seem to assume localhost resolves to the same address where the server is running.


Working on this patch started with the ConnectionRefusedError that H?kan mentioned. 
Applying the patch made the ConnectionRefusedError go away, but I think we may
have solved a different problem and suppressed the real problem as a side
effect.

@r.david.murray: would the patch be acceptable on dropping said hunk, and changing the description to 
"Do not assume localhost resolves to 127.0.0.1"?


That still leaves, I think, a hidden bug somewhere in the proxy code that will surface in some corner case.

----------

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

From report at bugs.python.org  Sat Nov  1 17:05:31 2014
From: report at bugs.python.org (Wouter van Heyst)
Date: Sat, 01 Nov 2014 16:05:31 +0000
Subject: [issue19838] test.test_pathlib.PosixPathTest.test_touch_common fails
 on FreeBSD with ZFS
In-Reply-To: <1385801049.84.0.483097954762.issue19838@psf.upfronthosting.co.za>
Message-ID: <1414857931.92.0.152067345489.issue19838@psf.upfronthosting.co.za>


Changes by Wouter van Heyst <wouter.bpo at richtlijn.be>:


----------
nosy: +larstiq

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

From report at bugs.python.org  Sat Nov  1 17:50:32 2014
From: report at bugs.python.org (Tim Graham)
Date: Sat, 01 Nov 2014 16:50:32 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1414860632.49.0.626793676305.issue22775@psf.upfronthosting.co.za>


Tim Graham added the comment:

Updated patch to test pickling of all protocols.

----------
Added file: http://bugs.python.org/file37100/cookie-pickling-all-protocols.diff

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

From report at bugs.python.org  Sat Nov  1 18:16:25 2014
From: report at bugs.python.org (Geoff Clements)
Date: Sat, 01 Nov 2014 17:16:25 +0000
Subject: [issue22781] ctypes: Differing results between Python and C.
Message-ID: <1414862185.49.0.654024451078.issue22781@psf.upfronthosting.co.za>


New submission from Geoff Clements:

I have used ctypes to create a binding to libdvdread but I am getting some bad values back from libdvdread when using python. I have used ctypeslib to generate the python bindings, i.e. h2xml and xml2py and, as far as I can tell, the bind is a faithful representation of the h files.

In order to demonstrate this I have created a small C program and a small Python3 program both doing the same thing. When run they should produce the same output but they do not. In order to run these you need a DVD inserted in a DVD drive, I've hard-coded the device path to the DVD drive as /dev/sr0 in both programs so this may need to be changed.

----------
components: ctypes
files: dvdtest.tar.gz
messages: 230453
nosy: Geoff.Clements
priority: normal
severity: normal
status: open
title: ctypes: Differing results between Python and C.
versions: Python 3.4
Added file: http://bugs.python.org/file37101/dvdtest.tar.gz

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

From report at bugs.python.org  Sat Nov  1 18:54:14 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Nov 2014 17:54:14 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414864454.09.0.145831056293.issue22695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Attached patch should fix the deprecated-removed directive. I've tested it with the following examples:

   .. deprecated-removed:: 3.4 4.0

      The ``'U'`` mode.


   .. deprecated-removed:: 3.4 4.0
      The ``'U'`` mode.


   .. deprecated-removed:: 3.4 4.0

----------
keywords: +patch
Added file: http://bugs.python.org/file37102/issue22695.diff

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

From report at bugs.python.org  Sat Nov  1 19:09:38 2014
From: report at bugs.python.org (Paul Moore)
Date: Sat, 01 Nov 2014 18:09:38 +0000
Subject: [issue22782] Python 3.4.2 Windows installer - cannot install 32 bit
 then 64 bit version
Message-ID: <1414865378.95.0.654751043147.issue22782@psf.upfronthosting.co.za>


New submission from Paul Moore:

When you install Python 3.4.2 32 bit and 64 bit on the same PC, in that order, the second one you install shows a red error message on the install screen, saying "This update will replace your existing Python 3.4 installation", and proceeds to uninstall the 32-bit version before installing. This is even though the two are being installed into different directories.

This does not happen if the 64 bit install is done first (which is a huge relief, as otherwise it's not possible to install the 2 versions side by side).

----------
assignee: steve.dower
components: Windows
messages: 230455
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.4.2 Windows installer - cannot install 32 bit then 64 bit version
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov  1 19:15:41 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 18:15:41 +0000
Subject: [issue22753] urllib2 localnet Changed test to lookup IP-address of
 localhost
In-Reply-To: <1414507628.78.0.884878705537.issue22753@psf.upfronthosting.co.za>
Message-ID: <1414865741.18.0.700318787554.issue22753@psf.upfronthosting.co.za>


R. David Murray added the comment:

The problem is that there are several places in the test suite (and the stdlib itself!) that assume that 127.0.0.1 is a valid loopback address.  This is the de-facto Internet standard, and while I know not all systems make 127.0.0.1 a valid loopback and/or do not map localhost to it, I'm not sure this is something it is practical for the stdlib or the test suite to compensate for.  (I had this problem with linux-vserver on my buildbots, see issue 3972).  It is true that the test suite in in a couple places assumes that 'localhost' maps to 127.0.0.1, which is an assumption that breaks more often than that of 127.0.0.;1 being a a valid loopback, since it depends on the "correct" configuration of the local host.

We've got a catch 22: if we assume localhost maps to a valid loopback address, the tests will fail on systems that are not configured correctly, while if we assume that 127.0.0.1 is a valid loopback address but may not be 'localhost', the tests will fail on systems for which 127.0.0.1 is not a valid loopback.  Since the stdlib itself assumes that 127.0.0.1 is valid, the former wins.  (As far as I know we don't have any open issues against the stdlib for this assumption.  If it is problematic on your system, then you should open a separate issue about that so we can consider it.)

If this test fails on your system because 127.0.0.1 is not a loopback address, I would expect many other tests to fail as well (ex: test_ssl).  If they do not, then I suspect your real problem is that localhost doesn't map to 127.0.0.1 even though 127.0.0.1 is a valid loopback address.  So, it looks to me like the better "fix" here would be to change 'URL' to be 'http://127.0.0.1'.  Can you confirm if that works for you, please?

----------

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

From report at bugs.python.org  Sat Nov  1 19:20:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 18:20:29 +0000
Subject: [issue14460] In re's positive lookbehind assertion repetition works
In-Reply-To: <1333267671.53.0.559378302882.issue14460@psf.upfronthosting.co.za>
Message-ID: <1414866029.53.0.254101463736.issue14460@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  1 19:21:54 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 18:21:54 +0000
Subject: [issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad
 argument to internal function
In-Reply-To: <1379574898.14.0.174335958635.issue19046@psf.upfronthosting.co.za>
Message-ID: <1414866114.12.0.288395825064.issue19046@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/issue19046>
_______________________________________

From report at bugs.python.org  Sat Nov  1 20:28:29 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Nov 2014 19:28:29 +0000
Subject: [issue22781] ctypes: Differing results between Python and C.
In-Reply-To: <1414862185.49.0.654024451078.issue22781@psf.upfronthosting.co.za>
Message-ID: <1414870109.29.0.0724075789187.issue22781@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This doesn't directly address your issue, but ctypeslib doesn't seem to have received any changes since 2009 (*), and has never had an official release. For a non-trivial binding, you might be better served using something providing type safety, such as Cython.

(*) (which makes it possible that ctypeslib produces bindings not compatible with Python 3, by the way)

----------
nosy: +meador.inge, pitrou
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sat Nov  1 20:38:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 19:38:35 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414870715.63.0.0452476928109.issue22695@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov  1 20:41:45 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 01 Nov 2014 19:41:45 +0000
Subject: [issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad
 argument to internal function
In-Reply-To: <1379574898.14.0.174335958635.issue19046@psf.upfronthosting.co.za>
Message-ID: <1414870905.46.0.377205659037.issue19046@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> out of date
status: pending -> closed

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

From report at bugs.python.org  Sat Nov  1 21:01:15 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 20:01:15 +0000
Subject: [issue22776] SyslogHandler's record formatting during emit(..) not
 covered by try-except block
In-Reply-To: <1414779190.8.0.640385408005.issue22776@psf.upfronthosting.co.za>
Message-ID: <20141101200108.111404.25986@psf.io>


Roundup Robot added the comment:

New changeset 54549f9b2ecc by Vinay Sajip in branch 'default':
Closes #22776: Merged fix from 3.4.
https://hg.python.org/cpython/rev/54549f9b2ecc

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

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

From report at bugs.python.org  Sat Nov  1 21:03:09 2014
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 01 Nov 2014 20:03:09 +0000
Subject: [issue22776] SyslogHandler's record formatting during emit(..) not
 covered by try-except block
In-Reply-To: <1414779190.8.0.640385408005.issue22776@psf.upfronthosting.co.za>
Message-ID: <1414872189.8.0.413874725479.issue22776@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

N.B. 2.7 and 3.4 also updated, but I accidentally left the issue no. out of the commit message. Relevant changesets are ea7b64406396 and f6a906541476.

----------

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

From report at bugs.python.org  Sat Nov  1 21:03:23 2014
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 01 Nov 2014 20:03:23 +0000
Subject: [issue22776] SyslogHandler's record formatting during emit(..) not
 covered by try-except block
In-Reply-To: <1414779190.8.0.640385408005.issue22776@psf.upfronthosting.co.za>
Message-ID: <1414872203.14.0.993541512094.issue22776@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Nov  1 21:35:07 2014
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 01 Nov 2014 20:35:07 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1414874107.52.0.0389536412202.issue12939@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
nosy: +rpetrov

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

From report at bugs.python.org  Sat Nov  1 22:34:08 2014
From: report at bugs.python.org (Geoff Clements)
Date: Sat, 01 Nov 2014 21:34:08 +0000
Subject: [issue22781] ctypes: Differing results between Python and C.
In-Reply-To: <1414862185.49.0.654024451078.issue22781@psf.upfronthosting.co.za>
Message-ID: <1414877648.61.0.419543891394.issue22781@psf.upfronthosting.co.za>


Geoff Clements added the comment:

Thanks for the comment Antoine.

I understand that ctypeslib is old but it produces relatively mundane python code which is python version agnostic. Well, that's how it looks to me.

I have not used cython mainly because it would make the distribution of my code more complex but it may be worth trying if only to point the issue at ctypes or otherwise.

----------

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

From report at bugs.python.org  Sat Nov  1 22:49:50 2014
From: report at bugs.python.org (David Edelsohn)
Date: Sat, 01 Nov 2014 21:49:50 +0000
Subject: [issue22773] Export Readline version and expect ANSI sequence for
 version < 0x0600
In-Reply-To: <1414764088.14.0.977066596578.issue22773@psf.upfronthosting.co.za>
Message-ID: <1414878590.57.0.259065689011.issue22773@psf.upfronthosting.co.za>


Changes by David Edelsohn <dje.gcc at gmail.com>:


----------
title: Export Readline version and expect ANSI sequence for version < 0x6000 -> Export Readline version and expect ANSI sequence for version < 0x0600

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

From report at bugs.python.org  Sat Nov  1 22:57:31 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Nov 2014 21:57:31 +0000
Subject: [issue22782] Python 3.4.2 Windows installer - cannot install 32 bit
 then 64 bit version
In-Reply-To: <1414865378.95.0.654751043147.issue22782@psf.upfronthosting.co.za>
Message-ID: <1414879051.38.0.965439448439.issue22782@psf.upfronthosting.co.za>


Steve Dower added the comment:

The 3.4 installer is still maintained by Martin.

----------
assignee: steve.dower -> 
nosy: +loewis

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

From report at bugs.python.org  Sat Nov  1 23:02:06 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:02:06 +0000
Subject: [issue15279] Spurious unittest warnings
In-Reply-To: <1341674545.77.0.716203051696.issue15279@psf.upfronthosting.co.za>
Message-ID: <1414879326.21.0.342577898366.issue15279@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm going to close this.
If someone can reproduce it again, feel free to reopen it.

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

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

From report at bugs.python.org  Sat Nov  1 23:05:36 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:05:36 +0000
Subject: [issue16056] shadowed test names in std lib regression tests
In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za>
Message-ID: <1414879536.68.0.569719572136.issue16056@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Sat Nov  1 23:09:27 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:09:27 +0000
Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual
In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za>
Message-ID: <1414879767.27.0.0775498297387.issue22452@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Sat Nov  1 23:11:39 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 22:11:39 +0000
Subject: [issue22731] test_capi test fails because of mismatched newlines
In-Reply-To: <1414355323.22.0.739956006711.issue22731@psf.upfronthosting.co.za>
Message-ID: <20141101221136.35266.78645@psf.io>


Roundup Robot added the comment:

New changeset edb270e5c9c3 by Steve Dower in branch 'default':
#22731 test_capi test fails because of mismatched newlines
https://hg.python.org/cpython/rev/edb270e5c9c3

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

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

From report at bugs.python.org  Sat Nov  1 23:12:05 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Nov 2014 22:12:05 +0000
Subject: [issue22731] test_capi test fails because of mismatched newlines
In-Reply-To: <1414355323.22.0.739956006711.issue22731@psf.upfronthosting.co.za>
Message-ID: <1414879925.37.0.57108804314.issue22731@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


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

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

From report at bugs.python.org  Sat Nov  1 23:13:22 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:13:22 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1414880002.28.0.590475729478.issue22364@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

+1 on the idea.

----------
stage:  -> needs patch

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

From report at bugs.python.org  Sat Nov  1 23:14:14 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:14:14 +0000
Subject: [issue16007] Improved Error message for failing re expressions
In-Reply-To: <1348416868.74.0.37879499143.issue16007@psf.upfronthosting.co.za>
Message-ID: <1414880054.1.0.979116675206.issue16007@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Sat Nov  1 23:16:10 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 22:16:10 +0000
Subject: [issue22732] ctypes tests don't set correct restype for intptr_t
 functions
In-Reply-To: <1414355526.1.0.122133649749.issue22732@psf.upfronthosting.co.za>
Message-ID: <20141101221607.35260.20192@psf.io>


Roundup Robot added the comment:

New changeset a944fe09fae8 by Steve Dower in branch 'default':
#22732 ctypes tests don't set correct restype for intptr_t functions
https://hg.python.org/cpython/rev/a944fe09fae8

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

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

From report at bugs.python.org  Sat Nov  1 23:16:10 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 22:16:10 +0000
Subject: [issue22734] marshal needs a lower stack depth for debug builds on
 Windows
In-Reply-To: <1414356005.7.0.437869876375.issue22734@psf.upfronthosting.co.za>
Message-ID: <20141101221607.35260.21428@psf.io>


Roundup Robot added the comment:

New changeset c2a3865a59f4 by Steve Dower in branch 'default':
#22734 marshal needs a lower stack depth for debug builds on Windows
https://hg.python.org/cpython/rev/c2a3865a59f4

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

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

From report at bugs.python.org  Sat Nov  1 23:16:57 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Nov 2014 22:16:57 +0000
Subject: [issue22734] marshal needs a lower stack depth for debug builds on
 Windows
In-Reply-To: <1414356005.7.0.437869876375.issue22734@psf.upfronthosting.co.za>
Message-ID: <1414880217.08.0.0585708909771.issue22734@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


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

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

From report at bugs.python.org  Sat Nov  1 23:17:11 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Nov 2014 22:17:11 +0000
Subject: [issue22732] ctypes tests don't set correct restype for intptr_t
 functions
In-Reply-To: <1414355526.1.0.122133649749.issue22732@psf.upfronthosting.co.za>
Message-ID: <1414880231.1.0.561610840052.issue22732@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


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

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

From report at bugs.python.org  Sat Nov  1 23:19:26 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:19:26 +0000
Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad
 argument
In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za>
Message-ID: <1414880366.45.0.599781064776.issue21931@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Sat Nov  1 23:23:43 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:23:43 +0000
Subject: [issue21400] Code coverage documentation is out-of-date.
In-Reply-To: <1398870474.7.0.668295680228.issue21400@psf.upfronthosting.co.za>
Message-ID: <1414880623.28.0.535254157369.issue21400@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Sat Nov  1 23:32:23 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 01 Nov 2014 22:32:23 +0000
Subject: [issue21815] imaplib truncates some untagged responses
In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za>
Message-ID: <1414881143.63.0.544057924126.issue21815@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the patches Lita, however it's better if you can upload a single patch with all the required changes.  This will make it easier to apply/review it.

----------
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Nov  1 23:38:16 2014
From: report at bugs.python.org (eryksun)
Date: Sat, 01 Nov 2014 22:38:16 +0000
Subject: [issue22781] ctypes: Differing results between Python and C.
In-Reply-To: <1414862185.49.0.654024451078.issue22781@psf.upfronthosting.co.za>
Message-ID: <1414881496.38.0.537491399427.issue22781@psf.upfronthosting.co.za>


eryksun added the comment:

ctypes doesn't always handle bitfields correctly. In particular it doesn't adapt the storage unit size when packed. A bitfield based on c_uint is always stored in 4 bytes, even if _pack_ is set to 1. This is MSVC rules, so all is well on Windows. 

For example, from ifo_types.h:

    typedef struct {
      unsigned int zero_1                    : 1;
      unsigned int multi_or_random_pgc_title : 1; /* 0: one sequential pgc title */
      unsigned int jlc_exists_in_cell_cmd    : 1;
      unsigned int jlc_exists_in_prepost_cmd : 1;
      unsigned int jlc_exists_in_button_cmd  : 1;
      unsigned int jlc_exists_in_tt_dom      : 1;
      unsigned int chapter_search_or_play    : 1; /* UOP 1 */
      unsigned int title_or_time_play        : 1; /* UOP 0 */
    } ATTRIBUTE_PACKED playback_type_t;

ctypeslib translates this as follows:

    class playback_type_t(Structure):
        pass
    playback_type_t._fields_ = [
        ('zero_1', c_uint, 1),
        ('multi_or_random_pgc_title', c_uint, 1),
        ('jlc_exists_in_cell_cmd', c_uint, 1),
        ('jlc_exists_in_prepost_cmd', c_uint, 1),
        ('jlc_exists_in_button_cmd', c_uint, 1),
        ('jlc_exists_in_tt_dom', c_uint, 1),
        ('chapter_search_or_play', c_uint, 1),
        ('title_or_time_play', c_uint, 1),
    ]

It doesn't set _pack_ = 1, but ctypes wouldn't use that to pack the c_uint bitfield anyway. It's 4 bytes, either way. MSVC agrees, even with #pragma pack(1). OTOH, with __attribute__((packed)), gcc packs the bitfield into a single byte. 

The incorrect packing (for gcc) of playback_type_t results in an incorrect offset for title_set_nr in title_info_t:

    class title_info_t(Structure):
        pass
    title_info_t._pack_ = 1
    title_info_t._fields_ = [
        ('pb_ty', playback_type_t),
        ('nr_of_angles', uint8_t),
        ('nr_of_ptts', uint16_t),
        ('parental_id', uint16_t),
        ('title_set_nr', uint8_t),
        ('vts_ttn', uint8_t),
        ('title_set_sector', uint32_t),
    ]

As a workaround for the immediate problem, on platforms that use gcc you can use c_uint8 in playback_type_t instead of c_uint. You'll want to verify other bitfields as well. I don't know about other compilers on other platforms. 

Working at the ABI level can be painful. Consider using CFFI's API level interface instead:

https://cffi.readthedocs.org

----------
nosy: +eryksun

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

From report at bugs.python.org  Sat Nov  1 23:49:08 2014
From: report at bugs.python.org (Geoff Clements)
Date: Sat, 01 Nov 2014 22:49:08 +0000
Subject: [issue22781] ctypes: Differing results between Python and C.
In-Reply-To: <1414881496.38.0.537491399427.issue22781@psf.upfronthosting.co.za>
Message-ID: <CALrvJCv=C0LBTQ6NA2ep4WCXaCG6uPoLo+hvcYASOsL8TDu4_A@mail.gmail.com>


Geoff Clements added the comment:

Thank you eryksun for the explanation. It's much appreciated. I'll take a
look at CFFI.
On 1 Nov 2014 22:38, "eryksun" <report at bugs.python.org> wrote:

>
> eryksun added the comment:
>
> ctypes doesn't always handle bitfields correctly. In particular it doesn't
> adapt the storage unit size when packed. A bitfield based on c_uint is
> always stored in 4 bytes, even if _pack_ is set to 1. This is MSVC rules,
> so all is well on Windows.
>
> For example, from ifo_types.h:
>
>     typedef struct {
>       unsigned int zero_1                    : 1;
>       unsigned int multi_or_random_pgc_title : 1; /* 0: one sequential pgc
> title */
>       unsigned int jlc_exists_in_cell_cmd    : 1;
>       unsigned int jlc_exists_in_prepost_cmd : 1;
>       unsigned int jlc_exists_in_button_cmd  : 1;
>       unsigned int jlc_exists_in_tt_dom      : 1;
>       unsigned int chapter_search_or_play    : 1; /* UOP 1 */
>       unsigned int title_or_time_play        : 1; /* UOP 0 */
>     } ATTRIBUTE_PACKED playback_type_t;
>
> ctypeslib translates this as follows:
>
>     class playback_type_t(Structure):
>         pass
>     playback_type_t._fields_ = [
>         ('zero_1', c_uint, 1),
>         ('multi_or_random_pgc_title', c_uint, 1),
>         ('jlc_exists_in_cell_cmd', c_uint, 1),
>         ('jlc_exists_in_prepost_cmd', c_uint, 1),
>         ('jlc_exists_in_button_cmd', c_uint, 1),
>         ('jlc_exists_in_tt_dom', c_uint, 1),
>         ('chapter_search_or_play', c_uint, 1),
>         ('title_or_time_play', c_uint, 1),
>     ]
>
> It doesn't set _pack_ = 1, but ctypes wouldn't use that to pack the c_uint
> bitfield anyway. It's 4 bytes, either way. MSVC agrees, even with #pragma
> pack(1). OTOH, with __attribute__((packed)), gcc packs the bitfield into a
> single byte.
>
> The incorrect packing (for gcc) of playback_type_t results in an incorrect
> offset for title_set_nr in title_info_t:
>
>     class title_info_t(Structure):
>         pass
>     title_info_t._pack_ = 1
>     title_info_t._fields_ = [
>         ('pb_ty', playback_type_t),
>         ('nr_of_angles', uint8_t),
>         ('nr_of_ptts', uint16_t),
>         ('parental_id', uint16_t),
>         ('title_set_nr', uint8_t),
>         ('vts_ttn', uint8_t),
>         ('title_set_sector', uint32_t),
>     ]
>
> As a workaround for the immediate problem, on platforms that use gcc you
> can use c_uint8 in playback_type_t instead of c_uint. You'll want to verify
> other bitfields as well. I don't know about other compilers on other
> platforms.
>
> Working at the ABI level can be painful. Consider using CFFI's API level
> interface instead:
>
> https://cffi.readthedocs.org
>
> ----------
> nosy: +eryksun
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22781>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Nov  2 00:40:28 2014
From: report at bugs.python.org (Nir Soffer)
Date: Sat, 01 Nov 2014 23:40:28 +0000
Subject: [issue22697] Deadlock with writing to stderr from forked process
In-Reply-To: <1413986367.14.0.352107167307.issue22697@psf.upfronthosting.co.za>
Message-ID: <1414885228.52.0.162338496401.issue22697@psf.upfronthosting.co.za>


Nir Soffer added the comment:

This is a duplicate of http://bugs.python.org/issue6721

----------
nosy: +nirs

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

From report at bugs.python.org  Sun Nov  2 00:43:53 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 01 Nov 2014 23:43:53 +0000
Subject: [issue17717] Set up nasm from external.bat
In-Reply-To: <1365870872.82.0.912332979443.issue17717@psf.upfronthosting.co.za>
Message-ID: <20141101234349.109258.92478@psf.io>


Roundup Robot added the comment:

New changeset 28d18fdc52c4 by Zachary Ware in branch '2.7':
Issue #17717: Pull NASM from svn.python.org for OpenSSL build.
https://hg.python.org/cpython/rev/28d18fdc52c4

New changeset f7ed3e058fca by Zachary Ware in branch '3.4':
Issue #17717: Pull NASM from svn.python.org for OpenSSL build.
https://hg.python.org/cpython/rev/f7ed3e058fca

New changeset ef15b51d59fb by Zachary Ware in branch 'default':
Issue #17717: Pull NASM from svn.python.org for OpenSSL build.
https://hg.python.org/cpython/rev/ef15b51d59fb

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

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

From report at bugs.python.org  Sun Nov  2 00:54:40 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 01 Nov 2014 23:54:40 +0000
Subject: [issue22731] test_capi test fails because of mismatched newlines
In-Reply-To: <1414355323.22.0.739956006711.issue22731@psf.upfronthosting.co.za>
Message-ID: <1414886080.43.0.814656547715.issue22731@psf.upfronthosting.co.za>


Steve Dower added the comment:

As near as I can tell, Py_Initialize() is causing the stdout mode to change from O_TEXT to O_BINARY in _testembed.

Looking at the output in this test, you can see the first printf('\n') (after 'Use defaults') is correctly translated, but the next '\n' comes after Py_Initialize().

b'--- Use defaults ---\r\n... \r\n--- Set encoding only ---\n...'

I don't really see how this can be avoided without breaking something else to do with text IO. Probably the documentation for Py_Initialize should get the note, rather than the What's New section. Py_Initialize has really brief docs, and I'm certain there are plenty of other little things like this that change when you call it - is this the right place for compiler-specific caveats like this? I don't really know where else it could go. Or is it something that we really do want to fix? (We generally avoid changing global settings like this where possible.)

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

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

From report at bugs.python.org  Sun Nov  2 00:57:31 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 01 Nov 2014 23:57:31 +0000
Subject: [issue17717] Set up nasm from external.bat
In-Reply-To: <1365870872.82.0.912332979443.issue17717@psf.upfronthosting.co.za>
Message-ID: <1414886251.3.0.0674597034219.issue17717@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The patches for 2.7 and 3.4 were more trivial than for default, and I was pretty confident in the patch for default, so I went ahead and committed.  I did switch around which end of PATH our copy of NASM was added to, to make it easier for someone to override which NASM was used.

Thanks for the suggestion John, and thanks for the support Antoine!

----------
assignee:  -> zach.ware
resolution:  -> fixed
status: open -> closed
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Nov  2 00:58:27 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 01 Nov 2014 23:58:27 +0000
Subject: [issue17717] Set up nasm from external.bat
In-Reply-To: <1365870872.82.0.912332979443.issue17717@psf.upfronthosting.co.za>
Message-ID: <1414886307.66.0.444509621049.issue17717@psf.upfronthosting.co.za>


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


----------
components: +Build
nosy: +tim.golden
stage:  -> resolved

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

From report at bugs.python.org  Sun Nov  2 03:34:03 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 02:34:03 +0000
Subject: [issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on
 OS X when run with regrtest -j option
In-Reply-To: <1414710344.61.0.884489180713.issue22770@psf.upfronthosting.co.za>
Message-ID: <20141102023400.35274.16172@psf.io>


Roundup Robot added the comment:

New changeset bd4dc351d670 by Ned Deily in branch '2.7':
Issue #22770: Prevent some Tk segfaults on OS X when running gui tests.
https://hg.python.org/cpython/rev/bd4dc351d670

New changeset 121517deb318 by Ned Deily in branch '3.4':
Issue #22770: Prevent some Tk segfaults on OS X when running gui tests.
https://hg.python.org/cpython/rev/121517deb318

New changeset e119343bc3ec by Ned Deily in branch 'default':
Issue #22770: merge from 3.4
https://hg.python.org/cpython/rev/e119343bc3ec

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

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

From report at bugs.python.org  Sun Nov  2 03:36:39 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 02 Nov 2014 02:36:39 +0000
Subject: [issue22770] test_ttk_guionly and test_tk can cause Tk segfaults on
 OS X when run with regrtest -j option
In-Reply-To: <1414710344.61.0.884489180713.issue22770@psf.upfronthosting.co.za>
Message-ID: <1414895799.81.0.715625612962.issue22770@psf.upfronthosting.co.za>


Ned Deily added the comment:

Applied for release in 2.7.9, 3.4.3, and 3.5.0.

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

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

From report at bugs.python.org  Sun Nov  2 03:48:34 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 02 Nov 2014 02:48:34 +0000
Subject: [issue18604] Consolidate gui available checks in test.support
In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za>
Message-ID: <1414896514.45.0.501409493334.issue18604@psf.upfronthosting.co.za>


Ned Deily added the comment:

The previous segfaults on OS X have been isolated to a problem in Cocoa Tk and an issue has been opened about it on the Tk issue tracker.  See Issue22770 for details.  Changesets applied to _is_gui_available() in that issue should prevent the segfaults by ensuring that Tk completes necessary initialization before the Tcl interpreter instance is destroyed and a new one created.  So _is_gui_available() is now enabled on OS X and we can close this issue.

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

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

From report at bugs.python.org  Sun Nov  2 03:50:34 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Nov 2014 02:50:34 +0000
Subject: [issue17896] Move Windows external libs from <src>\..\ to
 <src>\externals
In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za>
Message-ID: <1414896634.81.0.657212070834.issue17896@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The patch looks pretty straightforward.  Running the revised external.bat and then pcbuild.sln seem to give the same result as before.  So this looks ready to me.

As to Steve's merge question: since externals is ignored and not part of the python.org repository, it should have no effect on merge or graft.

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

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

From report at bugs.python.org  Sun Nov  2 04:20:30 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 02 Nov 2014 03:20:30 +0000
Subject: [issue18604] Consolidate gui available checks in test.support
In-Reply-To: <1414896514.45.0.501409493334.issue18604@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-M50yHrS9E3fi4Y5bB3rqNbO9RwtriBgi+2Do+4wC8v4w@mail.gmail.com>


Zachary Ware added the comment:

Thanks for tracking it down, Ned!

----------

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

From report at bugs.python.org  Sun Nov  2 04:50:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 03:50:12 +0000
Subject: [issue17896] Move Windows external libs from <src>\..\ to
 <src>\externals
In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za>
Message-ID: <20141102035007.111400.47695@psf.io>


Roundup Robot added the comment:

New changeset 62ce0f623154 by Zachary Ware in branch '2.7':
Issue #17896: Move Windows external lib sources from .. to externals.
https://hg.python.org/cpython/rev/62ce0f623154

New changeset b5e9bc4352e1 by Zachary Ware in branch '3.4':
Issue #17896: Move Windows external lib sources from .. to externals.
https://hg.python.org/cpython/rev/b5e9bc4352e1

New changeset 64a54f0c87d7 by Zachary Ware in branch 'default':
Issue #17896: Move Windows external lib sources from .. to externals.
https://hg.python.org/cpython/rev/64a54f0c87d7

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

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

From report at bugs.python.org  Sun Nov  2 04:57:12 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 02 Nov 2014 03:57:12 +0000
Subject: [issue17896] Move Windows external libs from <src>\..\ to
 <src>\externals
In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za>
Message-ID: <1414900632.43.0.323328894257.issue17896@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the test, Terry.  Committed.

----------
assignee:  -> zach.ware
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Nov  2 08:34:55 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Nov 2014 07:34:55 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1414913695.22.0.0754955400578.issue22364@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Nov  2 09:41:26 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Nov 2014 08:41:26 +0000
Subject: [issue17900] Recursive OrderedDict pickling
In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>
Message-ID: <1414917686.91.0.862996748532.issue17900@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This patch caused a regression by breaking designed-in support for pickling using PyYAML (note, there was a test for yaml support, but this patch defeated the test).  As a result of the patch, ordering now gets lost during a dump/load roundtrip.

This change should not have been committed without my review (I would have caught the problem instantly).

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
type: enhancement -> behavior
versions: +Python 3.5
Added file: http://bugs.python.org/file37103/test_yaml.py

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

From report at bugs.python.org  Sun Nov  2 13:00:41 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 12:00:41 +0000
Subject: [issue16056] shadowed test names in std lib regression tests
In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za>
Message-ID: <1414929641.12.0.189500561325.issue16056@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think my patch is wrong.

test_weak_destroy_while_iterating and test_weak_destroy_and_mutate_while_iterating tests were committed as part of issue 7105 to 2.7 (see changeset https://hg.python.org/cpython/rev/03fcc12282fc). But, those same tests(they uses SomeClass instead of UserString) were also backported to 2.7 in https://hg.python.org/cpython/rev/04cc075bddf5

Here is a new patch.

----------
components: +Tests -Library (Lib)
stage: commit review -> patch review
versions:  -Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37104/issue16056_27_v2.diff

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

From report at bugs.python.org  Sun Nov  2 13:09:01 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 12:09:01 +0000
Subject: [issue17900] Recursive OrderedDict pickling
In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>
Message-ID: <1414930141.94.0.0870128115808.issue17900@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Can you explain what is broken independently of PyYAML?

----------

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

From report at bugs.python.org  Sun Nov  2 13:10:15 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 12:10:15 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414930215.62.0.872097983178.issue22695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a new patch. Thanks for the review, Serhiy.

----------
Added file: http://bugs.python.org/file37105/issue22695_v2.diff

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

From report at bugs.python.org  Sun Nov  2 13:11:24 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 12:11:24 +0000
Subject: [issue9771] add an optional "default" argument to
 tokenize.detect_encoding
In-Reply-To: <1283599930.65.0.476914851505.issue9771@psf.upfronthosting.co.za>
Message-ID: <1414930284.76.0.977638698158.issue9771@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sun Nov  2 15:14:48 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 14:14:48 +0000
Subject: [issue22293] unittest.mock: use slots in MagicMock to reduce memory
 footprint
In-Reply-To: <1409223925.36.0.353064472257.issue22293@psf.upfronthosting.co.za>
Message-ID: <1414937688.0.0.517405657178.issue22293@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

James, could you check again with a recent Python and see if the #11798 fix makes things any better?

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

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

From report at bugs.python.org  Sun Nov  2 15:33:42 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 14:33:42 +0000
Subject: [issue22317] action argument is not documented in argparse
 add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414938822.99.0.125023475928.issue22317@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +bethard
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Sun Nov  2 15:56:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 14:56:24 +0000
Subject: [issue17900] Recursive OrderedDict pickling
In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>
Message-ID: <1414940184.84.0.0387336483857.issue17900@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry, I did not notice test_yaml_linkage. And in any case this test was broken (should be rv[1][0] instead of rv[1]).

I don't like to revert these changes, and the reversion can break a code written for 3.4 which pickles recursive OrderedDicts. I suggest following solution. PyYAML calls __reduce_ex_(2) or __reduce__(). Therefore we can return to old behavior with protocol < 3 and left current behavior with protocol >= 3. Recursive OrderedDicts will be pickleable with default protocol and with highest protocol, and PyYAML will be happy.

Does this patch look good to your?

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37106/OrderedDict_pickle_PyYAML.patch

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

From report at bugs.python.org  Sun Nov  2 16:05:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:05:39 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414940739.02.0.769914087626.issue22695@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On my superficial view the patch looks good. But I am not well known with Sphinx code.

----------

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

From report at bugs.python.org  Sun Nov  2 16:07:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:07:52 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1414940872.48.0.646335166516.issue22364@psf.upfronthosting.co.za>


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


----------
dependencies: +Add additional attributes to re.error, Other mentions of the buffer protocol

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

From report at bugs.python.org  Sun Nov  2 16:11:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:11:51 +0000
Subject: [issue22697] Deadlock with writing to stderr from forked process
In-Reply-To: <1413986367.14.0.352107167307.issue22697@psf.upfronthosting.co.za>
Message-ID: <1414941111.62.0.933903768369.issue22697@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Locks in the standard library should be sanitized on fork

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

From report at bugs.python.org  Sun Nov  2 16:16:25 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:16:25 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414941385.42.0.466516134078.issue22335@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Sun Nov  2 16:20:47 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:20:47 +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: <1414941647.32.0.954329330836.issue16662@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> resolved

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

From report at bugs.python.org  Sun Nov  2 16:22:15 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:22:15 +0000
Subject: [issue22344] Reorganize unittest.mock docs into linear manner
In-Reply-To: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za>
Message-ID: <1414941735.47.0.142353562087.issue22344@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Sun Nov  2 16:23:01 2014
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sun, 02 Nov 2014 15:23:01 +0000
Subject: [issue22697] Deadlock with writing to stderr from forked process
In-Reply-To: <1413986367.14.0.352107167307.issue22697@psf.upfronthosting.co.za>
Message-ID: <1414941781.34.0.62487055533.issue22697@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

Serhiy, I don't think this is a duplicate. Odd that you closed this without any explanation.

This happens in a internal lock in cpython's runtime, while the other bug is about locks used in the logging module (which are very different).

----------
resolution: duplicate -> 
status: closed -> open

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

From report at bugs.python.org  Sun Nov  2 16:28:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:28:43 +0000
Subject: [issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible
Message-ID: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently in pickle with protocol 4 the NEWOBJ_EX opcode is used to reconstruct objects with __getnewargs__() or __getnewargs_ex__() even if there no keyword arguments.

>>> import pickle, pickletools, collections
>>> P = collections.namedtuple('P', 'x y')
>>> pickletools.dis(pickle.dumps(P(12, 34), 3))
    0: \x80 PROTO      3
    2: c    GLOBAL     '__main__ P'
   14: q    BINPUT     0
   16: K    BININT1    12
   18: K    BININT1    34
   20: \x86 TUPLE2
   21: q    BINPUT     1
   23: \x81 NEWOBJ
   24: q    BINPUT     2
   26: .    STOP
highest protocol among opcodes = 2
>>> pickletools.dis(pickle.dumps(P(12, 34), 4))
    0: \x80 PROTO      4
    2: \x95 FRAME      28
   11: \x8c SHORT_BINUNICODE '__main__'
   21: \x94 MEMOIZE
   22: \x8c SHORT_BINUNICODE 'P'
   25: \x94 MEMOIZE
   26: \x93 STACK_GLOBAL
   27: \x94 MEMOIZE
   28: K    BININT1    12
   30: K    BININT1    34
   32: \x86 TUPLE2
   33: \x94 MEMOIZE
   34: }    EMPTY_DICT
   35: \x94 MEMOIZE
   36: \x92 NEWOBJ_EX
   37: \x94 MEMOIZE
   38: .    STOP
highest protocol among opcodes = 4

These EMPTY_DICT//MEMOIZE//NEWOBJ_EX can be replaced by single NEWOBJ. Actually there is a regression in protocol 4 against protocol 3, so may be following patch should be applied on 3.4 too.

Here is a patch which uses __newobj__ instead of __newobj_ex__ if there are no keywords arguments. Also it reduce the number of lines of C code and adds tests for classes with __getnewargs__() and __getnewargs_ex__().

----------
components: Library (Lib)
files: pickle_newobj.patch
keywords: patch
messages: 230490
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickle: use NEWOBJ instead of NEWOBJ_EX if possible
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37107/pickle_newobj.patch

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

From report at bugs.python.org  Sun Nov  2 16:33:30 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:33:30 +0000
Subject: [issue22354] Idle: highlite tabs
In-Reply-To: <1410095822.07.0.751550923398.issue22354@psf.upfronthosting.co.za>
Message-ID: <1414942410.29.0.147233443018.issue22354@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Possible ways to highlite is to have a light grey: 
> <--> 
> ? (at the beginning of the tab)

FWIW the latter (?) is what I usually see used, with a lighter color to distinguish it from regular text.

> 3. Should tab space in comments and strings be shaded?  I think so.
> If so, should the shading match the comment/string foreground color?

Tabs in comments and strings should generally be avoided (\t can be used in strings), and at least for Python source I would assume they don't occur too frequently, so I wouldn't worry too much about this issue.

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

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

From report at bugs.python.org  Sun Nov  2 16:35:23 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:35:23 +0000
Subject: [issue22357] inspect module documentation makes no reference to
 __qualname__ attribute
In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za>
Message-ID: <1414942523.96.0.55824647817.issue22357@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou, yselivanov
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.5

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

From report at bugs.python.org  Sun Nov  2 16:37:59 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:37:59 +0000
Subject: [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1414942679.9.0.765332846232.issue22388@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch LGTM.

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

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

From report at bugs.python.org  Sun Nov  2 16:44:19 2014
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 02 Nov 2014 15:44:19 +0000
Subject: [issue22697] Deadlock with writing to stderr from forked process
In-Reply-To: <1413986367.14.0.352107167307.issue22697@psf.upfronthosting.co.za>
Message-ID: <1414943059.82.0.929824760315.issue22697@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> Maries Ionel Cristian added the comment:
>
> Serhiy, I don't think this is a duplicate. Odd that you closed this without any explanation.
>
> This happens in a internal lock in cpython's runtime, while the other bug is about locks used in the logging module (which are very different).

Yes, this is a duplicate. Whether the lock is an internal or a user-created one doesn't change anything, it's always the same problem of having a lock locked by another thread at the time of the fork().

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sun Nov  2 16:45:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:45:41 +0000
Subject: [issue22697] Deadlock with writing to stderr from forked process
In-Reply-To: <1413986367.14.0.352107167307.issue22697@psf.upfronthosting.co.za>
Message-ID: <1414943141.55.0.351025585062.issue22697@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry. I thought issue6721 is more general, not just about the logging module.

----------

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

From report at bugs.python.org  Sun Nov  2 16:47:05 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:47:05 +0000
Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1414943225.86.0.420663621873.issue22525@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Sun Nov  2 16:56:00 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:56:00 +0000
Subject: [issue22558] Missing hint to source code - complete
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1414943760.32.0.484063317171.issue22558@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The source links have been added where the code proved to be readable, easy to understand, and self documenting, and have been omitted when the code is complicated and not self documenting.  This has been done under the assumption that reading the code might help understanding the documentation, but there are other situations where users might want to see the code regardless of how readable it is, so I wouldn't object if you decide to add links to all the modules.

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  2 16:59:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:59:16 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414943956.07.0.54729847217.issue22335@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"logical_offset + 1" can't overflow because logical_offset is an offset in allocated array not counting final null byte.

----------

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

From report at bugs.python.org  Sun Nov  2 16:59:45 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 15:59:45 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414943985.86.0.407610399949.issue22335@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note that there are two possible crashes in debug mode:

$ ./python -c "bytearray(2**31-1)"
Erreur de segmentation

$ ./python -c "bytearray(2**31-2)"
python: Objects/obmalloc.c:1179: _PyObject_Alloc: Assertion `nelem <= ((Py_ssize_t)(((size_t)-1)>>1)) / elsize' failed.
Abandon

----------

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

From report at bugs.python.org  Sun Nov  2 17:01:20 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 16:01:20 +0000
Subject: [issue22612] Add block info to unicodedata
In-Reply-To: <1413050325.25.0.295627364762.issue22612@psf.upfronthosting.co.za>
Message-ID: <1414944080.6.0.661907062675.issue22612@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I needed this in the past and had to implement it myself, so adding it to unicodedata might be OK.  A script to generate the list of blocks from the official Unicode files should probably be created and used whenever we update the version of the Unicode database.

----------
components: +Unicode
nosy: +ezio.melotti, haypo
stage:  -> needs patch

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

From report at bugs.python.org  Sun Nov  2 17:01:57 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 16:01:57 +0000
Subject: [issue22317] action argument is not documented in argparse
 add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414944117.4.0.0796394654627.issue22317@psf.upfronthosting.co.za>


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


----------
nosy: +paul.j3
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  2 17:03:31 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 16:03:31 +0000
Subject: [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1414944211.92.0.0805671328981.issue22671@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sun Nov  2 17:08:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 16:08:11 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414944491.02.0.483814151046.issue22335@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch. It also fixes a bug in the debug allocators, which didn't properly check for Py_ssize_t overflow.

----------
Added file: http://bugs.python.org/file37108/ba_resize.patch

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

From report at bugs.python.org  Sun Nov  2 17:08:20 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 16:08:20 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414944500.58.0.447540283955.issue22335@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Interpreter Core
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Nov  2 17:08:54 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 16:08:54 +0000
Subject: [issue22716] Add reference to the object missing an attribute to
 AttributeError
In-Reply-To: <1414162979.59.0.692601319144.issue22716@psf.upfronthosting.co.za>
Message-ID: <1414944534.13.0.801069354865.issue22716@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think we should be pursued together with #18156, so I'm going to close this.  Serhiy already added a reference to this issue there.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Nov  2 17:09:54 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 16:09:54 +0000
Subject: [issue18156] Add an 'attr' attribute to AttributeError
In-Reply-To: <1370619110.26.0.980030189702.issue18156@psf.upfronthosting.co.za>
Message-ID: <1414944594.36.0.729674724657.issue18156@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I closed #22716 in favor of this, since I think both should be tackled together.

----------

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

From report at bugs.python.org  Sun Nov  2 17:20:57 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 16:20:57 +0000
Subject: [issue22784] test_asyncio fails without the ssl module
Message-ID: <1414945257.4.0.921150586656.issue22784@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Patch attached. I don't know whether this applies to 3.4 as well.

----------
components: Tests, asyncio
files: ssl_test_asyncio.patch
keywords: patch
messages: 230502
nosy: gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: test_asyncio fails without the ssl module
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37109/ssl_test_asyncio.patch

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

From report at bugs.python.org  Sun Nov  2 17:24:44 2014
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Sun, 02 Nov 2014 16:24:44 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1414945484.12.0.00576338389187.issue6721@psf.upfronthosting.co.za>


Changes by Maries Ionel Cristian <ionel.mc at gmail.com>:


----------
nosy: +ionel.mc

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

From report at bugs.python.org  Sun Nov  2 17:31:27 2014
From: report at bugs.python.org (flying sheep)
Date: Sun, 02 Nov 2014 16:31:27 +0000
Subject: [issue22716] Add reference to the object missing an attribute to
 AttributeError
In-Reply-To: <1414162979.59.0.692601319144.issue22716@psf.upfronthosting.co.za>
Message-ID: <1414945887.55.0.0184018014718.issue22716@psf.upfronthosting.co.za>


flying sheep added the comment:

sure, go ahead! i wasn?t aware of PEP nor issue, so sorry for filing a dupe.

----------

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

From report at bugs.python.org  Sun Nov  2 17:34:06 2014
From: report at bugs.python.org (flying sheep)
Date: Sun, 02 Nov 2014 16:34:06 +0000
Subject: [issue18156] Add an 'attr' attribute to AttributeError
In-Reply-To: <1370619110.26.0.980030189702.issue18156@psf.upfronthosting.co.za>
Message-ID: <1414946046.93.0.475167318211.issue18156@psf.upfronthosting.co.za>


flying sheep added the comment:

yeah, exactly: my idea was to add a reference to the original object (AttributeError.target). together with this bug, that would be the AttributeError part of PEP 473, which i really like!

----------
nosy: +flying sheep

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

From report at bugs.python.org  Sun Nov  2 18:06:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 17:06:10 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414947970.55.0.763923128742.issue22335@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

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

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

From report at bugs.python.org  Sun Nov  2 18:15:42 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 17:15:42 +0000
Subject: [issue22751] Fix test___all__ warning about modified environment
In-Reply-To: <1414492058.43.0.353422984259.issue22751@psf.upfronthosting.co.za>
Message-ID: <20141102171539.120736.23102@psf.io>


Roundup Robot added the comment:

New changeset 37ed6eed0595 by Ezio Melotti in branch '3.4':
#22751: fix test___all__ warning about modified environment in the tests.  Patch by Michael Cetrulo.
https://hg.python.org/cpython/rev/37ed6eed0595

New changeset 16dfefe67c1f by Ezio Melotti in branch '2.7':
#22751: fix test___all__ warning about modified environment in the tests.  Patch by Michael Cetrulo.
https://hg.python.org/cpython/rev/16dfefe67c1f

New changeset 3c030e4da7c6 by Ezio Melotti in branch 'default':
#22751: merge with 3.4.
https://hg.python.org/cpython/rev/3c030e4da7c6

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

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

From report at bugs.python.org  Sun Nov  2 18:29:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 17:29:34 +0000
Subject: [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <20141102172926.120736.72886@psf.io>


Roundup Robot added the comment:

New changeset e3825486da53 by Serhiy Storchaka in branch '3.4':
Issue #22388: Unified the style of "Contributed by" sentences in What's New.
https://hg.python.org/cpython/rev/e3825486da53

New changeset 5f10a4a1e4df by Serhiy Storchaka in branch 'default':
Issue #22388: Unified the style of "Contributed by" sentences in What's New.
https://hg.python.org/cpython/rev/5f10a4a1e4df

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

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

From report at bugs.python.org  Sun Nov  2 18:31:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 17:31:29 +0000
Subject: [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1414949489.28.0.427883087325.issue22388@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ezio for your review.

----------

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

From report at bugs.python.org  Sun Nov  2 18:32:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 17:32:16 +0000
Subject: [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1414949536.48.0.73847629783.issue22388@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov  2 18:42:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 17:42:57 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <20141102174252.111392.31335@psf.io>


Roundup Robot added the comment:

New changeset 1590c594550e by Antoine Pitrou in branch '3.4':
Issue #22335: Fix crash when trying to enlarge a bytearray to 0x7fffffff bytes on a 32-bit platform.
https://hg.python.org/cpython/rev/1590c594550e

New changeset f0b334ae95c9 by Antoine Pitrou in branch 'default':
Issue #22335: Fix crash when trying to enlarge a bytearray to 0x7fffffff bytes on a 32-bit platform.
https://hg.python.org/cpython/rev/f0b334ae95c9

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

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

From report at bugs.python.org  Sun Nov  2 18:43:23 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 17:43:23 +0000
Subject: [issue22335] Python 3: Segfault instead of MemoryError when bytearray
 too big
In-Reply-To: <1409827137.12.0.977974506247.issue22335@psf.upfronthosting.co.za>
Message-ID: <1414950203.1.0.215194666956.issue22335@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you. This is now pushed.

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

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

From report at bugs.python.org  Sun Nov  2 18:59:52 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 17:59:52 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1414951192.18.0.366790479241.issue21650@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the suggestions.

> If you mean preserve order by default, then yes that would be a nice default.

issue21650_v3.diff implements this idea.

----------
Added file: http://bugs.python.org/file37110/issue21650_v3.diff

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

From report at bugs.python.org  Sun Nov  2 19:04:51 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Nov 2014 18:04:51 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414951491.04.0.574903539317.issue22725@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file37111/enumerate-doc.2.7.patch

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

From report at bugs.python.org  Sun Nov  2 19:05:17 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Nov 2014 18:05:17 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414951517.22.0.89916164123.issue22725@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file37112/enumerate_doc-3.4.patch

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

From report at bugs.python.org  Sun Nov  2 19:09:45 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 18:09:45 +0000
Subject: [issue22344] Reorganize unittest.mock docs into linear manner
In-Reply-To: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za>
Message-ID: <1414951785.19.0.0201532692156.issue22344@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Sun Nov  2 19:13:27 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 02 Nov 2014 18:13:27 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1414952007.81.0.912958826695.issue22417@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

New patch uses self-signed.pythontest.net, instead of svn.python.org. svn.python.org is signed by CACert, which is in the root on some machines.

----------
Added file: http://bugs.python.org/file37113/issue22417.diff

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

From report at bugs.python.org  Sun Nov  2 19:14:32 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 02 Nov 2014 18:14:32 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1414952072.04.0.224610109349.issue22650@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Note we now have pythontest.net set up.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sun Nov  2 19:19:24 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 18:19:24 +0000
Subject: [issue22366] urllib.request.urlopen should take a "context"
 (SSLContext) argument
In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za>
Message-ID: <20141102181919.111416.94223@psf.io>


Roundup Robot added the comment:

New changeset 13f46fc1a002 by Senthil Kumaran in branch '3.4':
backport context argument of urlopen (#22366) for pep 476
https://hg.python.org/cpython/rev/13f46fc1a002

----------

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

From report at bugs.python.org  Sun Nov  2 19:41:01 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 18:41:01 +0000
Subject: [issue22751] Fix test___all__ warning about modified environment
In-Reply-To: <1414492058.43.0.353422984259.issue22751@psf.upfronthosting.co.za>
Message-ID: <1414953661.65.0.142582837317.issue22751@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The buildbot seems happy, so I'm going to close this.
Thanks for the patch!

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

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

From report at bugs.python.org  Sun Nov  2 19:46:09 2014
From: report at bugs.python.org (Tim Graham)
Date: Sun, 02 Nov 2014 18:46:09 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1414953969.01.0.600022840085.issue22775@psf.upfronthosting.co.za>


Tim Graham added the comment:

Updated patch per comments.

----------
Added file: http://bugs.python.org/file37114/cookie-pickling-all-protocols-2.diff

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

From report at bugs.python.org  Sun Nov  2 19:48:58 2014
From: report at bugs.python.org (Lita Cho)
Date: Sun, 02 Nov 2014 18:48:58 +0000
Subject: [issue21815] imaplib truncates some untagged responses
In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za>
Message-ID: <1414954138.83.0.0471698923236.issue21815@psf.upfronthosting.co.za>


Lita Cho added the comment:

Sure, let me combine it into one change.

----------

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

From report at bugs.python.org  Sun Nov  2 19:55:15 2014
From: report at bugs.python.org (David Bolen)
Date: Sun, 02 Nov 2014 18:55:15 +0000
Subject: [issue17896] Move Windows external libs from <src>\..\ to
 <src>\externals
In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za>
Message-ID: <1414954515.34.0.277324770657.issue17896@psf.upfronthosting.co.za>


David Bolen added the comment:

I noticed this issue when checking on some recent 2.7 branch failures on my buildbot.  It might be worth noting this change to any Windows buildbot owners since we all have existing trees now with a lot of stranded external folders that can be removed.

For what it's worth - and it's a minor concern - in a buildbot context, I prefer the old way.  I am much more likely to have to manipulate the build folder (the hg checkout/build folder on a buildbot) to deal with issues than any of the external folders, so it's always been very convenient to be able to do so easily without affecting those externals (for which causing a rebuild is very time consuming)

-- David

----------
nosy: +db3l

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

From report at bugs.python.org  Sun Nov  2 20:30:16 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Nov 2014 19:30:16 +0000
Subject: [issue17900] Recursive OrderedDict pickling
In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>
Message-ID: <1414956616.37.0.996859743974.issue17900@psf.upfronthosting.co.za>


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


----------
assignee: serhiy.storchaka -> rhettinger

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

From report at bugs.python.org  Sun Nov  2 20:55:09 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 02 Nov 2014 19:55:09 +0000
Subject: [issue22354] Idle: highlite tabs
In-Reply-To: <1410095822.07.0.751550923398.issue22354@psf.upfronthosting.co.za>
Message-ID: <1414958109.47.0.367079272025.issue22354@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I looked more into tab handling in tk and Idle. Tk uses literal tabs in text to position following text according to the tab stops configured with the Text tabs option.  Tabs stops are ultimately set to the pixel (not character), although one may enter distances in other units.  The following text may be left, right, center, or number justified with respect to the tab stop, with 'left' the default.  I am rather sure that there is no way to tell tk to display a special char at the beginning of any extra space it adds. In the general case, there may not be enough extra to do so.

Tab handling in Idle is more confused.  They are normally converted to spaces in Editor windows, but in left as is and used for auto-indents in multi-line statements in Shell.  (The latter is a major nuisance, which I hope to remedy.)  There are more oddities within the editor, some probably not necessary now.  One is that turning tabs on and off changes the tab to space replacement to 8 instead of what it was (the default now being 4).  Another is that Idle was written when mixed space-and-tab indents were legal.  So a) Idle allows one to write illegal-in-3.x indents, and b) the code to handle tab, backspace, enter, indent, and dedent is probably more complicated that it would have to be if illegal indents were never allowed.  (The tab handling code is in EditorWindow.py, in 3.4.2 mostly around lines 240-260 and 1200-1300.)

Given the above, I would consider tagging tabs at least when a file is read and probably during editing.  Since indents are the major concern, I would not worry much about what happens elsewhere.
---

Successive tabs could be differentiated by having two tab tags with different background colors and alternate their use.  The following does this with a sample line.

import tkinter as tk
root = tk.Tk()
text = tk.Text(root)
text.pack()

text.tag_config('TAB0', background='#fed')  # light yellow
text.tag_config('TAB1', background='#eef')  # light blue
ttags = ('TAB0', 'TAB1')
tdex = 0

line = 'a\t\t    \t b'
text.insert('insert', line)
for i, c in enumerate(line):
    if c == '\t':
        text.tag_add(ttags[tdex], '1.%d'%i, '1.%d'%(i+1))
        tdex ^=1

----------

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

From report at bugs.python.org  Sun Nov  2 21:02:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 20:02:01 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1414958521.77.0.616763123847.issue22775@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

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

From report at bugs.python.org  Sun Nov  2 21:22:49 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 20:22:49 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <20141102202244.111398.25306@psf.io>


Roundup Robot added the comment:

New changeset 7be6ef737aaf by Serhiy Storchaka in branch '3.4':
Issue #22775: Fixed unpickling of http.cookies.SimpleCookie with protocol 2
https://hg.python.org/cpython/rev/7be6ef737aaf

New changeset caa8f9248ab8 by Serhiy Storchaka in branch 'default':
Issue #22775: Fixed unpickling of http.cookies.SimpleCookie with protocol 2
https://hg.python.org/cpython/rev/caa8f9248ab8

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

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

From report at bugs.python.org  Sun Nov  2 21:24:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 20:24:49 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1414959889.33.0.367367501948.issue22775@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Tim.

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

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

From report at bugs.python.org  Sun Nov  2 21:37:50 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 20:37:50 +0000
Subject: [issue22775] SimpleCookie not picklable with HIGHEST_PROTOCOL
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <20141102203747.111392.7971@psf.io>


Roundup Robot added the comment:

New changeset 515331e0ca0c by Serhiy Storchaka in branch '2.7':
Issue #22775: Fixed unpickling of Cookie.SimpleCookie with protocol 2.
https://hg.python.org/cpython/rev/515331e0ca0c

----------

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

From report at bugs.python.org  Sun Nov  2 21:39:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 20:39:34 +0000
Subject: [issue22775] SimpleCookie not unpicklable with protocol 2+
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1414960774.12.0.052452054922.issue22775@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This affects 2.7 too.

----------
title: SimpleCookie not picklable with HIGHEST_PROTOCOL -> SimpleCookie not unpicklable with protocol 2+
versions: +Python 2.7

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

From report at bugs.python.org  Sun Nov  2 22:07:03 2014
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 02 Nov 2014 21:07:03 +0000
Subject: [issue22785] range docstring is less useful than in python 2
Message-ID: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The Python 3.4 docstring for range is:
{{{
 |  range(stop) -> range object
 |  range(start, stop[, step]) -> range object
 |
 |  Return a virtual sequence of numbers from start to stop by step.
}}}

In Python 2.7, it said:
{{{
    range(stop) -> list of integers
    range(start, stop[, step]) -> list of integers

    Return a list containing an arithmetic progression of integers.
    range(i, j) returns [i, i+1, i+2, ..., j-1]; start (!) defaults to 0.
    When step is given, it specifies the increment (or decrement).
    For example, range(4) returns [0, 1, 2, 3].  The end point is omitted!
    These are exactly the valid indices for a list of 4 elements.
}}}

Note that Python 3 seems to imply that the end-point is included, while Python 2 made clear that it was not.  "Arithmetic progression" is a bit involved, but it would be good to mention that the end-point is omitted in the Python 3 docstring.

----------
assignee: docs at python
components: Documentation
messages: 230525
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: range docstring is less useful than in python 2
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov  2 23:12:44 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 02 Nov 2014 22:12:44 +0000
Subject: [issue22366] urllib.request.urlopen should take a "context"
 (SSLContext) argument
In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za>
Message-ID: <1414966364.49.0.0421757953598.issue22366@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 3.4

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

From report at bugs.python.org  Mon Nov  3 00:29:37 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Sun, 02 Nov 2014 23:29:37 +0000
Subject: [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1414970977.25.0.580308129824.issue20351@psf.upfronthosting.co.za>


Charles-Axel Dein added the comment:

Sounds good. Do you know when this will get merged?

----------

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

From report at bugs.python.org  Mon Nov  3 02:40:09 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:40:09 +0000
Subject: [issue21759] URL Typo in Documentation FAQ
In-Reply-To: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>
Message-ID: <1414978809.62.0.153951926659.issue21759@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
nosy: +Mike.Short

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

From report at bugs.python.org  Mon Nov  3 02:41:02 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:41:02 +0000
Subject: [issue22317] action argument is not documented in argparse
 add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414978862.03.0.538148483262.issue22317@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
nosy: +Mike.Short

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

From report at bugs.python.org  Mon Nov  3 02:49:09 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:49:09 +0000
Subject: [issue22317] action argument is not documented in argparse
 add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414979349.98.0.246056359363.issue22317@psf.upfronthosting.co.za>


Mike Short added the comment:

I am uploading patches for both 2.7 as well as latest (3.x).  I only added the action verbiage itself in, but would it be beneficial to also add in links to more detailed descriptions similar to what is done in ArgumentParser.add_argument earlier in the argparse page?

----------
keywords: +patch
Added file: http://bugs.python.org/file37115/argparse.patch

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

From report at bugs.python.org  Mon Nov  3 02:49:28 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:49:28 +0000
Subject: [issue22317] action argument is not documented in argparse
 add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414979368.32.0.319573996788.issue22317@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


Added file: http://bugs.python.org/file37116/argparse27.patch

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

From report at bugs.python.org  Mon Nov  3 04:10:01 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Nov 2014 03:10:01 +0000
Subject: [issue22784] test_asyncio fails without the ssl module
In-Reply-To: <1414945257.4.0.921150586656.issue22784@psf.upfronthosting.co.za>
Message-ID: <1414984201.86.0.988813206392.issue22784@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Is something missing from the patch? I don't understand how *not* defining a function can make anything better. Perhaps you need to conditionally skip the test that uses it?

----------

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

From report at bugs.python.org  Mon Nov  3 08:18:18 2014
From: report at bugs.python.org (era)
Date: Mon, 03 Nov 2014 07:18:18 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1414999098.75.0.0673886407392.issue1757072@psf.upfronthosting.co.za>


era added the comment:

For those who cannot update just yet, see also the workaround at http://stackoverflow.com/a/21996397/874188

----------
nosy: +era

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

From report at bugs.python.org  Mon Nov  3 10:38:14 2014
From: report at bugs.python.org (Robert Collins)
Date: Mon, 03 Nov 2014 09:38:14 +0000
Subject: [issue22457] load_tests not invoked in root __init__.py when
 start=package root
In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za>
Message-ID: <1415007494.51.0.82431583659.issue22457@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Added file: http://bugs.python.org/file37118/issue22457.patch

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

From report at bugs.python.org  Mon Nov  3 11:13:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Nov 2014 10:13:11 +0000
Subject: [issue22784] test_asyncio fails without the ssl module
In-Reply-To: <1414945257.4.0.921150586656.issue22784@psf.upfronthosting.co.za>
Message-ID: <1415009591.33.0.286431844706.issue22784@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The problem is the default value for `purpose` in the function declaration (the signature mocks the ssl.create_default_context() function, so I don't think it's ok to change the default parameter value here).

----------

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

From report at bugs.python.org  Mon Nov  3 11:21:35 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 03 Nov 2014 10:21:35 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1415010095.17.0.768712710278.issue22650@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Nice! How do you plan to organize its setup?

----------

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

From report at bugs.python.org  Mon Nov  3 11:32:15 2014
From: report at bugs.python.org (Yongzhi Pan)
Date: Mon, 03 Nov 2014 10:32:15 +0000
Subject: [issue8350] Document lack of support for keyword arguments in C
 functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1415010735.41.0.903179047088.issue8350@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <panyongzhi at gmail.com>:


----------
nosy: +fossilet

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

From report at bugs.python.org  Mon Nov  3 11:44:06 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 03 Nov 2014 10:44:06 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1415011446.66.0.505176949431.issue21650@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file37119/issue21650_v4.diff

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

From report at bugs.python.org  Mon Nov  3 11:53:09 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 03 Nov 2014 10:53:09 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415011989.56.0.000650408516561.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

> I don't want to change the kind of exception being raised (an API change from
> AttributeError to TypeError) without a really good reason.

Subclasses cannot work with the current implementation.

> In general, in-place methods are not required to return NotImplemented (for
> example, (3).__iadd__(4.5) raises an AttributeError).

AttributeError is being raised because int does not have an __iadd__ method, not because of a problem with the float operand.

> Also, I prefer the current AttributeError with its clear indication that an items()
> method is needed for duck-typing.  These kind of error messages are very helpful
> when you're trying to figure-out how to duck-type on-purpose

That's what the docs are for.

> (for example, {}.update(1) and {}.update([[]]) both provide the information about
> what you would need to do to get update() to work).

update is not a binary operation, so has more leeway in how it handles problems.

> The current duck-typeable behavior was an intended part of the design and is no
> different from a number of other methods that update in-place.

The only problem with the design is that it does not play well with others.  For duck-typeable just do a check on 'other' to see if it has an .items() method, and return NotImplemented if it does not.  Oh, and check that 'self' is Counter, and also return NotImplemented if that fails.

> At any rate, I want to avoid unnecessary API churn (and avoid contributing to
> what Guido has called "a death by a thousand cuts" for the growing list of tiny
> semantic differences between Python 2 and Python 3).

Not an issue in this case, as the 2.7 Counter does not have the in-place methods.

Here's proof of subclass trouble -- the idea is to make an immutable Counter:
---------------------------------------------
from collections import Counter

class FrozenCounter(Counter):
    """
    immutable after definition
    """
    def __add__(self, other):
        new_counter = self.__class__()
        for elem, count in self.items():
            new_counter[elem] = count
        for elem, count in other.items():
            new_counter[elem] += count
        return new_counter._keep_positive()
        
fc = FrozenCounter("abbc")
sc = FrozenCounter("bubba")
original = fc
fc += sc
assert fc == FrozenCounter("aabbbbbcu")
assert fc is not original
---------------------------------------------

and the results:
---------------------------------------------
Traceback (most recent call last):
  File "blah.py", line 20, in <module>
    assert fc is not original
AssertionError
---------------------------------------------

For subclassing to work, the fix is:

        if not hasattr(other, 'items') or type(self) is not Counter:
            return NotImplemented

----------

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

From report at bugs.python.org  Mon Nov  3 12:21:12 2014
From: report at bugs.python.org (Nir Soffer)
Date: Mon, 03 Nov 2014 11:21:12 +0000
Subject: [issue6721] Locks in the standard library should be sanitized on fork
In-Reply-To: <1250550378.97.0.072881968798.issue6721@psf.upfronthosting.co.za>
Message-ID: <1415013672.53.0.340057189076.issue6721@psf.upfronthosting.co.za>


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


----------
nosy: +nirs

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

From report at bugs.python.org  Mon Nov  3 12:58:36 2014
From: report at bugs.python.org (=?utf-8?b?SMOla2FuIEzDtnZkYWhs?=)
Date: Mon, 03 Nov 2014 11:58:36 +0000
Subject: [issue22753] urllib2 localnet Changed test to lookup IP-address of
 localhost
In-Reply-To: <1414507628.78.0.884878705537.issue22753@psf.upfronthosting.co.za>
Message-ID: <1415015915.99.0.0368706425531.issue22753@psf.upfronthosting.co.za>


H?kan L?vdahl added the comment:

Yes, I can confirm that changing 'URL' to be 'http://127.0.0.1' works. I think that would be a solution to this.

----------

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

From report at bugs.python.org  Mon Nov  3 14:34:53 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Nov 2014 13:34:53 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1415021693.49.0.716448218296.issue22650@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why a separate domain rather than a subdomain?  I'm not objecting, but I am curious.

----------

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

From report at bugs.python.org  Mon Nov  3 14:49:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Nov 2014 13:49:43 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1415011989.56.0.000650408516561.issue22766@psf.upfronthosting.co.za>
 <1415011989.56.0.000650408516561.issue22766@psf.upfronthosting.co.za>
Message-ID: <20141103134941.2F6DD250230@webabinitio.net>


R. David Murray added the comment:

On Mon, 03 Nov 2014 10:53:09 +0000, Ethan Furman <report at bugs.python.org> wrote:
> 
> Ethan Furman added the comment:
> 
> > I don't want to change the kind of exception being raised (an API change from
> > AttributeError to TypeError) without a really good reason.
> 
> Subclasses cannot work with the current implementation.

I don't understand this statement.

> > Also, I prefer the current AttributeError with its clear indication that an items()
> > method is needed for duck-typing.  These kind of error messages are very helpful
> > when you're trying to figure-out how to duck-type on-purpose
> 
> That's what the docs are for.

That's not the way it works in real life.  You implement something, it
doesn't work, and if the solution isn't obvious from the error message
*then* you look at the docs or google.  But if the error message says
"you can't do this", then like as not you don't even look at the docs.

> > (for example, {}.update(1) and {}.update([[]]) both provide the information about
> > what you would need to do to get update() to work).
> 
> update is not a binary operation, so has more leeway in how it handles problems.

As Raymond pointed out, the augmented assignment operator is a
*shortcut* for update.

> > The current duck-typeable behavior was an intended part of the design and is no
> > different from a number of other methods that update in-place.
> 
> The only problem with the design is that it does not play well with others.  For duck-typeable just do a check on 'other' to see if it has an .items() method, and return NotImplemented if it does not.  Oh, and check that 'self' is Counter, and also return NotImplemented if that fails.

No, that doesn't support duck typing.  Duck typing is not putting
arbitrary restrictions on what objects you accept, but only essential
restrictions.  And as noted above, if you return NotImplemented, then
you get an error message that essentially says "this is impossible"
instead of "this is what didn't work".

> Here's proof of subclass trouble -- the idea is to make an immutable Counter:

Your subclass doesn't override __iadd__ or any of the other mutation
methods.  Why would you expect it to be immutable if it doesn't?

> For subclassing to work, the fix is:
> 
>         if not hasattr(other, 'items') or type(self) is not Counter:
>             return NotImplemented

I've never seen a type check like that in a Python class, and I hope
I never do.  *That* breaks subclassing.

----------

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

From report at bugs.python.org  Mon Nov  3 15:49:41 2014
From: report at bugs.python.org (Wichert Akkerman)
Date: Mon, 03 Nov 2014 14:49:41 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1415026181.19.0.954413420715.issue2504@psf.upfronthosting.co.za>


Wichert Akkerman added the comment:

Bump.

Python 3 is still not on my radar, but I'll happily do a backport for Py2 and drop that on PyPI once this gets resolved.

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

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

From report at bugs.python.org  Mon Nov  3 15:56:08 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 03 Nov 2014 14:56:08 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1415026568.49.0.998920905166.issue2504@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


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

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

From report at bugs.python.org  Mon Nov  3 15:58:49 2014
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 03 Nov 2014 14:58:49 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1415026729.88.0.238575952578.issue22650@psf.upfronthosting.co.za>


Donald Stufft added the comment:

It is configured using salt, see https://github.com/python/psf-salt/blob/master/salt/pythontest/init.sls.

A separate domain just makes it easier to do whatever we need with it without needing to worry about getting confused between live sites and test sites.

----------

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

From report at bugs.python.org  Mon Nov  3 16:09:21 2014
From: report at bugs.python.org (Till Maas)
Date: Mon, 03 Nov 2014 15:09:21 +0000
Subject: [issue22787] ssl.SSLContext.load_cert_chain() backport regression
 with None as keyfile
Message-ID: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>


New submission from Till Maas:

https://github.com/python/cpython/commit/71a4ee3ea2c6847b9fc4b33cbc8d565a7bf2424a

introduces a regression in ssl.SSLContext.load_cert_chain()

https://github.com/python/cpython/blob/2.7/Modules/_ssl.c#L2462

With this change it is not possible to specify None as keyfile which can 
be triggered on Debian Testing? (there the change is backported) in requests.get("https://example.com", cerf="keycert.pem"). It can also be triggered with the sample code in the attached file. It is fixed in recent python 3.

----------
components: Library (Lib)
files: poc.txt
messages: 230539
nosy: till
priority: normal
severity: normal
status: open
title: ssl.SSLContext.load_cert_chain() backport regression with None as keyfile
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37120/poc.txt

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

From report at bugs.python.org  Mon Nov  3 16:10:07 2014
From: report at bugs.python.org (Till Maas)
Date: Mon, 03 Nov 2014 15:10:07 +0000
Subject: [issue22787] ssl.SSLContext.load_cert_chain() backport regression
 with None as keyfile
In-Reply-To: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>
Message-ID: <1415027407.96.0.550467336815.issue22787@psf.upfronthosting.co.za>


Till Maas added the comment:

sorry, it should be:
    requests.get("https://example.com", cert="keycert.pem")

----------

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

From report at bugs.python.org  Mon Nov  3 16:12:46 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 15:12:46 +0000
Subject: [issue22787] ssl.SSLContext.load_cert_chain() backport regression
 with None as keyfile
In-Reply-To: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>
Message-ID: <1415027566.02.0.449577045934.issue22787@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou

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

From report at bugs.python.org  Mon Nov  3 16:21:23 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 15:21:23 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1415028083.1.0.82299318667.issue22417@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

% ./python Lib/test/regrtest.py -v test_urllib2_localnet
== CPython 3.4.2+ (3.4:7be6ef737aaf+, Nov 3 2014, 10:03:11) [GCC 4.8.3]
==   Linux-3.16.5-gentoo-x86_64-Intel-R-_Core-TM-_i7-2860QM_CPU_ at _2.50GHz-with-gentoo-2.2 little-endian
==   hash algorithm: siphash24 64bit
==   /home/benjamin/dev/python/3.4/build/test_python_28724
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_urllib2_localnet
test_basic_auth_httperror (test.test_urllib2_localnet.BasicAuthTests) ... ok
test_basic_auth_success (test.test_urllib2_localnet.BasicAuthTests) ... ok
test_proxy_qop_auth_int_works_or_throws_urlerror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_bad_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_proxy_with_no_password_raises_httperror (test.test_urllib2_localnet.ProxyAuthTests) ... ok
test_200 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_200_with_parameters (test.test_urllib2_localnet.TestUrlopen) ... ok
test_404 (test.test_urllib2_localnet.TestUrlopen) ... ok
test_bad_address (test.test_urllib2_localnet.TestUrlopen) ... skipped "Use of the 'network' resource not enabled"
test_basic (test.test_urllib2_localnet.TestUrlopen) ... ok
test_chunked (test.test_urllib2_localnet.TestUrlopen) ... ok
test_geturl (test.test_urllib2_localnet.TestUrlopen) ... ok
test_https (test.test_urllib2_localnet.TestUrlopen) ... Got an error:
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:600)
stopping HTTPS server
joining HTTPS thread
ERROR
test_https_sni (test.test_urllib2_localnet.TestUrlopen) ... Got an error:
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:600)
stopping HTTPS server
joining HTTPS thread
ERROR
test_https_with_cadefault (test.test_urllib2_localnet.TestUrlopen) ... stopping HTTPS server
Got an error:
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:600)
joining HTTPS thread
ok
test_https_with_cafile (test.test_urllib2_localnet.TestUrlopen) ... Got an error:
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:600)
stopping HTTPS server
joining HTTPS thread
stopping HTTPS server
joining HTTPS thread
ok
test_info (test.test_urllib2_localnet.TestUrlopen) ... ok
test_iteration (test.test_urllib2_localnet.TestUrlopen) ... ok
test_line_iteration (test.test_urllib2_localnet.TestUrlopen) ... ok
test_redirection (test.test_urllib2_localnet.TestUrlopen) ... ok
test_sending_headers (test.test_urllib2_localnet.TestUrlopen) ... ok

======================================================================
ERROR: test_https (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 1182, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1090, in request
    self._send_request(method, url, body, headers)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1128, in _send_request
    self.endheaders(body)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1086, in endheaders
    self._send_output(message_body)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 924, in _send_output
    self.send(msg)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 859, in send
    self.connect()
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1230, in connect
    server_hostname=sni_hostname)
  File "/home/benjamin/dev/python/3.4/Lib/ssl.py", line 364, in wrap_socket
    _context=self)
  File "/home/benjamin/dev/python/3.4/Lib/ssl.py", line 584, in __init__
    self.do_handshake()
  File "/home/benjamin/dev/python/3.4/Lib/ssl.py", line 811, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/benjamin/dev/python/3.4/Lib/test/test_urllib2_localnet.py", line 548, in test_https
    data = self.urlopen("https://localhost:%s/bizarre" % handler.port)
  File "/home/benjamin/dev/python/3.4/Lib/test/test_urllib2_localnet.py", line 455, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 161, in urlopen
    return opener.open(url, data, timeout)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 463, in open
    response = self._open(req, data)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 481, in _open
    '_open', req)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 441, in _call_chain
    result = func(*args)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 1225, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 1184, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)>

======================================================================
ERROR: test_https_sni (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 1182, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1090, in request
    self._send_request(method, url, body, headers)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1128, in _send_request
    self.endheaders(body)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1086, in endheaders
    self._send_output(message_body)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 924, in _send_output
    self.send(msg)
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 859, in send
    self.connect()
  File "/home/benjamin/dev/python/3.4/Lib/http/client.py", line 1230, in connect
    server_hostname=sni_hostname)
  File "/home/benjamin/dev/python/3.4/Lib/ssl.py", line 364, in wrap_socket
    _context=self)
  File "/home/benjamin/dev/python/3.4/Lib/ssl.py", line 584, in __init__
    self.do_handshake()
  File "/home/benjamin/dev/python/3.4/Lib/ssl.py", line 811, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/benjamin/dev/python/3.4/Lib/test/test_urllib2_localnet.py", line 587, in test_https_sni
    self.urlopen("https://localhost:%s" % handler.port)
  File "/home/benjamin/dev/python/3.4/Lib/test/test_urllib2_localnet.py", line 455, in urlopen
    f = urllib.request.urlopen(url, data, **kwargs)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 161, in urlopen
    return opener.open(url, data, timeout)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 463, in open
    response = self._open(req, data)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 481, in _open
    '_open', req)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 441, in _call_chain
    result = func(*args)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 1225, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/home/benjamin/dev/python/3.4/Lib/urllib/request.py", line 1184, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)>

----------------------------------------------------------------------
Ran 22 tests in 3.087s

----------

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

From report at bugs.python.org  Mon Nov  3 16:23:37 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 15:23:37 +0000
Subject: [issue22787] ssl.SSLContext.load_cert_chain() backport regression
 with None as keyfile
In-Reply-To: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>
Message-ID: <1415028217.88.0.973722923594.issue22787@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file37121/issue22787.diff

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

From report at bugs.python.org  Mon Nov  3 16:23:44 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 15:23:44 +0000
Subject: [issue22787] ssl.SSLContext.load_cert_chain() backport regression
 with None as keyfile
In-Reply-To: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>
Message-ID: <1415028224.9.0.691529903291.issue22787@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
keywords: +needs review

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

From report at bugs.python.org  Mon Nov  3 16:28:41 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 15:28:41 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1415028521.72.0.269890367256.issue22417@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Latest patch fixes the urllib2_localnet tests.

----------
Added file: http://bugs.python.org/file37122/issue22417.diff

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

From report at bugs.python.org  Mon Nov  3 16:54:24 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Nov 2014 15:54:24 +0000
Subject: [issue22784] test_asyncio fails without the ssl module
In-Reply-To: <1414945257.4.0.921150586656.issue22784@psf.upfronthosting.co.za>
Message-ID: <1415030064.96.0.182663146407.issue22784@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, them LGTM.

----------

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

From report at bugs.python.org  Mon Nov  3 16:56:36 2014
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 03 Nov 2014 15:56:36 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415030196.86.0.621699990068.issue22766@psf.upfronthosting.co.za>


Jim Jewett added the comment:

If I know that a Counter (or any class X) can be updated in place, I will be surprised to find out that I'm using a different instance after a successful in-place operation.

I would even consider that (replacement of the original instance) a security risk, though it is mitigated by the fact that I don't see how to exploit it without already being able to create arbitrary subclasses.

> For subclassing to work, the fix is:
> 
>         if not hasattr(other, 'items') or type(self) is not Counter:
>             return NotImplemented

That breaks for Counter subclasses on the left hand side -- even a trivial subclass to change the repr would fail unless the _i* methods were all re-implemented, either by the otherwise-trivial Counter subclass or by the right-hand objects.  If you start making it work for the obvious cases, you just make the failure conditions more obscure.

----------
nosy: +Jim.Jewett

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

From report at bugs.python.org  Mon Nov  3 17:43:16 2014
From: report at bugs.python.org (Steve Dower)
Date: Mon, 03 Nov 2014 16:43:16 +0000
Subject: [issue22676] _pickle's whichmodule() is slow
In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>
Message-ID: <1415032996.59.0.790820141967.issue22676@psf.upfronthosting.co.za>


Steve Dower added the comment:

The fix for this now uses module without initializing it, which could lead to a crash if get_dotted_path() tries to raise an exception (it puts module into the error string with %R). See Modules/_pickle.c#l1656 and Modules/_pickle.c#l1538.

I think the fix is to initialize module with Py_None and currently there's no need to bump the refcount (though I'm always wary of doing that in case things change in the future). If that sounds right I'm happy to put the fix in, else Antoine can do it :)

----------
nosy: +steve.dower

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

From report at bugs.python.org  Mon Nov  3 17:43:57 2014
From: report at bugs.python.org (Steve Dower)
Date: Mon, 03 Nov 2014 16:43:57 +0000
Subject: [issue22676] _pickle's whichmodule() is slow
In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>
Message-ID: <1415033037.43.0.618461541364.issue22676@psf.upfronthosting.co.za>


Steve Dower added the comment:

(Looks like I was outsmarted by the tracker when trying to put line numbers in my links... is there a way to do that?)

----------

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

From report at bugs.python.org  Mon Nov  3 18:38:25 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 03 Nov 2014 17:38:25 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415036305.25.0.181235090408.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Ethan stated:
>> The only problem with the design is that it does not play well with others.  For
>> duck-typeable just do a check on 'other' to see if it has an .items() method, and
>> return NotImplemented if it does not.  Oh, and check that 'self' is Counter, and
>> also return NotImplemented if that fails.

R. David Murray replied:
> No, that doesn't support duck typing.  Duck typing is not putting arbitrary
> restrictions on what objects you accept, but only essential restrictions.

__iadd__ will raise an AttributeError if 'other' doesn't have an 'items' method -- how is that an arbitrary restriction?

If 'other' doesn't have an 'items' but does know how to add itself to Counter, it won't matter because Counter is raising an exception instead of returning NotImplemented.  

What other types return NotImplemented when 'other' is not the expected (sub)type?  bytes, bytearray, int, float, string, dict, list, tuple, Enum, deque, defaultdict, OrderedDict, Decimal, Fraction, and Counter itself for every binary method /except/ the four inplace ops it supplies itself.

> And as noted above, if you return NotImplemented, then you get an error message
> that essentially says "this is impossible" instead of "this is what didn't work".

Correct implementation should not be sacrificed for a nicer error message.

>> Here's proof of subclass trouble -- the idea is to make an immutable Counter:
>> [snip example]

> Your subclass doesn't override __iadd__ or any of the other mutation methods.  Why
> would you expect it to be immutable if it doesn't?

You're right, that was a bad example.  A subclass would need to override any method whose behavior it wants to change.

What does not seem correct to me is raising an exception because the type of 'other' is not correct, instead of returning NotImplemented, and in 14 other core datatypes it does work that way, and even in Counter it works that way for any in-place method that Counter itself doesn't override, and it does work that way /in/ Counter for the normal binary ops that it /does/ override.

> For subclassing to work, the fix is:
> 
>         if not hasattr(other, 'items') or type(self) is not Counter:
>             return NotImplemented

>> I've never seen a type check like that in a Python class, and I hope I never do.  *That*
>> breaks subclassing.

Explanations and examples go a lot further than bare statements.

[Jim Jewitt posts an explanation.]

Ah, I see.  Thank you, Jim.

Okay, I agree that the check against the base class is ill-advised (and I modified some of the above reply to match that understanding).

However, I am still unconvinced that 'other' should not be checked.  Hopefully the python-dev thread will shed more light on this.

----------

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

From report at bugs.python.org  Mon Nov  3 18:50:52 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 17:50:52 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1415037052.78.0.215427457422.issue22417@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Fix for the failing test_ssl testes.

----------
Added file: http://bugs.python.org/file37123/issue22417.diff

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

From report at bugs.python.org  Mon Nov  3 19:49:27 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 18:49:27 +0000
Subject: [issue22788] allow HTTPHandler to take an SSLContext
Message-ID: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

It would be nice if HTTPHandler could take an SSLContext as a parameter, which would be passed to HTTPSConnection to configure the security of the connection.

----------
components: Library (Lib)
messages: 230549
nosy: benjamin.peterson, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: allow HTTPHandler to take an SSLContext
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov  3 20:08:56 2014
From: report at bugs.python.org (Silvio Ricardo Cordeiro)
Date: Mon, 03 Nov 2014 19:08:56 +0000
Subject: [issue1539381] Add readinto method to StringIO and cStringIO
Message-ID: <1415041736.13.0.525903340437.issue1539381@psf.upfronthosting.co.za>


Silvio Ricardo Cordeiro added the comment:

BufferedReader assumes that readinto is defined, but that's not the case for StringIO's. In the end, this cripples StringIO objects, because their data can never be peek()'ed as with all other file objects.

----------
components: +IO -Library (Lib)
nosy: +silvioricardoc
type:  -> behavior
versions: +Python 2.7, Python 3.2 -Python 2.6

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

From report at bugs.python.org  Mon Nov  3 20:33:14 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 19:33:14 +0000
Subject: [issue22788] allow HTTPHandler to take an SSLContext
In-Reply-To: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>
Message-ID: <1415043194.08.0.12253804989.issue22788@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

I'm not sure I follow, where does HTTPHandler ever construct an HTTPSConnection?

----------
nosy: +alex

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

From report at bugs.python.org  Mon Nov  3 20:33:43 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 19:33:43 +0000
Subject: [issue22788] allow HTTPHandler to take an SSLContext
In-Reply-To: <1415043194.08.0.12253804989.issue22788@psf.upfronthosting.co.za>
Message-ID: <1415043220.2696900.186580369.561888AC@webmail.messagingengine.com>


Benjamin Peterson added the comment:

emit()

On Mon, Nov 3, 2014, at 15:33, Alex Gaynor wrote:
> 
> Alex Gaynor added the comment:
> 
> I'm not sure I follow, where does HTTPHandler ever construct an
> HTTPSConnection?
> 
> ----------
> nosy: +alex
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22788>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Nov  3 20:37:18 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 19:37:18 +0000
Subject: [issue22788] allow HTTPHandler to take an SSLContext
In-Reply-To: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>
Message-ID: <1415043438.06.0.739206975523.issue22788@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Hah! I didn't realize you meant *logging.handlers.HTTPHandler*, I thought you meant *urllib.request.HTTPHandler*.

----------

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

From report at bugs.python.org  Mon Nov  3 20:37:21 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 03 Nov 2014 19:37:21 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <20141103193653.109268.1594@psf.io>


Roundup Robot added the comment:

New changeset 2afe5413d7af by Benjamin Peterson in branch '3.4':
PEP 476: enable HTTPS certificate verification by default (#22417)
https://hg.python.org/cpython/rev/2afe5413d7af

New changeset 731375f83406 by Benjamin Peterson in branch 'default':
merge 3.4 (#22417)
https://hg.python.org/cpython/rev/731375f83406

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

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

From report at bugs.python.org  Mon Nov  3 20:37:43 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 19:37:43 +0000
Subject: [issue22788] allow logging.handlers.HTTPHandler to take an SSLContext
In-Reply-To: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>
Message-ID: <1415043463.63.0.235818133332.issue22788@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Right then...

----------
title: allow HTTPHandler to take an SSLContext -> allow logging.handlers.HTTPHandler to take an SSLContext

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

From report at bugs.python.org  Mon Nov  3 20:39:45 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 19:39:45 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1415043585.33.0.494177295521.issue22417@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Okay, 3.4/3.5 have been dealt with. I had to hack up test_logging a bit. (#22788 would make that better). 2.7 now needs a backport.

----------

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

From report at bugs.python.org  Mon Nov  3 20:50:20 2014
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Mon, 03 Nov 2014 19:50:20 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1415044220.04.0.876314592211.issue7559@psf.upfronthosting.co.za>


Domen Ko?ar added the comment:

Could we backport this one to 3.x and 2.7? It's leads to really bad UX.

----------

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

From report at bugs.python.org  Mon Nov  3 21:00:58 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 03 Nov 2014 20:00:58 +0000
Subject: [issue22788] allow logging.handlers.HTTPHandler to take an SSLContext
In-Reply-To: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>
Message-ID: <1415044858.28.0.358479088739.issue22788@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Quick pass at a patch. No docs, and it should proabbly be an error to pass context with secure=False.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file37124/issue22788.diff

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

From report at bugs.python.org  Mon Nov  3 21:21:46 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 03 Nov 2014 20:21:46 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415046106.85.0.444028052201.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, the python-dev ruling is in, and raising an exception in the __ixxx__ methods is allowed, and even a good idea in the cases of mutable containers.

However, doing the check on 'other' and raising a TypeError with an appropriate message would still be better for a couple reasons:

  - all the non-inplace operations raise TypeError when 'other' is not a correct type
  - __iand__ is currently buggy because it does not do the check

If backwards compatibility is a concern in this case, a custom "TypeError" that was a subclass of both TypeError and AttributeError could address that.

----------

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

From report at bugs.python.org  Mon Nov  3 21:36:31 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 20:36:31 +0000
Subject: [issue22735] Fix various crashes exposed through mro() customization
In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za>
Message-ID: <1415046990.99.0.656463331723.issue22735@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Thank you for the patchset. I wonder if we should just forbid most reentrancy i.e. set a flag on the type when it's being constructed and not let type_set_bases be called then. Setting __bases__ from within mro() doesn't seem very useful outside of producing pathologies.

----------

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

From report at bugs.python.org  Mon Nov  3 21:37:18 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 03 Nov 2014 20:37:18 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415047038.39.0.213432984086.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

+   Special value which should be returned by the special methods
+   (:meth:`__eq__`, :meth:`__lt__`, :meth:`__add__`, etc.) to indicate
+   that the operation is not implemented with respect to the other type.

After a discussion on python-dev, I think this wording could be even clearer.  How about:

    Special value which should be returned by the binary special methods
    (e.g. :meth:`__eq__`, :meth:`__lt__`, :meth:`__add__`, :meth:`__rsub__`,
    etc.) to indicate that the operation is not implemented with respect to
    the other type; may be returned by the in-place binary special methods
    (e.g. :meth:`__imul__`, :meth:`__iand__`, etc.) for the same purpose.

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

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

From report at bugs.python.org  Mon Nov  3 21:40:56 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 03 Nov 2014 20:40:56 +0000
Subject: [issue22366] urllib.request.urlopen should take a "context"
 (SSLContext) argument
In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za>
Message-ID: <1415047256.89.0.882555584139.issue22366@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Please update versionchanged to 3.4.3 on default branch.

----------

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

From report at bugs.python.org  Mon Nov  3 21:49:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Nov 2014 20:49:41 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1415047781.65.0.151149324419.issue21650@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

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

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

From report at bugs.python.org  Mon Nov  3 21:56:26 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Nov 2014 20:56:26 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415048186.46.0.575150875023.issue22780@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds OK to me.  There should already be a discussion of the consequences of returning it (I don't remember where, though), and it would be nice to link to that discussion.

Note that any doc change should be applied to 3.4 first, and then merged to 3.5.

----------
versions: +Python 3.4

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

From report at bugs.python.org  Mon Nov  3 21:57:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Nov 2014 20:57:05 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1415048225.19.0.202651848954.issue7559@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would love that, but I think the fix depends on a feature.  Robert will know for sure.

----------

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

From report at bugs.python.org  Mon Nov  3 22:49:22 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 03 Nov 2014 21:49:22 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415051362.3.0.264720335774.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I found these items:

Doc/c-api/object.rst
--------------------
.. c:var:: PyObject* Py_NotImplemented

   The ``NotImplemented`` singleton, used to signal that an operation is
   not implemented for the given type combination.


Doc/extending/newtypes.rst
---------------------------
where the operator is one of ``Py_EQ``, ``Py_NE``, ``Py_LE``, ``Py_GT``,
``Py_LT`` or ``Py_GT``.  It should compare the two objects with respect to the
specified operator and return ``Py_True`` or ``Py_False`` if the comparison is
successful, ``Py_NotImplemented`` to indicate that comparison is not
implemented and the other object's comparison method should be tried, or *NULL*
if an exception was set.


Doc/Library/numbers.rst
-----------------------
Implementing the arithmetic operations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

We want to implement the arithmetic operations so that mixed-mode
operations either call an implementation whose author knew about the
types of both arguments, or convert both to the nearest built in type
and do the operation there. For subtypes of :class:`Integral`, this
means that :meth:`__add__` and :meth:`__radd__` should be defined as::

    class MyIntegral(Integral):

        def __add__(self, other):
            if isinstance(other, MyIntegral):
                return do_my_adding_stuff(self, other)
            elif isinstance(other, OtherTypeIKnowAbout):
                return do_my_other_adding_stuff(self, other)
            else:
                return NotImplemented

        def __radd__(self, other):
            if isinstance(other, MyIntegral):
                return do_my_adding_stuff(other, self)
            elif isinstance(other, OtherTypeIKnowAbout):
                return do_my_other_adding_stuff(other, self)
            elif isinstance(other, Integral):
                return int(other) + int(self)
            elif isinstance(other, Real):
                return float(other) + float(self)
            elif isinstance(other, Complex):
                return complex(other) + complex(self)
            else:
                return NotImplemented


There are 5 different cases for a mixed-type operation on subclasses
of :class:`Complex`. I'll refer to all of the above code that doesn't
refer to ``MyIntegral`` and ``OtherTypeIKnowAbout`` as
"boilerplate". ``a`` will be an instance of ``A``, which is a subtype
of :class:`Complex` (``a : A <: Complex``), and ``b : B <:
Complex``. I'll consider ``a + b``:

    1. If ``A`` defines an :meth:`__add__` which accepts ``b``, all is
       well.
    2. If ``A`` falls back to the boilerplate code, and it were to
       return a value from :meth:`__add__`, we'd miss the possibility
       that ``B`` defines a more intelligent :meth:`__radd__`, so the
       boilerplate should return :const:`NotImplemented` from
       :meth:`__add__`. (Or ``A`` may not implement :meth:`__add__` at
       all.)
    3. Then ``B``'s :meth:`__radd__` gets a chance. If it accepts
       ``a``, all is well.
    4. If it falls back to the boilerplate, there are no more possible
       methods to try, so this is where the default implementation
       should live.
    5. If ``B <: A``, Python tries ``B.__radd__`` before
       ``A.__add__``. This is ok, because it was implemented with
       knowledge of ``A``, so it can handle those instances before
       delegating to :class:`Complex`.


Doc/library/datetime.rst
------------------------
   In other words, ``date1 < date2`` if and only if ``date1.toordinal() <
   date2.toordinal()``. In order to stop comparison from falling back to the
   default scheme of comparing object addresses, date comparison normally raises
   :exc:`TypeError` if the other comparand isn't also a :class:`date` object.
   However, ``NotImplemented`` is returned instead if the other comparand has a
   :meth:`timetuple` attribute.  This hook gives other kinds of date objects a
   chance at implementing mixed-type comparison. If not, when a :class:`date`
   object is compared to an object of a different type, :exc:`TypeError` is raised
   unless the comparison is ``==`` or ``!=``.  The latter cases return
   :const:`False` or :const:`True`, respectively.


Doc/reference/expressions.rst
-----------------------------
Comparisions
============
...
Comparison of objects of differing types depends on whether either of the
types provide explicit support for the comparison.  Most numeric types can be
compared with one another.  When cross-type comparison is not supported, the
comparison method returns ``NotImplemented``.


Ahha!  I think I found it (nearly at the end, of course):

Doc/reference/datamodel.rst
---------------------------
The standard type hierarchy
===========================
...
NotImplemented
   .. index:: object: NotImplemented

   This type has a single value.  There is a single object with this value. This
   object is accessed through the built-in name ``NotImplemented``. Numeric methods
   and rich comparison methods may return this value if they do not implement the
   operation for the operands provided.  (The interpreter will then try the
   reflected operation, or some other fallback, depending on the operator.)  Its
   truth value is true.

----------

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

From report at bugs.python.org  Mon Nov  3 23:09:42 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 03 Nov 2014 22:09:42 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415052582.75.0.503159460043.issue22780@psf.upfronthosting.co.za>


R. David Murray added the comment:

I was actually thinking of the Implementing the arithmetic operations section.  Maybe we should copy the parenthetical from the datamodel description into the text you are modifying, and then link to the implementing section.

----------

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

From report at bugs.python.org  Mon Nov  3 23:41:25 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 03 Nov 2014 22:41:25 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1415054485.65.0.580828961111.issue22417@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Somehow the Windows bots are failing to verify python.org http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/11179/steps/test/logs/stdio

----------

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

From report at bugs.python.org  Tue Nov  4 00:49:31 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 03 Nov 2014 23:49:31 +0000
Subject: [issue22788] allow logging.handlers.HTTPHandler to take an SSLContext
In-Reply-To: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>
Message-ID: <1415058571.71.0.584911168724.issue22788@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Nov  4 00:59:07 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 03 Nov 2014 23:59:07 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1415059147.8.0.191175330536.issue22650@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Not to mention possible cookie tests, I suppose.
(I would personally have preferred something like "comfychair.net", but I guess pythontest.net is ok too :-))

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Nov  4 03:11:09 2014
From: report at bugs.python.org (Tim Graham)
Date: Tue, 04 Nov 2014 02:11:09 +0000
Subject: [issue826897] Proto 2 pickle vs dict subclass
Message-ID: <1415067069.32.0.383031853664.issue826897@psf.upfronthosting.co.za>


Tim Graham added the comment:

Cookie pickling issue should be fixed in #22775.

----------
nosy: +Tim.Graham

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

From report at bugs.python.org  Tue Nov  4 03:12:21 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 02:12:21 +0000
Subject: [issue22787] ssl.SSLContext.load_cert_chain() backport regression
 with None as keyfile
In-Reply-To: <1415027361.25.0.159833627415.issue22787@psf.upfronthosting.co.za>
Message-ID: <20141104021216.85196.8511@psf.io>


Roundup Robot added the comment:

New changeset e54d0b197c82 by Benjamin Peterson in branch '2.7':
allow keyfile argument to be None (closes #22787)
https://hg.python.org/cpython/rev/e54d0b197c82

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

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

From report at bugs.python.org  Tue Nov  4 03:14:45 2014
From: report at bugs.python.org (Tim Graham)
Date: Tue, 04 Nov 2014 02:14:45 +0000
Subject: [issue22758] Regression in Python 3.2 cookie parsing
In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za>
Message-ID: <1415067285.81.0.702174982649.issue22758@psf.upfronthosting.co.za>


Tim Graham added the comment:

Georg, how do want to proceed with this issue? Should we backport #16611 (support for parsing secure/httponly flag) to 3.2 to fix this regression and then create a separate issue to fix the lax parsing issue on all versions?

----------

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

From report at bugs.python.org  Tue Nov  4 05:25:04 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 04 Nov 2014 04:25:04 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1415075104.38.0.409697295325.issue20160@psf.upfronthosting.co.za>


Steve Dower added the comment:

Patch looks good to me, but given this issue, #11835, #22733, and probably more, should we be integrating from libffi (which apparently has fixes for some of these) more often? I know nothing about how we move code between that and ctypes.

----------
nosy: +steve.dower

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

From report at bugs.python.org  Tue Nov  4 05:46:26 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Nov 2014 04:46:26 +0000
Subject: [issue17896] Move Windows external libs from <src>\..\ to
 <src>\externals
In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za>
Message-ID: <1415076386.07.0.922631389698.issue17896@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Good point, David.  Jeremy, Trent, you're the only other Windows buildbot operators as far as I know; feel free to clean up the old externals locations as you like.

Also, sorry to make it a bit hairier to operate, but I think this is a big enough improvement for day-to-day development that I definitely don't want to change back.  For the record, it is fairly easy to just move out the externals folder, do whatever you need to with the repository, and move it back in without having to rebuild OpenSSL or Tcl/Tk/Tix.

----------
nosy: +jeremy.kloth

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

From report at bugs.python.org  Tue Nov  4 05:56:17 2014
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 04 Nov 2014 04:56:17 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415076977.35.0.913395315014.issue22725@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

@raymond

Why do you say that 'sequence' is a keyword?

>>> enumerate()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Required argument 'sequence' (pos 1) not found

That means that 'sequence' can be changed to 'iterable' without worrying about backwards compatibility.

----------
nosy: +tshepang

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

From report at bugs.python.org  Tue Nov  4 06:00:45 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 05:00:45 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
Message-ID: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Save space and reduce I/O time (reading and writing) by compressing the marshaled code in  files.

In my code tree for Python 3, there was a nice space savings 19M to 7M.  Here's some of the output from my test:

    8792 ->     4629 ./Tools/scripts/__pycache__/reindent.cpython-35.pyc
    1660 ->     1063 ./Tools/scripts/__pycache__/rgrep.cpython-35.pyc
    1995 ->     1129 ./Tools/scripts/__pycache__/run_tests.cpython-35.pyc
    1439 ->      973 ./Tools/scripts/__pycache__/serve.cpython-35.pyc
     727 ->      498 ./Tools/scripts/__pycache__/suff.cpython-35.pyc
    3240 ->     1808 ./Tools/scripts/__pycache__/svneol.cpython-35.pyc
   74866 ->    23611 ./Tools/scripts/__pycache__/texi2html.cpython-35.pyc
    5562 ->     2870 ./Tools/scripts/__pycache__/treesync.cpython-35.pyc
    1492 ->      970 ./Tools/scripts/__pycache__/untabify.cpython-35.pyc
    1414 ->      891 ./Tools/scripts/__pycache__/which.cpython-35.pyc
19627963 ->  6976410 Total

I haven't measured it yet, but I believe this will improve Python's start-up time (because fewer bytes get transferred from disk).

----------
files: compress_pyc.py
messages: 230576
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Compress the marshalled data in PYC files
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37125/compress_pyc.py

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

From report at bugs.python.org  Tue Nov  4 06:15:10 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 04 Nov 2014 05:15:10 +0000
Subject: [issue22719] os.path.isfile & os.path.exists bug in while loop
In-Reply-To: <1414166412.24.0.659144032685.issue22719@psf.upfronthosting.co.za>
Message-ID: <1415078110.06.0.0662956257256.issue22719@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Aaron, what version of Python are you using on what version of Windows?  Also, 32 or 64 bit on both?

I can't reproduce this with any Python 3.3.6 or newer on 64-bit Windows 8.1.

----------

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

From report at bugs.python.org  Tue Nov  4 06:22:06 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 05:22:06 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415078526.14.0.264691745755.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

static PyObject *
> Why do you say that 'sequence' is a keyword?

It is a keyword argument to enumerate().  Here's the relevant section of code:

enum_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
    enumobject *en;
    PyObject *seq = NULL;
    PyObject *start = NULL;
    static char *kwlist[] = {"sequence", "start", 0};

    if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|O:enumerate", kwlist,
                                     &seq, &start))
        return NULL

----------

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

From report at bugs.python.org  Tue Nov  4 06:38:17 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 05:38:17 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415079497.68.0.279190620958.issue22780@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I think doc changes like this need to be made by the people most familiar with the implementation details and with the original design intent (i.e. the authors of PEP 207).

The knowledge here is fragile and it would be easy to accidentally make-up new normative rules that aren't actually true or necessary, or to subtly misrepresent what was trying to be accomplished originally.  The risk is greatest when the OP is just now learning the ins and outs of NotImplemented (i.e. whether in-place operations can or should return NotImplemeted or whether those operations can be duck typed).

Changing "can be returned" to "should be returned" is normative (making-up a new rule without sufficient discussion).  This doesn't add explanation; instead, instead, it make a rule change about how a feature should be used.
https://hg.python.org/cpython/rev/26d0a17affb5

----------
nosy: +gvanrossum, rhettinger, tim.peters

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

From report at bugs.python.org  Tue Nov  4 06:41:27 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 05:41:27 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415079687.01.0.733017493122.issue22780@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  4 07:09:19 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 06:09:19 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415081359.85.0.747223743536.issue22789@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Looking into this further, I suspect that the cleanest way to implement this would be to add a marshal version 4 that compresses and decompresses using zlib.

----------
components: +Interpreter Core
nosy: +brett.cannon, pitrou

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

From report at bugs.python.org  Tue Nov  4 07:16:46 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 06:16:46 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415081806.21.0.684341671643.issue22789@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Looking into this further, I suspect that the cleanest way to implement this would be to add a zlib compression and decompression using to the marshal.c (bumping the version number to 5).

----------

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

From report at bugs.python.org  Tue Nov  4 07:16:55 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 06:16:55 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415081815.25.0.684964515113.issue22789@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  4 08:06:21 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 04 Nov 2014 07:06:21 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415084781.77.0.328926001659.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thank you, Raymond, both for your concern and your discretion.

My interest in changing the "can" or "may" to "should" is that, whatever the original intent of the PEP, the way Python works /now/ is that any class that doesn't return NotImplemented when it /should/ is not going to interoperate well with other compatible classes.

At the heart of the issue is what happens when

  def bin_op(self, other):
     ...

is called, but the left-hand operand doesn't know how to work with the right-hand operand?

We have three choices:

  - do nothing, letting any exceptions boil up or errors propagate

  - do a check on 'other' to determine if it's usable, and raise an exception
    if it is not

  - do a check on 'other' to determine if it's usable, and return NotImplemented
    if it is not

Only the last choice allows 'other' to also try the operation.  Except for the special-case of in-place bin-ops, why would we not want choice three?

----------

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

From report at bugs.python.org  Tue Nov  4 08:19:06 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Nov 2014 07:19:06 +0000
Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad
 argument
In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za>
Message-ID: <1415085546.04.0.557900659292.issue21931@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I haven't had any time to work on Python in the last year, so it may take some more time for me to look into this.

----------

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

From report at bugs.python.org  Tue Nov  4 08:38:36 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 04 Nov 2014 07:38:36 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415086716.09.0.235080936826.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

How about:

    Special value which should be returned by the binary special methods
    (e.g. :meth:`__eq__`, :meth:`__lt__`, :meth:`__add__`, :meth:`__rsub__`,
    etc.) to indicate that the operation is not implemented with respect to
    the other type; may be returned by the in-place binary special methods
    (e.g. :meth:`__imul__`, :meth:`__iand__`, etc.) for the same purpose.
    Its truth value is true.

    Note::
    When NotImplemented is returned, the interpreter will then try the
    reflected operation on the other type, or some other fallback, depending
    on the operator.  If all attempted operations return NotImplemented, the
    interpreter will raise an appropriate exception.


I have no idea how to create a link to the 'Implementing the arithmetic operations' section.  Any clues?

----------

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

From report at bugs.python.org  Tue Nov  4 08:46:13 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 07:46:13 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415087173.29.0.0250210342381.issue22780@psf.upfronthosting.co.za>


Georg Brandl added the comment:

You add a label before that section and then reference it with :ref:.

----------

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

From report at bugs.python.org  Tue Nov  4 08:47:08 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 07:47:08 +0000
Subject: [issue22758] Regression in Python 3.2 cookie parsing
In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za>
Message-ID: <1415087228.28.0.964424875261.issue22758@psf.upfronthosting.co.za>


Georg Brandl added the comment:

That seems like the best course of action.

----------

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

From report at bugs.python.org  Tue Nov  4 08:47:25 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 07:47:25 +0000
Subject: [issue22775] SimpleCookie not unpicklable with protocol 2+
In-Reply-To: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>
Message-ID: <1415087245.54.0.366218256956.issue22775@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks!

----------

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

From report at bugs.python.org  Tue Nov  4 08:50:21 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 07:50:21 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1415087421.14.0.606475432531.issue22695@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

----------

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

From report at bugs.python.org  Tue Nov  4 09:08:34 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 08:08:34 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415088514.75.0.869232202728.issue22780@psf.upfronthosting.co.za>


R. David Murray added the comment:

"try the reflected operation" is not our standard terminology.  There is a reason I suggested *copying* the parenthetical statement.  We essentially have two places where NotImplemented is described (language reference and library reference), and the parenthetical is the only substantial piece of information present in one that is not present in the other.

----------

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

From report at bugs.python.org  Tue Nov  4 09:10:37 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 08:10:37 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415088637.95.0.00433196200754.issue22725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Specifically, this works (in 2.7):

  >>> enumerate(sequence=myvar)

Changing sequence to iterable would break any code that was written like the above.

----------

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

From report at bugs.python.org  Tue Nov  4 09:44:04 2014
From: report at bugs.python.org (Sam Bishop)
Date: Tue, 04 Nov 2014 08:44:04 +0000
Subject: [issue22790] __qualname__ missing from dir(__class__) during class
 initialisation
Message-ID: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>


New submission from Sam Bishop:

The output of performing "dir(__class__)" during a class' __init__ method, seems to be lacking the new '__qualname__' attribute in python 3.

This rough test can be pasted right into the python 3.4 REPL to see the issue.
Tested on 64bit python 3.4 running on OSX 10.9
 
"
class Foo:
    class Bar(object):
        keywords = dict()
        def __init__(self, **kwargs):
            print(dir(__class__))
            print(''.join(('"str(__class__.__qualname__)" = ', str(__class__.__qualname__))))
            print(''.join((
                'Is "__qualname__" in the output of the dir() function? : ',
                str(('__qualname__' in dir(__class__))))))
            self.keywords = kwargs


test = Foo.Bar(see='We are missing something here')


"

----------
components: Interpreter Core
messages: 230591
nosy: techdragon
priority: normal
severity: normal
status: open
title: __qualname__ missing from dir(__class__) during class initialisation
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  4 09:44:40 2014
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 04 Nov 2014 08:44:40 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
Message-ID: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>


New submission from INADA Naoki:

In [1]: import datetime

In [2]: datetime.datetime.utcfromtimestamp(0)
Out[2]: datetime.datetime(1970, 1, 1, 0, 0)

In [3]: datetime.datetime.utcfromtimestamp(0).replace(tzinfo=datetime.timezone.utc)
Out[3]: datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

datetime.utcfromtimestamp() returns naive datetime.
But some methods assumes naive datetime is localtime. (e.g. datetime.timestamp()).
This is big pitfall for many Pythonistas.

We can't change default behavior for backward compatibility.
How about adding `aware` keyword-only option?

>>> datetime.datetime.utcfromtimestamp(0, aware=True)
datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

----------
components: Library (Lib)
messages: 230592
nosy: naoki
priority: normal
severity: normal
status: open
title: datetime.utcfromtimestamp() shoud have option for create tz aware datetime
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 10:23:14 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Nov 2014 09:23:14 +0000
Subject: [issue22790] __qualname__ missing from dir(__class__) during class
 initialisation
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415092994.42.0.203865062882.issue22790@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Why did you specify "during class initialization" only? When I print dir(Foo.Bar) at top-level, there is no __qualname__.

Then, note that '__name__' is not listed either, so it's not about new attributes.

It was chosen that dir(someClass) tries to list the know attributes of instances, not the attributes of the class object itself (__bases__, __mro__, and so on).
See https://docs.python.org/3.4/library/functions.html#dir

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> pending

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

From report at bugs.python.org  Tue Nov  4 10:27:05 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 09:27:05 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415093225.06.0.565397943874.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

@Amaury: this is not what I read there:

"If the object is a type or class object, the list contains the names of its attributes, and recursively of the attributes of its bases."

This implies that class attributes are definitely supposed to be in there.

----------
nosy: +georg.brandl
resolution: works for me -> 
status: pending -> open
title: __qualname__ missing from dir(__class__) during class initialisation -> some class attributes missing from dir(Class)

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

From report at bugs.python.org  Tue Nov  4 10:29:02 2014
From: report at bugs.python.org (Sam Bishop)
Date: Tue, 04 Nov 2014 09:29:02 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415093342.52.0.367871378564.issue22790@psf.upfronthosting.co.za>


Sam Bishop added the comment:

I specified 'during class initialisation' because that was the only case I confirmed.

----------

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

From report at bugs.python.org  Tue Nov  4 10:29:37 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 09:29:37 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415093377.48.0.335242530583.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The missing attributes are some of those defined in type_getsets, i.e.

__name__
__qualname__
__bases__
__abstractmethods__
__text_signature__

The latter two are obscure enough that it probably doesn't matter, but the first three should definitely be there.

----------

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

From report at bugs.python.org  Tue Nov  4 10:31:10 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 09:31:10 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415093470.06.0.394077098281.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Ah yes, and some type_members are also missing.

----------

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

From report at bugs.python.org  Tue Nov  4 10:34:38 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Nov 2014 09:34:38 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415093678.09.0.675171529667.issue22790@psf.upfronthosting.co.za>


eryksun added the comment:

You won't find the __qualname__ data descriptor in dir(Foo.Bar) because it's defined by the metaclass, `type`. Attributes from the metaclass have always been excluded from the dir() of a class.

----------
nosy: +eryksun

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

From report at bugs.python.org  Tue Nov  4 10:38:39 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Nov 2014 09:38:39 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415093919.96.0.82854133354.issue22790@psf.upfronthosting.co.za>


eryksun added the comment:

See type_dir:

https://hg.python.org/cpython/file/ab2c023a9432/Objects/typeobject.c#l2984

----------

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

From report at bugs.python.org  Tue Nov  4 10:41:05 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 09:41:05 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415094065.51.0.634739658383.issue22789@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is similar to the idea of loading the stdlib from a zip file (but less intrusive and more debugging-friendly). The time savings will depend on whether the filesystem cache is cold or hot. In the latter case, my intuition is that decompression will slow things down a bit :-)

Quick decompression benchmark on a popular stdlib module, and a fast CPU:

$ ./python -m timeit -s "import zlib; data = zlib.compress(open('Lib/__pycache__/threading.cpython-35.pyc', 'rb').read())" "zlib.decompress(data)"
10000 loops, best of 3: 180 usec per loop

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

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

From report at bugs.python.org  Tue Nov  4 10:50:41 2014
From: report at bugs.python.org (housetier)
Date: Tue, 04 Nov 2014 09:50:41 +0000
Subject: [issue22792] string replace() not documented
Message-ID: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>


New submission from housetier:

https://docs.python.org/3.4/library/string.html does not explain the replace() function. I suppose it is very similar, if not identical, to 2.7: https://docs.python.org/2.7/library/string.html#string.replace

----------
components: Distutils
messages: 230601
nosy: dstufft, eric.araujo, housetier
priority: normal
severity: normal
status: open
title: string replace() not documented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  4 10:59:59 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 09:59:59 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415095199.37.0.230269612912.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

"Attributes from the metaclass have always been excluded from the dir() of a class."

Be that as it may, I think it is wrong.  I can understand excluding methods of the metaclass, but __qualname__ (and friends) are only defined in the metaclass because they are properties and not __dict__ members, but they are regular attributes of the class, not of the metaclass.

E.g. why is __module__ in there and not __qualname__? Both are determined dynamically at class creation time.

The answer is that it's an implementation detail: there is no tp_module (or ht_module) member in the PyHeapTypeObject struct to store it, so it's stored in __dict__, while __qualname__ is stored in a struct member.

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Nov  4 11:15:39 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:15:39 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096139.15.0.780548230749.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

BTW, the same implementation detail means that you can ask an instance for its class' __module__, but not the __name__.

----------

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

From report at bugs.python.org  Tue Nov  4 11:22:00 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Nov 2014 10:22:00 +0000
Subject: [issue22792] string replace() not documented
In-Reply-To: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>
Message-ID: <1415096520.34.0.246513872074.issue22792@psf.upfronthosting.co.za>


eryksun added the comment:

Follow the "String Methods" link at the top of the string module documentation. Or use this link:

https://docs.python.org/3.4/library/stdtypes.html#str.replace

See also help(str.replace) and help(str) in the interactive shell.

----------
assignee:  -> docs at python
components: +Documentation -Distutils
nosy: +docs at python, eryksun

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

From report at bugs.python.org  Tue Nov  4 11:23:28 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:23:28 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096608.07.0.809056927704.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

However, it may not be possible to change this for backward compatibility reasons.  People shouldn't be using dir() for determining attributes and the like, but they do, as documented by the multiprocessing module in the stdlib.

This should at least be noted more explicitly in the docs for dir().

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python

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

From report at bugs.python.org  Tue Nov  4 11:24:49 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:24:49 +0000
Subject: [issue22792] string replace() not documented
In-Reply-To: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>
Message-ID: <1415096689.56.0.894118972188.issue22792@psf.upfronthosting.co.za>


Georg Brandl added the comment:

There is already a "see also: string methods" at the top of the page.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

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

From mal at egenix.com  Tue Nov  4 11:25:03 2014
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 04 Nov 2014 11:25:03 +0100
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415094065.51.0.634739658383.issue22789@psf.upfronthosting.co.za>
References: <1415094065.51.0.634739658383.issue22789@psf.upfronthosting.co.za>
Message-ID: <5458A97F.3030502@egenix.com>

On 04.11.2014 10:41, Antoine Pitrou wrote:
> 
> Antoine Pitrou added the comment:
> 
> This is similar to the idea of loading the stdlib from a zip file (but less intrusive and more debugging-friendly). The time savings will depend on whether the filesystem cache is cold or hot. In the latter case, my intuition is that decompression will slow things down a bit :-)
> 
> Quick decompression benchmark on a popular stdlib module, and a fast CPU:
> 
> $ ./python -m timeit -s "import zlib; data = zlib.compress(open('Lib/__pycache__/threading.cpython-35.pyc', 'rb').read())" "zlib.decompress(data)"
> 10000 loops, best of 3: 180 usec per loop

zlib is rather slow when it comes to decompression. Something like
snappy or lz4 could work out, though:

https://code.google.com/p/snappy/
https://code.google.com/p/lz4/

Those were designed to be fast on decompression.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Tue Nov  4 11:25:08 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 04 Nov 2014 10:25:08 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415094065.51.0.634739658383.issue22789@psf.upfronthosting.co.za>
Message-ID: <5458A97F.3030502@egenix.com>


Marc-Andre Lemburg added the comment:

On 04.11.2014 10:41, Antoine Pitrou wrote:
> 
> Antoine Pitrou added the comment:
> 
> This is similar to the idea of loading the stdlib from a zip file (but less intrusive and more debugging-friendly). The time savings will depend on whether the filesystem cache is cold or hot. In the latter case, my intuition is that decompression will slow things down a bit :-)
> 
> Quick decompression benchmark on a popular stdlib module, and a fast CPU:
> 
> $ ./python -m timeit -s "import zlib; data = zlib.compress(open('Lib/__pycache__/threading.cpython-35.pyc', 'rb').read())" "zlib.decompress(data)"
> 10000 loops, best of 3: 180 usec per loop

zlib is rather slow when it comes to decompression. Something like
snappy or lz4 could work out, though:

https://code.google.com/p/snappy/
https://code.google.com/p/lz4/

Those were designed to be fast on decompression.

----------
nosy: +lemburg

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

From report at bugs.python.org  Tue Nov  4 11:28:33 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:28:33 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096913.3.0.296131794976.issue22790@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I definitely think this should be changed. I just don't know how to do it :-)

----------
stage:  -> needs patch
versions: +Python 3.5

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

From report at bugs.python.org  Tue Nov  4 11:28:38 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:28:38 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096918.68.0.145342077698.issue22790@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Nov  4 11:36:26 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:36:26 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415097386.96.0.853733146062.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Attaching prototype patch without test suite adjustments.

----------
keywords: +patch
Added file: http://bugs.python.org/file37126/type_dir_patch.diff

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

From report at bugs.python.org  Tue Nov  4 11:39:59 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:39:59 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415097599.15.0.769239183625.issue22789@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, comparison between zlib/snappy/lz4:

$ python3.4 -m timeit -s "import zlib; data = zlib.compress(open('Lib/__pycache__/threading.cpython-35.pyc', 'rb').read()); print(len(data))" "zlib.decompress(data)"
10000 loops, best of 3: 181 usec per loop

$ python3.4 -m timeit -s "import snappy; data = snappy.compress(open('Lib/__pycache__/threading.cpython-35.pyc', 'rb').read()); print(len(data))" "snappy.decompress(data)"
10000 loops, best of 3: 35 usec per loop

$ python3.4 -m timeit -s "import lz4; data = lz4.compress(open('Lib/__pycache__/threading.cpython-35.pyc', 'rb').read()); print(len(data))" "lz4.decompress(data)"
10000 loops, best of 3: 21.3 usec per loop

Compressed sizes for threading.cpython-35.pyc (the file used above):
- zlib: 14009 bytes
- snappy: 20573 bytes
- lz4: 21038 bytes
- uncompressed: 38973 bytes

Packages used:
https://pypi.python.org/pypi/lz4/0.7.0
https://pypi.python.org/pypi/python-snappy/0.5

----------

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

From report at bugs.python.org  Tue Nov  4 11:40:59 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 10:40:59 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415097659.22.0.0599217992882.issue22790@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Nov  4 11:42:44 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:42:44 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415097764.55.0.614742116533.issue22789@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

lz4 also has a "high compression" mode which improves the compression ratio (-> 17091 bytes compressed), for a similar decompression speed.

----------

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

From report at bugs.python.org  Tue Nov  4 11:44:13 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:44:13 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415097853.65.0.896036543073.issue22790@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I have a question: why would do it for classes and not for regular objects?

----------
assignee: docs at python -> 

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

From report at bugs.python.org  Tue Nov  4 11:48:22 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:48:22 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415098102.5.0.787830896001.issue22790@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, I misunderstood the patch, sorry. Nevermind.

----------

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

From report at bugs.python.org  Tue Nov  4 11:48:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:48:27 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415098107.38.0.787833315701.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Basically beacuse with the current patch, this is because object_dir also does merge_class_dict, to get class attributes.  This means that attributes like __qualname__ would show up in dir(instance), but are not actually available on the instance.

Fixing this requires a more substantial rewrite, but is certainly the right way if this is accepted at all.

----------

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

From report at bugs.python.org  Tue Nov  4 11:49:49 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:49:49 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415098189.22.0.781258327687.issue22789@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Both lz4 and snappy are BSD-licensed, but snappy is written in C++.

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

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

From report at bugs.python.org  Tue Nov  4 12:02:45 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 11:02:45 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415098965.29.0.898739592431.issue22790@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Tue Nov  4 12:08:38 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 11:08:38 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415099318.06.0.355756763369.issue22791@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Nov  4 12:26:50 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 04 Nov 2014 11:26:50 +0000
Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad
 argument
In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za>
Message-ID: <1415100410.07.0.423523769889.issue21931@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

There's not much to look into.  If the Python function encounters an argument error, it returns an uninitialized integer as an "error code."  This patch fixes incorrect C code, nothing more.

----------

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

From report at bugs.python.org  Tue Nov  4 12:45:59 2014
From: report at bugs.python.org (Michael Foord)
Date: Tue, 04 Nov 2014 11:45:59 +0000
Subject: [issue22457] load_tests not invoked in root __init__.py when
 start=package root
In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za>
Message-ID: <1415101559.2.0.272832274837.issue22457@psf.upfronthosting.co.za>


Michael Foord added the comment:

With one minor doc change (break up the really long sentence), this looks good to go to me.

----------

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

From report at bugs.python.org  Tue Nov  4 12:49:18 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 11:49:18 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415101758.8.0.855544727322.issue22725@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Nov  4 12:49:49 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 11:49:49 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415101789.62.0.818293371698.issue22780@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Nov  4 12:58:01 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 11:58:01 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415102281.07.0.276074749248.issue22789@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Nov  4 13:30:04 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Nov 2014 12:30:04 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415104204.05.0.191006124233.issue22790@psf.upfronthosting.co.za>


eryksun added the comment:

__doc__ and __module__ are also getsets (to support built-in types), but it's nothing to worry about since the attributes can't be deleted.

I think the most value added here is for listing __mro__ and the others that Georg mentioned. Should the following attributes be blacklisted from dir() as CPython implementation details?

    __base__
    __flags__
    __basicsize__
    __itemsize__
    __dictoffset__
    __weakrefoffset__

It's not as if people will miss what they never had.

----------

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

From report at bugs.python.org  Tue Nov  4 14:26:25 2014
From: report at bugs.python.org (Tim Graham)
Date: Tue, 04 Nov 2014 13:26:25 +0000
Subject: [issue22758] Regression in Python 3.2 cookie parsing
In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za>
Message-ID: <1415107585.0.0.849136576695.issue22758@psf.upfronthosting.co.za>


Tim Graham added the comment:

The patch from #16611 applies cleanly to 3.2. I added a mention in Misc/NEWS and confirmed that all tests pass.

----------
Added file: http://bugs.python.org/file37127/secure-httponly-3.2-backport.diff

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

From report at bugs.python.org  Tue Nov  4 14:50:48 2014
From: report at bugs.python.org (Rishi)
Date: Tue, 04 Nov 2014 13:50:48 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1415109048.73.0.261936805425.issue1610654@psf.upfronthosting.co.za>


Rishi added the comment:

Patch updated from review comments. Also added a few corner test cases.

----------
Added file: http://bugs.python.org/file37128/issue1610654_2.patch

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

From report at bugs.python.org  Tue Nov  4 14:53:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 13:53:12 +0000
Subject: [issue22773] Export Readline version and expect ANSI sequence for
 version < 0x0600
In-Reply-To: <1414764088.14.0.977066596578.issue22773@psf.upfronthosting.co.za>
Message-ID: <20141104135307.113482.5164@psf.io>


Roundup Robot added the comment:

New changeset c4b5a5d44254 by Antoine Pitrou in branch '3.4':
Issue #22773: fix failing test with old readline versions due to issue #19884.
https://hg.python.org/cpython/rev/c4b5a5d44254

New changeset be374b8c40c8 by Antoine Pitrou in branch 'default':
Issue #22773: fix failing test with old readline versions due to issue #19884.
https://hg.python.org/cpython/rev/be374b8c40c8

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

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

From report at bugs.python.org  Tue Nov  4 14:53:59 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 13:53:59 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <20141104135308.113482.86534@psf.io>


Roundup Robot added the comment:

New changeset c4b5a5d44254 by Antoine Pitrou in branch '3.4':
Issue #22773: fix failing test with old readline versions due to issue #19884.
https://hg.python.org/cpython/rev/c4b5a5d44254

New changeset be374b8c40c8 by Antoine Pitrou in branch 'default':
Issue #22773: fix failing test with old readline versions due to issue #19884.
https://hg.python.org/cpython/rev/be374b8c40c8

----------

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

From report at bugs.python.org  Tue Nov  4 14:56:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 13:56:46 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <20141104135456.108383.52422@psf.io>


Roundup Robot added the comment:

New changeset eba6e68e818c by Antoine Pitrou in branch '2.7':
Issue #22773: fix failing test with old readline versions due to issue #19884.
https://hg.python.org/cpython/rev/eba6e68e818c

----------

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

From report at bugs.python.org  Tue Nov  4 14:56:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 13:56:46 +0000
Subject: [issue22773] Export Readline version and expect ANSI sequence for
 version < 0x0600
In-Reply-To: <1414764088.14.0.977066596578.issue22773@psf.upfronthosting.co.za>
Message-ID: <20141104135456.108383.73157@psf.io>


Roundup Robot added the comment:

New changeset eba6e68e818c by Antoine Pitrou in branch '2.7':
Issue #22773: fix failing test with old readline versions due to issue #19884.
https://hg.python.org/cpython/rev/eba6e68e818c

----------

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

From report at bugs.python.org  Tue Nov  4 15:10:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 14:10:28 +0000
Subject: [issue22457] load_tests not invoked in root __init__.py when
 start=package root
In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za>
Message-ID: <20141104140917.113454.54696@psf.io>


Roundup Robot added the comment:

New changeset ce0dd5e4b801 by Robert Collins in branch 'default':
Close #22457: Honour load_tests in the start_dir of discovery.
https://hg.python.org/cpython/rev/ce0dd5e4b801

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

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

From report at bugs.python.org  Tue Nov  4 15:14:52 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 14:14:52 +0000
Subject: [issue22773] Export Readline version and expect ANSI sequence for
 version < 0x0600
In-Reply-To: <1414764088.14.0.977066596578.issue22773@psf.upfronthosting.co.za>
Message-ID: <1415110492.35.0.76088298635.issue22773@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Tue Nov  4 15:21:43 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 14:21:43 +0000
Subject: [issue22793] test_uuid failure on OpenIndiana
Message-ID: <1415110903.37.0.741513995713.issue22793@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8840/steps/test/logs/stdio

testIssue8621 (test.test_uuid.TestUUID) ... ok
test_UUID (test.test_uuid.TestUUID) ... ok
test_exceptions (test.test_uuid.TestUUID) ... ok
test_find_mac (test.test_uuid.TestUUID) ... ok
test_getnode (test.test_uuid.TestUUID) ... ok
test_ifconfig_getnode (test.test_uuid.TestUUID) ... ERROR
test_ipconfig_getnode (test.test_uuid.TestUUID) ... skipped 'requires Windows'
test_netbios_getnode (test.test_uuid.TestUUID) ... skipped 'requires win32wnet'
test_random_getnode (test.test_uuid.TestUUID) ... ok
test_unixdll_getnode (test.test_uuid.TestUUID) ... skipped 'requires ctypes'
test_uuid1 (test.test_uuid.TestUUID) ... skipped 'requires ctypes'
test_uuid3 (test.test_uuid.TestUUID) ... ok
test_uuid4 (test.test_uuid.TestUUID) ... skipped 'requires ctypes'
test_uuid5 (test.test_uuid.TestUUID) ... ok
test_windll_getnode (test.test_uuid.TestUUID) ... skipped 'requires Windows'

======================================================================
ERROR: test_ifconfig_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_uuid.py", line 319, in test_ifconfig_getnode
    node = uuid._ifconfig_getnode()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/uuid.py", line 360, in _ifconfig_getnode
    mac = _find_mac('arp', '-an', [os.fsencode(ip_addr)], lambda i: -1)
NameError: name 'os' is not defined

----------------------------------------------------------------------
Ran 15 tests in 0.211s

----------
components: Library (Lib)
messages: 230626
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_uuid failure on OpenIndiana
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 15:44:17 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 04 Nov 2014 14:44:17 +0000
Subject: [issue22457] load_tests not invoked in root __init__.py when
 start=package root
In-Reply-To: <1411357674.43.0.0204872118136.issue22457@psf.upfronthosting.co.za>
Message-ID: <20141104144401.709.61470@psf.io>


Roundup Robot added the comment:

New changeset 2aac2d76035e by Robert Collins in branch 'default':
Fix regression in issue 22457 fix.
https://hg.python.org/cpython/rev/2aac2d76035e

----------

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

From report at bugs.python.org  Tue Nov  4 16:03:57 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Nov 2014 15:03:57 +0000
Subject: [issue22794] missing test for issue 22457 regression commit
Message-ID: <1415113437.67.0.13245212924.issue22794@psf.upfronthosting.co.za>


New submission from Robert Collins:

I did a brownbag fix for my change to issue22457 which exposed a untested corner case - this issue is for me to come back and add a regression test for it.

----------
messages: 230628
nosy: rbcollins
priority: normal
severity: normal
status: open
title: missing test for issue 22457 regression commit
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov  4 16:07:53 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 04 Nov 2014 15:07:53 +0000
Subject: [issue22680] unittest discovery is fragile
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1415113673.17.0.933629926502.issue22680@psf.upfronthosting.co.za>


Robert Collins added the comment:

This was reported as https://code.google.com/p/unittest-ext/issues/detail?id=71 a while back. I think blacklisting FunctionTestCase in TestLoader is entirely reasonable.

----------

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

From report at bugs.python.org  Tue Nov  4 16:28:27 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 04 Nov 2014 15:28:27 +0000
Subject: [issue22795] Intermittent
Message-ID: <1415114907.55.0.414991174026.issue22795@psf.upfronthosting.co.za>


Changes by David Edelsohn <dje.gcc at gmail.com>:


----------
components: Tests
nosy: David.Edelsohn, haypo
priority: normal
severity: normal
status: open
title: Intermittent
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov  4 16:30:53 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 04 Nov 2014 15:30:53 +0000
Subject: [issue22795] Intermittent test_tarfile failures on zLinux
Message-ID: <1415115053.37.0.0197964842568.issue22795@psf.upfronthosting.co.za>


New submission from David Edelsohn:

test_list_command_verbose intermittently fails because the date comparison differs by six hours.  I suspect a bad interaction between tests, but have not been able to find the culprit.

FAIL: test_list_command_verbose (test.test_tarfile.CommandLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_tarfile.py", line 1953, in test_list_command_verbose
    self.assertEqual(out, expected)
AssertionError: b'?rw[39 chars]-01-05 18:19:43 ustar/conttype \n?rw-r--r-- ta[6470 chars]f \n' != b'?rw[39 chars]-01-06 00:19:43 ustar/conttype \n?rw-r--r-- ta[6470 chars]f \n'

----------
nosy: +pitrou
title: Intermittent -> Intermittent test_tarfile failures on zLinux

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

From report at bugs.python.org  Tue Nov  4 16:35:47 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 04 Nov 2014 15:35:47 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415115347.2.0.447725127994.issue22789@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Just FYI, there can easily be added into importlib since it works through marshal's API to unmarshal the module's data. There is also two startup benchmarks in the benchmark suite to help measure possible performance gains/losses which should also ferret out if cache warmth will play a significant role in the performance impact.

----------

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

From report at bugs.python.org  Tue Nov  4 16:45:48 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 04 Nov 2014 15:45:48 +0000
Subject: [issue22795] Intermittent test_tarfile failures on zLinux
In-Reply-To: <1415115053.37.0.0197964842568.issue22795@psf.upfronthosting.co.za>
Message-ID: <1415115948.07.0.695046197933.issue22795@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag, serhiy.storchaka
versions: +Python 3.4, Python 3.5 -Python 3.6

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

From report at bugs.python.org  Tue Nov  4 16:51:41 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 15:51:41 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415116301.63.0.907792434423.issue22791@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't find the keyword to be superior to the 'replace' spelling, myself.  I think the replace spelling makes it clearer what the intent is.

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

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

From report at bugs.python.org  Tue Nov  4 16:57:37 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 15:57:37 +0000
Subject: [issue22792] string replace() not documented
In-Reply-To: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>
Message-ID: <1415116657.88.0.820858911135.issue22792@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify for the OP: in python3 the 'string' module does not contain a replace function, whereas in 2.7 it did.  'replace' is only a method on str in python3, whereas in 2.7 it is both an str method and a function in the string module.

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

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

From report at bugs.python.org  Tue Nov  4 16:59:21 2014
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 04 Nov 2014 15:59:21 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415116761.01.0.459399139911.issue22789@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Tue Nov  4 17:17:17 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 04 Nov 2014 16:17:17 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415117837.98.0.12068243008.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

R. David Murray said:
--------------------
> "try the reflected operation" is not our standard terminology.

Parenthetical under discussion:
-------------------------------
> (The interpreter will then try the reflected operation, or some other fallback,
> depending on the operator.)

----------

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

From report at bugs.python.org  Tue Nov  4 17:27:03 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 04 Nov 2014 16:27:03 +0000
Subject: [issue19753] test_gdb failure on SystemZ buildbot
In-Reply-To: <1385297498.35.0.580960849051.issue19753@psf.upfronthosting.co.za>
Message-ID: <1415118423.76.0.676358262728.issue19753@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Victor, can this patch be applied to Python 2.7 branch also?

----------
components: +Tests
type:  -> behavior
versions: +Python 2.7

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

From report at bugs.python.org  Tue Nov  4 17:37:54 2014
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 04 Nov 2014 16:37:54 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415119074.51.0.228889047772.issue22791@psf.upfronthosting.co.za>


INADA Naoki added the comment:

This is not a spelling issue.

When people writing code converting between unixtime and datetime,
they should find `.timestamp()` and `.utcfromtimestamp()`.
But they may not awake about `.replace(tzinfo=datetime.timezone.utc)` is very important.

Since `fromtimestamp` takes `tz` as optional 2nd argument,
I feel adding 2nd `aware` option to `utcfromtimestamp` is good for symmetry.


If `datetime.datetime.utcfromtimestamp(ts).replace(tzinfo=datetime.timezone.utc)`
is clearer than `datetime.datetime.utcfromtimestamp(ts, aware=True)`,
docstring of `utcfromtimestamp` should notice about how `replace()` important:

"""
Note that it returns **naive** (tz=None) datetime.  Since naive datetime is
treated as localtime in most functions, you may have to call `.replace(tzinfo=datetime.datetime.utc)` before using it.
"""

----------

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

From report at bugs.python.org  Tue Nov  4 17:47:43 2014
From: report at bugs.python.org (Tim Graham)
Date: Tue, 04 Nov 2014 16:47:43 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
Message-ID: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>


New submission from Tim Graham:

As noted in the comments of #22758 by Georg Brandle: 

* Django uses __init__(str()) roundtripping, which is not explicitly supported by the library, and worked by accident with previous versions.  That it works again with 3.3+ is another accident, and a bug.

(The change for #16611 reintroduces "lax" parsing behavior that the security fix [1] was supposed to prevent.)

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

----------
components: Library (Lib)
messages: 230637
nosy: Tim.Graham, berker.peksag, georg.brandl, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Support for httponly/secure cookies reintroduced lax parsing behavior
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov  4 17:48:35 2014
From: report at bugs.python.org (Tim Graham)
Date: Tue, 04 Nov 2014 16:48:35 +0000
Subject: [issue22758] Regression in Python 3.2 cookie parsing
In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za>
Message-ID: <1415119715.37.0.566012529224.issue22758@psf.upfronthosting.co.za>


Tim Graham added the comment:

I also created #22796 for the lax parsing issue.

----------

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

From report at bugs.python.org  Tue Nov  4 17:52:33 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 16:52:33 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415119953.15.0.482886325231.issue22790@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

__base__ exists also in Jython and PyPy (#22456).

I think that all attributes could be listed.

----------

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

From report at bugs.python.org  Tue Nov  4 17:58:55 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 16:58:55 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415120335.11.0.0654720559626.issue22796@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Nov  4 18:04:57 2014
From: report at bugs.python.org (Joshua Chin)
Date: Tue, 04 Nov 2014 17:04:57 +0000
Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees
 that a URLError will be raised on errors
Message-ID: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>


New submission from Joshua Chin:

The documentation for urlopen states that it "Raises URLError on errors." However, urlopen can raise a ValueError. In fact, test_urllib. urlopen_FileTests.test_relativelocalfile  specifically checks if urlopen raises a ValueError. I suggest removing the guarantee from the documentation.

----------
assignee: docs at python
components: Documentation
files: urlopen_doc.patch
keywords: patch
messages: 230640
nosy: Joshua.Chin, docs at python, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37129/urlopen_doc.patch

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

From report at bugs.python.org  Tue Nov  4 18:12:37 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 17:12:37 +0000
Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees
 that a URLError will be raised on errors
In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>
Message-ID: <1415121157.96.0.178195524813.issue22797@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a general principle in Python.  A module may raise specific errors, but there are always other errors that may be raised.  The wording could be clarified, but it should not be removed.

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

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

From report at bugs.python.org  Tue Nov  4 18:14:00 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 17:14:00 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415121240.46.0.923945401329.issue22780@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, you got me there :)

----------

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

From report at bugs.python.org  Tue Nov  4 18:17:27 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 17:17:27 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415121447.5.0.268287184459.issue22791@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I agree that a doc note would be appropriate.  timezone is relatively new, originally there was no way to produce aware datetimes from the datetime module without writing your own tzinfo class.  Now that there is, there are may be more than one place in the datetime docs that should be enhanced.

----------

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

From report at bugs.python.org  Tue Nov  4 18:23:21 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 17:23:21 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415121801.71.0.248359853756.issue22796@psf.upfronthosting.co.za>


R. David Murray added the comment:

This test still exists, so the change didn't cause it to trigger.  What is the security bug?  The commit doesn't say, and doesn't reference an issue number.  So if that test still passes, what's the bug?

----------

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

From report at bugs.python.org  Tue Nov  4 18:38:58 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 17:38:58 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415122738.96.0.735349785424.issue22796@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, with this change you can again (e.g.) pass

"Set-cookie: foo=bar"

which isn't a valid cookie.  It doesn't reintroduce the same vulnerability, but it will still silently consume invalid cookies (i.e. such with attribute-like tokens upfront) and return a seemingly valid one.

IMO this is questionable behavior of the kind that can enable exploits, which is also why it was disallowed by the fix of the first vulnerability.

----------

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

From report at bugs.python.org  Tue Nov  4 18:43:40 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Nov 2014 17:43:40 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415123020.94.0.140197876832.issue22790@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

So, dir(C) contains '__mro__', but not 'mro'?

I'm -1 on the change.
>From https://docs.python.org/3.4/library/functions.html#dir :
"""
Note Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases. For example, metaclass attributes are not in the result list when the argument is a class.
"""

dir(sys) does not list its __str__ method, even if sys.__str__() works, because returning only the explicit content of the module is more interesting to the user.

Likewise, the implementation of dir(__class__) returns the methods and attributes of *instances* because [someone decided that] it's the most relevant info for the user.

----------

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

From report at bugs.python.org  Tue Nov  4 18:46:55 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 17:46:55 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415123215.37.0.430428166168.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> So, dir(C) contains '__mro__', but not 'mro'?

That can be discussed.

But I would argue that at least __name__, __bases__ and __qualname__ are interesting attributes for the user.  Same for methods like __subclasses__().

Otherwise, it's quite ironic to prevent attributes that allow introspection in the first place from being displayed in one of the main features used for introspection.

----------

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

From report at bugs.python.org  Tue Nov  4 18:53:05 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 04 Nov 2014 17:53:05 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415123585.72.0.0576402782979.issue22790@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Why are __flags__, __basicsize__, __itemsize__, __dictoffset__, and __weakrefoffset__ interesting?

I agree with Georg about the others.

----------
nosy: +ethan.furman

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

From report at bugs.python.org  Tue Nov  4 19:00:13 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 18:00:13 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415124013.02.0.0204169369427.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> Why are __flags__, __basicsize__, __itemsize__, __dictoffset__, and __weakrefoffset__ interesting?

I haven't said they are, but on the other hand I don't see why consistency is a bad thing.

----------

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

From report at bugs.python.org  Tue Nov  4 19:34:36 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 18:34:36 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415126076.32.0.571958779106.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The security issue isn't easy to explain, it involves an elaborated set of services (browser, Web site...) each having a slightly different notion of cookie parsing to mount an attack allowing to bypass CSRF protection on certain Python-powered frameworks. It's from a report made to security at p.o.

----------

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

From report at bugs.python.org  Tue Nov  4 20:10:29 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 19:10:29 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415128229.44.0.141573678681.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This qualification isn't really accurate:

> The change for #16611 reintroduces "lax" parsing behavior that the security fix [1] was supposed to prevent

since the #16611 changes were committed *before* the security fix.

----------

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

From report at bugs.python.org  Tue Nov  4 20:16:11 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 04 Nov 2014 19:16:11 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1415128571.77.0.401811929385.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Whew!

If a different wording is better, I'm happy to change both places.  :)

----------

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

From report at bugs.python.org  Tue Nov  4 20:49:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 19:49:26 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415130566.67.0.785942343889.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note that f81846c2b746 adds an explicit test for acceptance of invalid cookie strings ("test_bad_attrs").

----------

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

From report at bugs.python.org  Tue Nov  4 20:51:30 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 19:51:30 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415130690.31.0.601558009317.issue22796@psf.upfronthosting.co.za>


Georg Brandl added the comment:

These are unknown attributes after a key=value pair.  What this issue is about is accepting attributes *before* any key=value pair.

----------

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

From report at bugs.python.org  Tue Nov  4 21:31:47 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 20:31:47 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415133107.37.0.213934440505.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, if we want to become stricter, I don't it makes sense to stop at the middle of the road.
In any case, here is a patch enabling strict parsing.

----------
keywords: +patch
Added file: http://bugs.python.org/file37130/cookie_strict_parsing.patch

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

From report at bugs.python.org  Tue Nov  4 21:33:01 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 20:33:01 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415133181.95.0.838511745198.issue22796@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +PaulMcMillan

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

From report at bugs.python.org  Tue Nov  4 21:43:36 2014
From: report at bugs.python.org (Joshua Chin)
Date: Tue, 04 Nov 2014 20:43:36 +0000
Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees
 that a URLError will be raised on errors
In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>
Message-ID: <1415133816.6.0.0832786782263.issue22797@psf.upfronthosting.co.za>


Changes by Joshua Chin <joshuarchin at gmail.com>:


Added file: http://bugs.python.org/file37131/urlopen_doc.patch

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

From report at bugs.python.org  Tue Nov  4 22:08:42 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 04 Nov 2014 21:08:42 +0000
Subject: [issue21931] Nonsense errors reported by msilib.FCICreate for bad
 argument
In-Reply-To: <1404737590.72.0.85327158616.issue21931@psf.upfronthosting.co.za>
Message-ID: <1415135322.71.0.838277590339.issue21931@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Right, the entire patch might be processed in 30 minutes. I won't have these 30 minutes any time soon.

----------

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

From report at bugs.python.org  Tue Nov  4 22:10:08 2014
From: report at bugs.python.org (Devin Jeanpierre)
Date: Tue, 04 Nov 2014 21:10:08 +0000
Subject: [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <1415135408.89.0.887627556374.issue22785@psf.upfronthosting.co.za>


Changes by Devin Jeanpierre <jeanpierreda at gmail.com>:


----------
nosy: +Devin Jeanpierre

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

From report at bugs.python.org  Tue Nov  4 22:20:48 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Tue, 04 Nov 2014 21:20:48 +0000
Subject: [issue20597] PATH_MAX already defined on some Windows compilers
In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>
Message-ID: <1415136048.36.0.622615335218.issue20597@psf.upfronthosting.co.za>


Changes by Jeffrey Armstrong <jeffrey.armstrong at approximatrix.com>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Nov  4 23:25:18 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 22:25:18 +0000
Subject: [issue22797] urllib.request.urlopen documentation falsely guarantees
 that a URLError will be raised on errors
In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>
Message-ID: <1415139918.54.0.247143358769.issue22797@psf.upfronthosting.co.za>


R. David Murray added the comment:

(Looking at your new patch...thanks for giving it a try even though I wasn't clear).

There are lots of other errors it can raise, too.  I was thinking more along the lines of "raises URLError on http protocol errors".  The problem is that's not completely accurate, either, but I don't remember exactly when it is that HTTPError can leak through.

Just for reference, in my code that calls urlopen and needs to keep running it if can't access the URL no matter what the (network-derived) reason, I catch ConnectionError, HTTPError, URLError, and IncompleteRead.  

We do not document all possible exceptions.  We document those that are specific to the module in question (which is URLError in this case) or that are part of the documented API (such as mentioning TimeoutError as what happens if the timeout specified by a timeout keyword is exceeded).

ValueErrors are a general class of errors that, when encountered, usually mean you need to fix your code (or, in the case of the SSL one you mention, check for SSL support at startup, assuming I understood correctly), rather than something you would catch around the urlopen call in a typical program.  There are, of course, occasions when you *do* catch ValueErrors in specific bits of code, but there is no practical way we can document all of the reasons ValueError might get raised, so we don't try.

All of that said, it would be lovely to have a reference somewhere (maybe a tutorial?) that went over all the possible exceptions one might get while using various network libraries, and why they might arise.  It is an issue that comes from the fact that the libraries are built on top of each other and the general python technique is that lower level errors are allowed to bubble up.  It would be a beast to keep up to date, though, which is probably one reason we don't have one.  But even that kind of guide wouldn't include ValueErrors.

----------

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

From report at bugs.python.org  Wed Nov  5 00:11:18 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 04 Nov 2014 23:11:18 +0000
Subject: [issue22668] memoryview.format is corrupted due to dangling shared
 pointer
In-Reply-To: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za>
Message-ID: <1415142678.87.0.707382843211.issue22668@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions:  -Python 3.6

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

From report at bugs.python.org  Wed Nov  5 01:15:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 00:15:11 +0000
Subject: [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <1415146511.09.0.202429234182.issue22785@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.5

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

From report at bugs.python.org  Wed Nov  5 03:41:55 2014
From: report at bugs.python.org (Tim Graham)
Date: Wed, 05 Nov 2014 02:41:55 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415155315.38.0.752263782361.issue22796@psf.upfronthosting.co.za>


Tim Graham added the comment:

Django's test suite passes with the proposed patch after some updates: https://github.com/django/django/pull/3455

----------

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

From report at bugs.python.org  Wed Nov  5 06:44:00 2014
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Nov 2014 05:44:00 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1415166240.87.0.742391940763.issue20160@psf.upfronthosting.co.za>


Steve Dower added the comment:

Had a look at where libffi is at, and we're such a long way from them now that I don't think we can easily merge (a.k.a. I don't want to be the one to do it :) )

I want to run this patch through some builds with the right compilers, but then I'll check it in.

----------
assignee:  -> steve.dower
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Wed Nov  5 07:13:51 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Wed, 05 Nov 2014 06:13:51 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1415168031.45.0.711261710777.issue22619@psf.upfronthosting.co.za>


Dmitry Kazakov added the comment:

I'm not sure what would be the best way to support negative limit for stack functions. Actually, I think the current behavior is not intuitive. For example we could make positive limit mean the same thing for traceback and stack functions (load N entries, starting from the caller), but in that case the change will inverse the behavior of code that uses stack functions. Since the traceback module is mostly used for printing/formatting the difference won't be crucial.

----------

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

From report at bugs.python.org  Wed Nov  5 07:22:48 2014
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 05 Nov 2014 06:22:48 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1415088637.95.0.00433196200754.issue22725@psf.upfronthosting.co.za>
Message-ID: <CAA77j2D3+TnYBP89MipLO6vaSJYM27nHxQRStb5ew0_+2kzDQA@mail.gmail.com>


Tshepang Lekhonkhobe added the comment:

Oh, I see now. The documentation doesn't make it clear.

Anyways, what were the advantages of making it a keyword, instead of
just a positional argument?

----------

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

From report at bugs.python.org  Wed Nov  5 08:05:16 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Nov 2014 07:05:16 +0000
Subject: [issue20597] PATH_MAX already defined on some Windows compilers
In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>
Message-ID: <1415171116.65.0.766332327247.issue20597@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Reopening. I still don't understand the issue for 3.4, especially in the light of #21274

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

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

From report at bugs.python.org  Wed Nov  5 08:06:03 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 05 Nov 2014 07:06:03 +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: <1415171163.5.0.56459678842.issue21274@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Reopening. What problem does this fix? AFAICT, PATH_MAX isn't used at all (anymore).

----------
nosy: +loewis
resolution: fixed -> 
status: closed -> open

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

From report at bugs.python.org  Wed Nov  5 08:13:18 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Nov 2014 07:13:18 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415171598.74.0.735743720312.issue22725@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Missing keyword argument support is not the norm, it's the exception that is only due to implementation details in C code. Eventually, we'd like every C function to support keyword arguments.

Converting everything is tedious work, though, and still makes things slower (that may become less of an issue eventually with Clinic), so only select functions are converted.

Functions are good candidates for keyword argument support when they have parameters that are best passed as keywords, such as

    enumerate(x, start=5)

which makes it immediately clear what the second parameter does.

----------

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

From report at bugs.python.org  Wed Nov  5 09:17:29 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:17:29 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415175449.78.0.40548713049.issue22766@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> However, doing the check on 'other' and raising a TypeError
> with an appropriate message would still be better 

Let's be clear.  These are duck-typed methods.  A type check is inappropriate.  Anything with o.items() is allowed regardless of type.

Also, I generally won't approve changes to existing APIs without compelling real-world use cases to motivate the design change.  Otherwise, you just create unnecessary churn and consternation.

----------

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

From report at bugs.python.org  Wed Nov  5 09:29:23 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:29:23 +0000
Subject: [issue22725] improve documentation for enumerate() (built-in function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415176163.76.0.217060991593.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm sorry but I do not like the proposed patch at all.  The wording is awkward "which when iterated" and has weird terminology "the sequence number".

The OP's concern about the *sequence* versus *iterable* parameter name has been addressed (it is part of the 2.7 API and is unchangeable).

I see no need for revising the text which already discusses "sequence or some other object that supports iterable", that has clear examples, and that has pure python equivalent code.   The existing wording has worked well for most people for the better part of a decade.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Nov  5 09:33:11 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:33:11 +0000
Subject: [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <1415176391.59.0.130417289002.issue22785@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Note that Python 3 seems to imply that the end-point is included

The Python 2 wording is better in this regard.

Also, it would be nice clarify what is meant by "virtual sequence".  I know what that means only because I already know what range() does.  For someone who doesn't already know what it means, that phrase probably doesn't add any value.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Nov  5 09:41:40 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:41:40 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415176900.45.0.843175860219.issue22796@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good.  One nit, please change "items" to "typed_items" or somesuch.  That will make it clear why there are 3-tuples instead of the traditional 2-tuple used for normal mappings.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Nov  5 09:45:58 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:45:58 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1415177158.96.0.682757163246.issue21650@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good.  One nit, the phrase "sorted by their key" has an odd ring to it and is mildly confusing, though technically correct.  Perhaps, "sorted alphabetically by key" would be better for most folks.

----------

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

From report at bugs.python.org  Wed Nov  5 09:49:54 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:49:54 +0000
Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1415177394.8.0.596437007166.issue22525@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Georg's proposed wording reads well and is clearer than the current wording.  The patch is ready to apply.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Nov  5 09:55:46 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:55:46 +0000
Subject: [issue22721] pprint output for sets and dicts is not stable
In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za>
Message-ID: <1415177746.18.0.469144586089.issue22721@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> the primary sort will be on the type of quote used for the repr,
> which would be surprising and significantly less useful.

How about:  repr(obj).strip("'\"") ?

Overall, the idea of using repr() in some fashion is appealing because it sorts on what the user actually sees.

----------

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

From report at bugs.python.org  Wed Nov  5 10:49:13 2014
From: report at bugs.python.org (Michael Foord)
Date: Wed, 05 Nov 2014 09:49:13 +0000
Subject: [issue22680] Blacklist FunctionTestCase from test discovery
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1415180953.04.0.136300984356.issue22680@psf.upfronthosting.co.za>


Michael Foord added the comment:

I agree.

----------
title: unittest discovery is fragile -> Blacklist FunctionTestCase from test discovery

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

From report at bugs.python.org  Wed Nov  5 12:21:30 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 05 Nov 2014 11:21:30 +0000
Subject: [issue22680] Blacklist FunctionTestCase from test discovery
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1415186490.83.0.943873174441.issue22680@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy

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

From report at bugs.python.org  Wed Nov  5 12:27:00 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Wed, 05 Nov 2014 11:27:00 +0000
Subject: [issue20597] PATH_MAX already defined on some Windows compilers
In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>
Message-ID: <1415186820.95.0.437469331823.issue20597@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

What's to understand?  Some compilers, particularly MinGW and Open Watcom, already define a PATH_MAX macro on Windows, and it's not necessarily the same as Python's redefinition of it, possibly causing a compiler error.  That's all.

Given the time frame that this bug has existed (9 months!?!) and its trivial fix, which would involve adding an  "#ifndef PATH_MAX" right before its declaration, I think "won't fix" is an appropriate resolution.

Leave it open or don't, it makes little difference to me as I'm no longer interested.

----------

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

From report at bugs.python.org  Wed Nov  5 13:12:28 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 05 Nov 2014 12:12:28 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
Message-ID: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>


New submission from Akira Li:

time.tzname is initialized from C tzname variable or tm_zone around Jan, Jul of the current year.

If time.mktime() is called with a time tuple from the past/future then after the call time.tzname might be out-of-sync with the corresponding C tzname and tm_zone values. Because C mktime may change tzname, tm_zone values on some systems and time.mktime calls C mktime.

I've attached test_mktime_changes_tzname.c file that demonstrates that mktime() may change tzname.

----------
components: Library (Lib)
files: test_mktime_changes_tzname.c
messages: 230674
nosy: akira
priority: normal
severity: normal
status: open
title: time.mktime doesn't update time.tzname
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37132/test_mktime_changes_tzname.c

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

From report at bugs.python.org  Wed Nov  5 13:13:30 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 05 Nov 2014 12:13:30 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1415189610.33.0.222714511889.issue22798@psf.upfronthosting.co.za>


Akira Li added the comment:

I've attached test-timezone-info-is-updated.diff file -- a patch for Lib/test/test_time.py that demonstrates that time functions fail to update the timezone info.

The test uses Europe/Moscow timezone but most timezones around the world had/will have different tzname/utc offset (unrelated to DST changes) in the past/future.

----------
keywords: +patch
Added file: http://bugs.python.org/file37133/test-timezone-info-is-updated.diff

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

From report at bugs.python.org  Wed Nov  5 15:01:10 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2014 14:01:10 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1415196070.78.0.87821665606.issue19884@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Arfever, Antoine: If buildbots are happy (green), you can close the issue. (I'm answering to your question on IRC ;-))

----------

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

From report at bugs.python.org  Wed Nov  5 15:07:36 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 14:07:36 +0000
Subject: [issue19753] test_gdb failure on SystemZ buildbot
In-Reply-To: <1385297498.35.0.580960849051.issue19753@psf.upfronthosting.co.za>
Message-ID: <20141105140725.113484.78789@psf.io>


Roundup Robot added the comment:

New changeset 4c260cf1ba39 by Victor Stinner in branch '2.7':
Issue #19753: Fix test_gdb on SystemZ buildbot, ignore warnings
https://hg.python.org/cpython/rev/4c260cf1ba39

----------

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

From report at bugs.python.org  Wed Nov  5 15:08:40 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2014 14:08:40 +0000
Subject: [issue19753] test_gdb failure on SystemZ buildbot
In-Reply-To: <1385297498.35.0.580960849051.issue19753@psf.upfronthosting.co.za>
Message-ID: <1415196520.02.0.296764264412.issue19753@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Victor, can this patch be applied to Python 2.7 branch also?

Done. I didn't check the buildbots, but I guess that the issue was already fixed one year ago...

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

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

From report at bugs.python.org  Wed Nov  5 15:12:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 14:12:18 +0000
Subject: [issue20597] PATH_MAX already defined on some Windows compilers
In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>
Message-ID: <20141105141203.113480.7652@psf.io>


Roundup Robot added the comment:

New changeset 6aaa0aab1e93 by Victor Stinner in branch 'default':
Issue #20597: Remove unused definition of PATH_MAX on Windows, MAXPATHLEN is
https://hg.python.org/cpython/rev/6aaa0aab1e93

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

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

From report at bugs.python.org  Wed Nov  5 15:13:27 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 05 Nov 2014 14:13:27 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1415196807.85.0.277390220025.issue22798@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Added file: http://bugs.python.org/file37134/test_mktime_changes_tzname.c

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

From report at bugs.python.org  Wed Nov  5 15:15:40 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 14:15:40 +0000
Subject: [issue20597] PATH_MAX already defined on some Windows compilers
In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>
Message-ID: <20141105141451.108381.99648@psf.io>


Roundup Robot added the comment:

New changeset d6fb87972dee by Victor Stinner in branch 'default':
Issue #20597, #21274: Remove unused definition of PATH_MAX on GNU/Hurd,
https://hg.python.org/cpython/rev/d6fb87972dee

----------

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

From report at bugs.python.org  Wed Nov  5 15:15:40 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 14:15:40 +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: <20141105141451.108381.61606@psf.io>


Roundup Robot added the comment:

New changeset d6fb87972dee by Victor Stinner in branch 'default':
Issue #20597, #21274: Remove unused definition of PATH_MAX on GNU/Hurd,
https://hg.python.org/cpython/rev/d6fb87972dee

----------

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

From report at bugs.python.org  Wed Nov  5 15:18:35 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2014 14:18:35 +0000
Subject: [issue20597] PATH_MAX already defined on some Windows compilers
In-Reply-To: <1392124275.46.0.750764006124.issue20597@psf.upfronthosting.co.za>
Message-ID: <1415197115.47.0.902332381637.issue20597@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Reopening. I still don't understand the issue for 3.4, especially in the light of #21274

In Python 3.5, PATH_MAX is no more used in Modules/main.c nor Python/pythonrun.c. I removed the "#define PATH_MAX ..." on Windows on Hurd.

This issue is about supporting OpenWatcom which is not officially supported to compile Python on Windows, so I don't want to change Python 2.7 nor 3.4. If anyone disagree, please complain :-)

PATH_MAX is still used in posixmodule.c, but it looks to work on all platforms:

#ifndef MAXPATHLEN
#if defined(PATH_MAX) && PATH_MAX > 1024
#define MAXPATHLEN PATH_MAX
#else
#define MAXPATHLEN 1024
#endif
#endif /* MAXPATHLEN */

I'm now closing this issue.

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

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

From report at bugs.python.org  Wed Nov  5 15:19:18 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2014 14:19:18 +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: <1415197158.59.0.726871985904.issue21274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

In Python 3.5, PATH_MAX is no more used in Modules/main.c nor Python/pythonrun.c. I removed the "#define PATH_MAX ..." on Hurd.

I didn't check Python 3.4.

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

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

From report at bugs.python.org  Wed Nov  5 15:28:09 2014
From: report at bugs.python.org (Tim Graham)
Date: Wed, 05 Nov 2014 14:28:09 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1415197689.26.0.436507696125.issue7559@psf.upfronthosting.co.za>


Changes by Tim Graham <timograham at gmail.com>:


----------
nosy: +Tim.Graham

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

From report at bugs.python.org  Wed Nov  5 16:00:06 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 05 Nov 2014 15:00:06 +0000
Subject: [issue22799] wrong time.timezone
Message-ID: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za>


New submission from Akira Li:

$ TZ=:Europe/Moscow ./python -mtest -v test_time
  ======================================================================
  FAIL: test_localtime_timezone (test.test_time.TestPytime)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File ".../Lib/test/test_time.py", line 721, in test_localtime_timezone
      self.assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst])
  AssertionError: 10800 != 14400
  
  ----------------------------------------------------------------------
  Ran 45 tests in 1.832s
  
  FAILED (failures=1, skipped=3)
  test test_time failed
  1 test failed:
      test_time


UTC offset had changed on 2014-10-26 in Europe/Moscow timezone from
MSK+0400 to MSK+0300.

Python time.timezone returns -14400 (old utc offset) despite C timezone
variable having the correct value (Python uses tm_gmtoff from Jan here).

Similar case where timezone, altzone may be wrong
http://bugs.python.org/msg31138

The issue again http://bugs.python.org/issue22798 is that time timezone
attribute is out-of-sync with the corresponding C variable i.e., C
library provides correct values but time module doesn't use them.

----------
components: Library (Lib)
messages: 230684
nosy: akira
priority: normal
severity: normal
status: open
title: wrong time.timezone
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Nov  5 16:24:22 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2014 15:24:22 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1415201062.65.0.613762011476.issue22685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a patch with a simple unit test.

I chose to modify the pause_reading method of the transport instead of mocking "everything" to test the real code (have a better code coverage).

----------
Added file: http://bugs.python.org/file37135/set_transport-2.patch

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

From report at bugs.python.org  Wed Nov  5 16:34:45 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Wed, 05 Nov 2014 15:34:45 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
Message-ID: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>


New submission from Chris PeBenito:

Python 3.3/3.4 sometimes does not recognize a legitimate IPv6Network netmask:

$ python3
Python 3.3.5 (default, May 28 2014, 13:56:57) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress as ip
>>> nodecon = ip.IPv6Network('ff00::/ff00::')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/ipaddress.py", line 2084, in __init__
    self._prefixlen = self._prefix_from_prefix_string(addr[1])
  File "/usr/lib64/python3.3/ipaddress.py", line 514, in _prefix_from_prefix_string
    self._report_invalid_netmask(prefixlen_str)
  File "/usr/lib64/python3.3/ipaddress.py", line 497, in _report_invalid_netmask
    raise NetmaskValueError(msg) from None
ipaddress.NetmaskValueError: 'ff00::' is not a valid netmask
>>> nodecon = ip.IPv6Network('ff00::/8')
>>> print(nodecon)
ff00::/8
>>> print(nodecon.with_netmask)
ff00::/ff00::

I get the same behavior on Python 3.4.2.

----------
components: Library (Lib)
messages: 230686
nosy: pebenito
priority: normal
severity: normal
status: open
title: IPv6Network constructor sometimes does not recognize legitimate netmask
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  5 16:49:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 15:49:20 +0000
Subject: [issue22793] test_uuid failure on OpenIndiana
In-Reply-To: <1415110903.37.0.741513995713.issue22793@psf.upfronthosting.co.za>
Message-ID: <1415202560.12.0.593794431754.issue22793@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch for issue17293 changes tests so that this bug is visible on Posix. And it fixes this bug itself.

----------

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

From report at bugs.python.org  Wed Nov  5 17:01:01 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 16:01:01 +0000
Subject: [issue22793] test_uuid failure on OpenIndiana
In-Reply-To: <1415110903.37.0.741513995713.issue22793@psf.upfronthosting.co.za>
Message-ID: <20141105160036.108079.21764@psf.io>


Roundup Robot added the comment:

New changeset 16d6c2443131 by Victor Stinner in branch 'default':
Issue #22793, #22637: Add missing "import os" in uuid._ifconfig_getnode()
https://hg.python.org/cpython/rev/16d6c2443131

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

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

From report at bugs.python.org  Wed Nov  5 17:01:01 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 16:01:01 +0000
Subject: [issue22637] avoid using a shell in uuid: replce os.popen with
 subprocess.Popen
In-Reply-To: <1413326137.66.0.946040587589.issue22637@psf.upfronthosting.co.za>
Message-ID: <20141105160036.108079.70466@psf.io>


Roundup Robot added the comment:

New changeset 16d6c2443131 by Victor Stinner in branch 'default':
Issue #22793, #22637: Add missing "import os" in uuid._ifconfig_getnode()
https://hg.python.org/cpython/rev/16d6c2443131

----------

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

From report at bugs.python.org  Wed Nov  5 17:01:56 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Nov 2014 16:01:56 +0000
Subject: [issue22793] test_uuid failure on OpenIndiana
In-Reply-To: <1415110903.37.0.741513995713.issue22793@psf.upfronthosting.co.za>
Message-ID: <1415203316.16.0.740504320271.issue22793@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> NameError: name 'os' is not defined

The imports in this module are really weird... But I'm not interested to rework completly the module, so I just fixed this specific issue.

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

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

From report at bugs.python.org  Wed Nov  5 17:03:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 16:03:01 +0000
Subject: [issue22721] pprint output for sets and dicts is not stable
In-Reply-To: <1415177746.18.0.469144586089.issue22721@psf.upfronthosting.co.za>
Message-ID: <5093090.xXbeeNUMFC@raxxla>


Serhiy Storchaka added the comment:

> How about:  repr(obj).strip("'\"") ?

String can starts or ends with quotes. And string repr can be a part of the 
repr of other type (e.g. short list).

----------

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

From report at bugs.python.org  Wed Nov  5 17:04:33 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 05 Nov 2014 16:04:33 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415203473.75.0.619690692422.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Raymond declared:
----------------
> Let's be clear.  These are duck-typed methods.  A type check is inappropriate.
> Anything with o.items() is allowed regardless of type.

Wikipedia explains (http://en.wikipedia.org/wiki/Duck_typing):
-------------------------------------------------------------
> In computer programming with object-oriented programming languages, duck typing
> is an alternative to typing. In duck typing, an object's suitability for some
> purpose is determined by the presence of certain methods and properties [...]

I did use an actual 'type' check in one of my exmaples, and that was wrong.

It is possible to do a "duck-type check" with a `hasattr(other, 'items')`.

I don't use Counter myself -- I'll try and find some real-world examples.

----------

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

From report at bugs.python.org  Wed Nov  5 17:05:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 16:05:40 +0000
Subject: [issue22795] Intermittent test_tarfile failures on zLinux
In-Reply-To: <1415115053.37.0.0197964842568.issue22795@psf.upfronthosting.co.za>
Message-ID: <1415203540.41.0.72720501094.issue22795@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue20220.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> TarFile.list() outputs wrong time

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

From report at bugs.python.org  Wed Nov  5 17:12:11 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Nov 2014 16:12:11 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415203931.84.0.526423410376.issue22766@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is no purpose served by changing the AttributeError into a TypeError.  It's just extra unneeded code.

----------

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

From report at bugs.python.org  Wed Nov  5 17:36:06 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 05 Nov 2014 16:36:06 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415205366.52.0.23323838173.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I've posted to python-list and python-dev.  I'll report back here the findings, if any.

----------

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

From report at bugs.python.org  Wed Nov  5 18:05:44 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 17:05:44 +0000
Subject: [issue22721] pprint output for sets and dicts is not stable
In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za>
Message-ID: <1415207144.5.0.170735944696.issue22721@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think it'd be nice if the solution kept the current order when all keys are orderable (which is a very common case). So IMO repr() should only be used as a fallback when the object comparison fails.

----------

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

From report at bugs.python.org  Wed Nov  5 18:19:13 2014
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 05 Nov 2014 17:19:13 +0000
Subject: [issue22795] Intermittent test_tarfile failures on zLinux
In-Reply-To: <1415115053.37.0.0197964842568.issue22795@psf.upfronthosting.co.za>
Message-ID: <1415207953.89.0.570669538274.issue22795@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Sorry, I was not aware of the other issue.  Three tests seems to have intermittent failures.

test_datetime
test_tarfile
test_strptime

----------

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

From report at bugs.python.org  Wed Nov  5 18:37:51 2014
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 05 Nov 2014 17:37:51 +0000
Subject: [issue22795] Intermittent test_tarfile failures on zLinux
In-Reply-To: <1415115053.37.0.0197964842568.issue22795@psf.upfronthosting.co.za>
Message-ID: <1415209071.45.0.606266644411.issue22795@psf.upfronthosting.co.za>


David Edelsohn added the comment:

I found the connection but I don't know the cause:

Running test_imaplib prior to either test_datetime or test_tarfile causes the latter test to fail.  test_datetime seems to fix the problem for test_tarfile if it precedes it.

[1/3] test_imaplib
[2/3] test_datetime
test test_datetime failed -- multiple errors occurred; run in verbose mode for details
[3/3/1] test_tarfile
2 tests OK.
1 test failed:
    test_datetime


[1/3] test_imaplib
[2/3] test_tarfile
test test_tarfile failed -- Traceback (most recent call last):
  File "/mnt/9707/edelsohn/src/cpython/Lib/test/test_tarfile.py", line 1953, in test_list_command_verbose
    self.assertEqual(out, expected)
AssertionError: b'?rw[39 chars]-01-05 18:19:43 ustar/conttype \n?rw-r--r-- ta[6470 chars]f \n' != b'?rw[39 chars]-01-06 00:19:43 ustar/conttype \n?rw-r--r-- ta[6470 chars]f \n'

[3/3/1] test_datetime
test test_datetime failed -- multiple errors occurred; run in verbose mode for details
1 test OK.
2 tests failed:
    test_datetime test_tarfile

----------

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

From report at bugs.python.org  Wed Nov  5 18:44:31 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 05 Nov 2014 17:44:31 +0000
Subject: [issue22801] collections.Counter, when empty,
 doesn't raise an error with &= when other is an incompatible type
Message-ID: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>


New submission from Ethan Furman:

test script:
---------------------------------------
from collections import Counter
empty_counter = Counter()
counter = Counter('abbc')
empty_counter &= 5
counter &= 5
---------------------------------------

results:
---------------------------------------
Traceback (most recent call last):
  File "blah.py", line 5, in <module>
    counter &= 5
  File "/home/ethan/source/python/issue22778/Lib/collections/__init__.py", line 780, in __iand__
    other_count = other[elem]
TypeError: 'int' object is not subscriptable
----------------------------------------

As can be seen, the error does not show up when the Counter is empty, which could lead to hard to diagnose bugs.

----------
assignee: rhettinger
files: issue22778.stoneleaf.01.patch
keywords: patch
messages: 230699
nosy: ethan.furman, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: collections.Counter, when empty, doesn't raise an error with &= when other is an incompatible type
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37136/issue22778.stoneleaf.01.patch

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

From report at bugs.python.org  Wed Nov  5 18:44:39 2014
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 05 Nov 2014 17:44:39 +0000
Subject: [issue22795] Intermittent test_tarfile failures on zLinux
In-Reply-To: <1415115053.37.0.0197964842568.issue22795@psf.upfronthosting.co.za>
Message-ID: <1415209479.91.0.686405063711.issue22795@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Its the @run_with_tz decorations in test_imaplib and test_datetime.  The TZ is not being restored after the test.

----------

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

From report at bugs.python.org  Wed Nov  5 18:45:50 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 05 Nov 2014 17:45:50 +0000
Subject: [issue22801] collections.Counter, when empty,
 doesn't raise an error with &= when other is an incompatible type
In-Reply-To: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>
Message-ID: <1415209550.97.0.669172006998.issue22801@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


Removed file: http://bugs.python.org/file37136/issue22778.stoneleaf.01.patch

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

From report at bugs.python.org  Wed Nov  5 18:47:46 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 05 Nov 2014 17:47:46 +0000
Subject: [issue22801] collections.Counter, when empty,
 doesn't raise an error with &= when other is an incompatible type
In-Reply-To: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>
Message-ID: <1415209666.22.0.4662753262.issue22801@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


Added file: http://bugs.python.org/file37137/issue22778.stoneleaf.01.patch

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

From report at bugs.python.org  Wed Nov  5 18:54:15 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 17:54:15 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415210055.05.0.216847381138.issue20220@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I can reproduce under Linux using:

$ TZ='America/New_York' ./python -m test -v test_imaplib test_tarfile test_datetime

----------
nosy: +David.Edelsohn, pitrou

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

From report at bugs.python.org  Wed Nov  5 18:55:56 2014
From: report at bugs.python.org (Matt Frank)
Date: Wed, 05 Nov 2014 17:55:56 +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: <1415210156.26.0.985981134603.issue16353@psf.upfronthosting.co.za>


Changes by Matt Frank <matthew.i.frank at intel.com>:


----------
nosy: +WanderingLogic

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

From report at bugs.python.org  Wed Nov  5 18:56:13 2014
From: report at bugs.python.org (Matt Frank)
Date: Wed, 05 Nov 2014 17:56:13 +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: <1415210173.96.0.048134155491.issue16255@psf.upfronthosting.co.za>


Changes by Matt Frank <matthew.i.frank at intel.com>:


----------
nosy: +WanderingLogic

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

From report at bugs.python.org  Wed Nov  5 19:09:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 18:09:26 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415210966.69.0.126274834293.issue20220@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

We seem to be bitten by the following bit of glibc (?) oddity:

>>> os.environ['TZ'] = 'America/New_York'
>>> time.tzset()
>>> time.daylight, time.timezone, time.altzone, time.tzname
(1, 18000, 14400, ('EST', 'EDT'))
>>> os.environ['TZ'] = 'STD-1DST'
>>> time.tzset()
>>> time.daylight, time.timezone, time.altzone, time.tzname
(1, -3600, -7200, ('STD', 'DST'))
>>> os.environ['TZ'] = 'America/New_York'
>>> time.tzset()
>>> time.daylight, time.timezone, time.altzone, time.tzname
(1, -3600, -7200, ('STD', 'DST'))

----------
nosy: +belopolsky, lemburg
versions: +Python 3.5

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

From report at bugs.python.org  Wed Nov  5 19:13:08 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 18:13:08 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415211188.3.0.957111869485.issue20220@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

First unsetting TZ seems to fix it:

diff --git a/Lib/test/support/__init__.py b/Lib/test/support/__init__.py
--- a/Lib/test/support/__init__.py
+++ b/Lib/test/support/__init__.py
@@ -1507,11 +1507,11 @@ def run_with_tz(tz):
             try:
                 return func(*args, **kwds)
             finally:
-                if orig_tz is None:
-                    del os.environ['TZ']
-                else:
+                del os.environ['TZ']
+                time.tzset()
+                if orig_tz is not None:
                     os.environ['TZ'] = orig_tz
-                time.tzset()
+                    time.tzset()
 
         inner.__name__ = func.__name__
         inner.__doc__ = func.__doc__

----------

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

From report at bugs.python.org  Wed Nov  5 19:41:31 2014
From: report at bugs.python.org (Matt Frank)
Date: Wed, 05 Nov 2014 18:41:31 +0000
Subject: [issue5717] os.defpath includes unix /bin on windows
In-Reply-To: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za>
Message-ID: <1415212890.99.0.969495575541.issue5717@psf.upfronthosting.co.za>


Changes by Matt Frank <matthew.i.frank at intel.com>:


----------
nosy: +WanderingLogic

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

From report at bugs.python.org  Wed Nov  5 19:45:09 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Nov 2014 18:45:09 +0000
Subject: [issue5717] os.defpath includes unix /bin on windows
In-Reply-To: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za>
Message-ID: <1415213109.69.0.0920654117172.issue5717@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/issue5717>
_______________________________________

From report at bugs.python.org  Wed Nov  5 19:50:34 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 05 Nov 2014 18:50:34 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1415213434.36.0.759461900074.issue22650@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I created a repository https://hg.python.org/pythontestdotnet, which is cloned on the server.

----------

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

From report at bugs.python.org  Wed Nov  5 20:12:41 2014
From: report at bugs.python.org (Alex Earl)
Date: Wed, 05 Nov 2014 19:12:41 +0000
Subject: [issue22802] On Windows,
 if you try and use ccs=UTF-8 (or other variants) the U is removed
Message-ID: <1415214761.19.0.969078591014.issue22802@psf.upfronthosting.co.za>


New submission from Alex Earl:

As you can see below, the code in fileobject.c is removing the U from the UTF-8 (or UNICODE) when it tries to replace a U for universal line ending mode.


Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('newfile.txt', 'rt+,ccs=UNICODE')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid mode ('rbt+,ccs=NICODE')
>>> f = open('newfile.txt', 'rt+,ccs=UTF-8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid mode ('rbt+,ccs=TF-8')


It looks to be an issue with the code around:

https://hg.python.org/cpython/file/ee879c0ffa11/Objects/fileobject.c#l283

----------
components: IO, Windows
messages: 230705
nosy: Alex.Earl, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: On Windows, if you try and use ccs=UTF-8 (or other variants) the U is removed
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  5 20:21:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 19:21:44 +0000
Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <20141105192059.85194.49862@psf.io>


Roundup Robot added the comment:

New changeset 5c5909740026 by Georg Brandl in branch '3.4':
Closes #22525: clarify documentation for ast.literal_eval().
https://hg.python.org/cpython/rev/5c5909740026

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

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

From report at bugs.python.org  Wed Nov  5 20:24:25 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Nov 2014 19:24:25 +0000
Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1415215465.21.0.253201714108.issue22525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, Raymond.

----------

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

From report at bugs.python.org  Wed Nov  5 20:27:22 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 19:27:22 +0000
Subject: [issue22525] ast.literal_eval() doesn't do what the documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <20141105192409.723.63761@psf.io>


Roundup Robot added the comment:

New changeset 3e8d3c4bc17e by Georg Brandl in branch '2.7':
Closes #22525: clarify documentation for ast.literal_eval().
https://hg.python.org/cpython/rev/3e8d3c4bc17e

----------

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

From report at bugs.python.org  Wed Nov  5 20:29:09 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Nov 2014 19:29:09 +0000
Subject: [issue22802] On Windows,
 if you try and use ccs=UTF-8 (or other variants) the U is removed
In-Reply-To: <1415214761.19.0.969078591014.issue22802@psf.upfronthosting.co.za>
Message-ID: <1415215749.24.0.122628650139.issue22802@psf.upfronthosting.co.za>


Georg Brandl added the comment:

open() does not support arbitrary platform flags in its mode argument.  To open encoded files and transparently decode them to Unicode strings, please use io.open() on Python 2, and pass the correct "encoding" argument.  On Python 3, the builtin open() is the same as io.open().

----------
nosy: +georg.brandl
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Nov  5 20:50:11 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 19:50:11 +0000
Subject: [issue22784] test_asyncio fails without the ssl module
In-Reply-To: <1414945257.4.0.921150586656.issue22784@psf.upfronthosting.co.za>
Message-ID: <20141105194913.108383.43524@psf.io>


Roundup Robot added the comment:

New changeset 7e9e2b17ac6f by Antoine Pitrou in branch '3.4':
Closes #22784: fix test_asyncio when the ssl module isn't available
https://hg.python.org/cpython/rev/7e9e2b17ac6f

New changeset 028c729714af by Antoine Pitrou in branch 'default':
Closes #22784: fix test_asyncio when the ssl module isn't available
https://hg.python.org/cpython/rev/028c729714af

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

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

From report at bugs.python.org  Wed Nov  5 21:01:15 2014
From: report at bugs.python.org (Matt Frank)
Date: Wed, 05 Nov 2014 20:01:15 +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: <1415217675.7.0.0765393995642.issue16353@psf.upfronthosting.co.za>


Matt Frank added the comment:

Unfortunately os.defpath seems to be hardcoded.  And hardcoded to the wrong value on every system I have looked at, including Linux.

Lib/posixpath.py sets defpath=':/bin:/usr/bin' which is _not_ what `getconf CS_PATH` returns on my Linux (the extra ':' at the beginning means "include the cwd"[1] which is almost certainly not what anyone wants.)  The hardcoded value '/bin:/usr/bin' would also be wrong for Solaris and AIX installations that are trying to be POSIX (I think they use /usr/xpg4/bin/sh).

Meanwhile Lib/macpath.py sets defpath=':', which is also almost certainly wrong.  (I don't have a Mac and have never programmed one, but StackOverflow[2] indicates that one should use `path_helper` (which in turn gets the default value by reading it from the files in /etc/paths.d))[3]  So it seems likely that this patch breaks Popen() on MacOS (unless, perhaps, a path of ':' means something special on Mac?).

And Lib/ntpath.py sets defpath='.;C:\\bin', which doesn't resemble a path that even works (as pointed out in now closed http://bugs.python.org/issue5717).  (The correct value may be '%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\'.)

So I don't know where to go next.  I'm happy to cook up a different patch, but I have no idea what it should be.  Here are some possibilities:

1. Kick the can down the road: file a new bug against os.defpath and (somehow) fix Lib/*path.py so they do something more reasonable in more cases.  One of which might be to have posixpath.py try to call os.confstr() (and then, perhaps, special-code something in Modules/posixmodule.c in the case that HAVE_CONFSTR is not defined.)

2. Modify @akira's patch to call os.confstr('CS_PATH') instead of os.defpath, and then deal with the fact that very few systems actually implement confstr() (perhaps by special-coding something in Modules/posixmodule.c as described above.)

3. Modify this patch to fall back to `PATH` if `sh` can't be found on os.defpath (or os.confstr('CS_PATH') fails).



[1] `man bash` on Linux, search for the description of the PATH variable.  (e.g., http://man7.org/linux/man-pages/man1/bash.1.html)
[2] http://stackoverflow.com/questions/9832770/where-is-the-default-terminal-path-located-on-mac
[3] https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/path_helper.8.html
[4] http://superuser.com/questions/124239/what-is-the-default-path-environment-variable-setting-on-fresh-install-of-window

----------

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

From report at bugs.python.org  Wed Nov  5 21:06:17 2014
From: report at bugs.python.org (Matt Frank)
Date: Wed, 05 Nov 2014 20:06:17 +0000
Subject: [issue5717] os.defpath includes unix /bin on windows
In-Reply-To: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za>
Message-ID: <1415217977.11.0.289172910387.issue5717@psf.upfronthosting.co.za>


Matt Frank added the comment:

os.defpath also seems wrong on Mac (':') and Linux (':/bin:/bin/sh'. The extra ':' at the beginning means the same thing as '.:/bin:/bin/sh' which is probably a security problem.

I just started up discussion on http://bugs.python.org/issue16353 (which may require a correct os.defpath).

----------

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

From report at bugs.python.org  Wed Nov  5 21:13:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 20:13:04 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1415218384.9.0.176620263157.issue21650@psf.upfronthosting.co.za>


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


----------
assignee:  -> berker.peksag

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

From report at bugs.python.org  Wed Nov  5 21:13:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 20:13:33 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1415218413.21.0.0919384232621.issue22695@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Nov  5 21:17:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 20:17:53 +0000
Subject: [issue14260] re.groupindex is available for modification and
 continues to work, having incorrect data inside it
In-Reply-To: <1331530103.22.0.0779581075646.issue14260@psf.upfronthosting.co.za>
Message-ID: <1415218673.89.0.18864049635.issue14260@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov  5 21:34:38 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 05 Nov 2014 20:34:38 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415219678.91.0.73901219156.issue22800@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ncoghlan, pmoody

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

From report at bugs.python.org  Wed Nov  5 21:41:41 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 20:41:41 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415220101.8.0.924437765756.issue22800@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Nov  5 21:42:42 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 05 Nov 2014 20:42:42 +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: <1415220162.3.0.888096052094.issue16353@psf.upfronthosting.co.za>


Ned Deily added the comment:

Matt, ignore Lib/macpath.py.  It is not used on OS X systems other than in the rare case that someone explicitly needs to parse obsolete Classic Mac OS (Mac OS 9 or earlier) style path names.  OS X uses Lib/posixpath.py.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Nov  5 22:18:53 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Nov 2014 21:18:53 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <1415222333.72.0.714375879345.issue22650@psf.upfronthosting.co.za>


Georg Brandl added the comment:

4985375db40f takes care of test_httplib.

----------

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

From report at bugs.python.org  Wed Nov  5 22:57:40 2014
From: report at bugs.python.org (Matthew Hall)
Date: Wed, 05 Nov 2014 21:57:40 +0000
Subject: [issue15824] mutable urlparse return type
In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za>
Message-ID: <1415224660.49.0.294850518923.issue15824@psf.upfronthosting.co.za>


Matthew Hall added the comment:

I don't think having to call a method with a weird secret underscored name to update a value in a URL named tuple is very elegant. Neither is creating a handful of pointless objects to make one simple validator function like the one I had to code today. I would urge some reconsideration of this, like a way to get back a named yet mutable object when needed, instead of trying to force everybody to do this one way which isn't always that great.

def validate_url(url):
    parts = urlparse.urlparse(url.strip())
    # scheme, netloc, path, params, query, fragment
    # XXX: preserve backward compatibility w/ old code
    if not parts.scheme:
        parts = parts._replace(scheme='http', netloc=parts.path.strip('/'), path='')

    # remove params, query, and fragment
    # params is nearly never used anywhere
    # (NOTE: it does NOT mean the stuff after '?')
    # it actually means this http://domain/page.py;param1=foo?query1=bar
    # query and fragment are used but aren't helpful for our application
    parts = parts._replace(params='', query='', fragment='')

    if parts.scheme not in URI_SCHEMES:
        raise ValueError('scheme=%s is not valid' % parts.scheme)
    if '.' not in parts.netloc:
        raise ValueError('location=%s does not contain a domain' % parts.netloc)

    if len(parts.path) and not parts.path.startswith('/'):
        raise ValueError('path=%s appears invalid' % parts.path)
    elif not parts.path:
        parts=parts._replace(path='/')

    validated_url = parts.geturl()
    return validated_url, parts

----------
nosy: +mhcptg

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

From report at bugs.python.org  Wed Nov  5 23:07:09 2014
From: report at bugs.python.org (larkost)
Date: Wed, 05 Nov 2014 22:07:09 +0000
Subject: [issue21367] multiprocessing.JoinableQueue requires new kwarg
In-Reply-To: <1398618734.12.0.810845662855.issue21367@psf.upfronthosting.co.za>
Message-ID: <1415225229.91.0.552286719449.issue21367@psf.upfronthosting.co.za>


larkost added the comment:

We just got bitten by this issue because we are trying to be compatible across 2.x and 3.x (including 3.0-3.2). For anyone who runs into the "missing 1 required keyword-only argument: 'ctx'" here is an import statement that works:

try:
    from multiprocessing import SimpleQueue
except ImportError:
    from multiprocessing.queues import SimpleQueue

Replace SimpleQueue with JoinableQueue if you need that. Importing in the other order will wind you up in problems in 3.4.2+.

----------
nosy: +larkost

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

From report at bugs.python.org  Wed Nov  5 23:10:12 2014
From: report at bugs.python.org (Joshua J Cogliati)
Date: Wed, 05 Nov 2014 22:10:12 +0000
Subject: [issue7562] Custom order for the subcommands of build
In-Reply-To: <1261492513.72.0.435888181618.issue7562@psf.upfronthosting.co.za>
Message-ID: <1415225412.49.0.580935031011.issue7562@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

The documentation does claim that swig should just work "the build_ext command knows how to deal with SWIG extensions: it will run SWIG on the interface file and compile the resulting C/C++ file into your extension."

It would be nice if there was one obvious way to compile a swig extension.  (See for example the workarounds suggested in http://stackoverflow.com/questions/12491328 )

----------
nosy: +Joshua.J.Cogliati

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

From report at bugs.python.org  Wed Nov  5 23:18:47 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 05 Nov 2014 22:18:47 +0000
Subject: [issue15824] mutable urlparse return type
In-Reply-To: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za>
Message-ID: <1415225927.47.0.945700354046.issue15824@psf.upfronthosting.co.za>


R. David Murray added the comment:

Think of it as immutable like a string is immutable.  The cases are exactly parallel (the string function is of course named 'replace' since it doesn't have to deal with the 'arbitrary attribute names' problem namedtuple does), except that it is much easier to address the parts of a url using the namedtuple.

_replace is not a "weird secrete method", it is part of the public API of namedtuple.  I agree that using '_' is unfortunate.  I would have preferred a name pattern like _replace_, to make it clearer that it is *not* a private method.

----------

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

From report at bugs.python.org  Thu Nov  6 00:59:01 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 23:59:01 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415231941.43.0.344798811149.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Paul, Tim, do you think there's a real risk of regression with the proposed patch?

----------
stage:  -> commit review
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov  6 01:47:47 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 06 Nov 2014 00:47:47 +0000
Subject: [issue16353] add function to os module for getting path to default
 shell
In-Reply-To: <1415217675.7.0.0765393995642.issue16353@psf.upfronthosting.co.za>
 (Matt Frank's message of "Wed, 05 Nov 2014 20:01:15 +0000")
Message-ID: <8761et6tqg.fsf@gmail.com>


Akira Li added the comment:

> Matt Frank added the comment:
>
> Unfortunately os.defpath seems to be hardcoded.  And hardcoded to the
> wrong value on every system I have looked at, including Linux.

os.defpath is supposed to be ':'+CS_PATH, e.g., look at glibc (C library
used on Linux) sysdeps/posix/spawni.c I don't know whether it is
possible to change CS_PATH without recompiling every statically linked
executable on a system, sysdeps/unix/confstr.h:

  #define CS_PATH "/bin:/usr/bin"

Though this issue is about the path to the standard shell sh/cmd.exe.
It is not about os.defpath.

The patch [1] has tests. Have you tried to run them?
The tests *pass* at least on one system ;)

[1] http://bugs.python.org/review/16353/#ps12569

To run the tests, download the patch into your python checkout:

  $ curl -O \
  http://bugs.python.org/file36196/os.get_shell_executable.patch

and apply it:

  $ patch -p1< os.get_shell_executable.patch

to run only test_os.py:

  $ ./python -mtest test_os

> Lib/posixpath.py sets defpath=':/bin:/usr/bin' which is _not_ what
> getconf CS_PATH` returns on my Linux (the extra ':' at the beginning
> means "include the cwd" which is almost certainly not what anyone
> wants.) 

os.get_shell_executable() does not use cwd. Neither the documentation
nor the code in the patch suggest that.

> The hardcoded value '/bin:/usr/bin' would also be wrong for
> Solaris and AIX installations that are trying to be POSIX (I think
> they use /usr/xpg4/bin/sh).

os.defpath is the default search path used by exec*p* and spawn*p*
i.e., if os.defpath is incorrect for these system then os.exec*p* and
os.spawn*p* functions could also be broken.

I expect that Windows, OS X, Linux work as is. If the tests fail on
Solaris, AIX then os.defpath should be tweaked on these systems if it
hasn't been already. Note: os.defpath is a very conservative value: it
should be set at python's installation time at the very
latest. Henceforth it should remain the same.

> And Lib/ntpath.py sets defpath='.;C:\\bin', which doesn't resemble a
> path that even works (as pointed out in now closed
> http://bugs.python.org/issue5717).  (The correct value may be
> %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\'.)

Please, look at the patch. Neither the documentation nor the code
suggest that os.defpath is used on Windows.

> So I don't know where to go next.  I'm happy to cook up a different
> patch, but I have no idea what it should be.  Here are some
> possibilities:
>
> 1. Kick the can down the road: file a new bug against os.defpath and
> (somehow) fix Lib/*path.py so they do something more reasonable in
> more cases.  One of which might be to have posixpath.py try to call
> os.confstr() (and then, perhaps, special-code something in
> Modules/posixmodule.c in the case that HAVE_CONFSTR is not defined.)
>
> 2. Modify @akira's patch to call os.confstr('CS_PATH') instead of
> os.defpath, and then deal with the fact that very few systems actually
> implement confstr() (perhaps by special-coding something in
> Modules/posixmodule.c as described above.)

Note I'm the author of http://bugs.python.org/issue16353#msg224514
message that references the POSIX recommendation about `getconf PATH`
and *explicitly* mentions os.confstr('CS_PATH').

I don't remember exactly the motivation to use os.defpath instead of
os.confstr('CS_PATH').

A guess: the result is the same (a lone `:` is ignored in the patch) but
os.defpath is easier to modify for uncommon systems where os.confstr
might not be available.

I expect that the tests in the patch will pass on all stable buildbots
[2] successfully without any modifications (with os.defpath as is).

[2] http://buildbot.python.org/all/waterfall?category=3.x.stable

Other systems should probably configure os.defpath appropriately (it
should include the path to the standard shell).

> 3. Modify this patch to fall back to `PATH` if `sh` can't be found on
> os.defpath (or os.confstr('CS_PATH') fails).

The standard shell should not depend on PATH envvar. The tests show that
os.get_shell_executable() works even with an empty environment. The
motivation is the same as why `getconf PATH` exists in the first place.

The documentation for os.get_shell_executable() (from the patch):

   Return a path to the standard system shell executable -- ``sh``
   program on POSIX (default: ``'/bin/sh'``) or ``%ComSpec%`` command
   processor on Windows (default: ``%SystemRoot%\system32\cmd.exe``).

   Availability: Unix, Windows

The intent is that os.get_shell_executable() returns the same *shell
path* as used by system(3) on POSIX i.e., (ignoring signals,
etc) os.system(command) could be implemented:

  subprocess.call(command, shell=True, executable=os.get_shell_executable())

(presumably subprocess can use get_shell_executable() internally instead
of /bin/sh but it is another issue)

----------

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

From report at bugs.python.org  Thu Nov  6 02:10:49 2014
From: report at bugs.python.org (Tim Graham)
Date: Thu, 06 Nov 2014 01:10:49 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415236249.43.0.584945072697.issue22796@psf.upfronthosting.co.za>


Tim Graham added the comment:

Security-wise? I don't know, I haven't really been in the loop on the original issue.

----------

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

From report at bugs.python.org  Thu Nov  6 04:31:17 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Nov 2014 03:31:17 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <20141106033102.113466.30926@psf.io>


Roundup Robot added the comment:

New changeset f75b0470168b by Steve Dower in branch '2.7':
Issue #20160: broken ctypes calling convention on MSVC / 64-bit Windows (large structs). Patch by mattip
https://hg.python.org/cpython/rev/f75b0470168b

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

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

From report at bugs.python.org  Thu Nov  6 04:31:27 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Nov 2014 03:31:27 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <20141106033126.719.30342@psf.io>


Roundup Robot added the comment:

New changeset cd36ba22602d by Steve Dower in branch '3.4':
Issue #20160: broken ctypes calling convention on MSVC / 64-bit Windows (large structs) Patch by mattip
https://hg.python.org/cpython/rev/cd36ba22602d

New changeset b701eb69260d by Steve Dower in branch 'default':
Issue #20160: broken ctypes calling convention on MSVC / 64-bit Windows (large structs) Patch by mattip
https://hg.python.org/cpython/rev/b701eb69260d

----------

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

From report at bugs.python.org  Thu Nov  6 04:32:28 2014
From: report at bugs.python.org (Steve Dower)
Date: Thu, 06 Nov 2014 03:32:28 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1415244748.25.0.508364365067.issue20160@psf.upfronthosting.co.za>


Steve Dower added the comment:

Done. Thanks mattip!

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

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

From report at bugs.python.org  Thu Nov  6 05:35:13 2014
From: report at bugs.python.org (Christopher Foo)
Date: Thu, 06 Nov 2014 04:35:13 +0000
Subject: [issue22803] textwrap.indent version added not documented
Message-ID: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>


New submission from Christopher Foo:

I was running my program under CI and it failed under 3.2:

    text = textwrap.indent(text, '* ', predicate=lambda line: True)

    AttributeError: 'module' object has no attribute 'indent'

textwrap.indent appears to be a new feature in 3.3 but Doc/library/textwrap.rst is not documented with ".. versionadded:: 3.3"

----------
assignee: docs at python
components: Documentation
messages: 230725
nosy: chfoo, docs at python
priority: normal
severity: normal
status: open
title: textwrap.indent version added not documented
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Nov  6 06:28:33 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Nov 2014 05:28:33 +0000
Subject: [issue22803] textwrap.indent version added not documented
In-Reply-To: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>
Message-ID: <20141106052826.85216.52649@psf.io>


Roundup Robot added the comment:

New changeset 501edbbb74ff by Raymond Hettinger in branch '3.4':
Issue 22803:  Add missing versionadded directive.
https://hg.python.org/cpython/rev/501edbbb74ff

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

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

From report at bugs.python.org  Thu Nov  6 06:28:58 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Nov 2014 05:28:58 +0000
Subject: [issue22803] textwrap.indent version added not documented
In-Reply-To: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>
Message-ID: <1415251738.96.0.457239889501.issue22803@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the bug report.

----------
nosy: +rhettinger
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Nov  6 08:31:04 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Nov 2014 07:31:04 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415259064.93.0.160767122519.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

No, I meant functionality-wise.

----------

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

From report at bugs.python.org  Thu Nov  6 09:56:16 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Nov 2014 08:56:16 +0000
Subject: [issue22735] Fix various crashes exposed through mro() customization
In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za>
Message-ID: <1415264176.31.0.985755598135.issue22735@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think forbidding reentrancy would indeed be a good idea.

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Nov  6 10:15:20 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Nov 2014 09:15:20 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415265320.77.0.278616956252.issue22789@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

FWIW, I personally doubt this would actually reduce startup time. Disk I/O cost is in the first access, not in the transfer size (unless we're talking hundreds of megabytes). But in any case, someone interested has to do measurements :-)

----------

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

From report at bugs.python.org  Thu Nov  6 10:40:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 09:40:18 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415266818.09.0.535437542898.issue20220@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be issue6478 is related.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Thu Nov  6 11:10:49 2014
From: report at bugs.python.org (nx u)
Date: Thu, 06 Nov 2014 10:10:49 +0000
Subject: [issue22804] Can't run Idle in Windows 8 or windows 64
Message-ID: <1415268649.04.0.373697042917.issue22804@psf.upfronthosting.co.za>


New submission from nx u:

Hi,

I have just downloaded and installed python34. When I run the short cut  IDLE python gui nothing happens  ( I think a command window appears briefly - not sure as this happens so quickly).  My machine runs windows 8 and 64 bit version of . I did the same on a windows 7 64 bit machine and double clicking the Python IDLE gui 32 bit doesn't work.

Not quite sure what's going on. Our machines are located in a school with GPOs controlling access and security. I am from the ICT support team. There isn't much reported on this issue on the internet either except a couple of entries in stackoverflow. But the solutions offered are far off the mark. Please help. The documentation on the Python web site is not clear or not detailed enough to diagnose the fault.

----------
components: IDLE
messages: 230732
nosy: nx.u
priority: normal
severity: normal
status: open
title: Can't run Idle in Windows 8 or windows 64
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  6 11:14:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 10:14:21 +0000
Subject: [issue19102] Add tests for CLI of the tabnanny module
In-Reply-To: <1380282068.15.0.580247887303.issue19102@psf.upfronthosting.co.za>
Message-ID: <1415268861.64.0.261283880474.issue19102@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

Although tabnanny is located in the Lib directory, not in the Tools directory, technically it is a script. May be move test_tabnanny.py to Lib/test/test_tools?

----------
assignee:  -> berker.peksag
nosy: +serhiy.storchaka
type:  -> enhancement
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Thu Nov  6 12:18:26 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 06 Nov 2014 11:18:26 +0000
Subject: [issue7559] TestLoader.loadTestsFromName swallows import errors
In-Reply-To: <1261429637.28.0.131724711132.issue7559@psf.upfronthosting.co.za>
Message-ID: <1415272706.6.0.712560819929.issue7559@psf.upfronthosting.co.za>


Robert Collins added the comment:

Its backported in unittest2 0.8.0 which is available on pypi for 2.6+ and 3.2+.

The changes are large enough that I'd hesitate to backport them in cPython itself.

----------

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

From report at bugs.python.org  Thu Nov  6 12:20:35 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 06 Nov 2014 11:20:35 +0000
Subject: [issue22804] Can't run Idle in Windows 8 or windows 64
In-Reply-To: <1415268649.04.0.373697042917.issue22804@psf.upfronthosting.co.za>
Message-ID: <1415272835.03.0.476050417656.issue22804@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

You can try to run IDLE from a command prompt. Type the command:
  path_to_python34.exe -m idlelib

and look at error messages.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Thu Nov  6 12:58:01 2014
From: report at bugs.python.org (Kovid Goyal)
Date: Thu, 06 Nov 2014 11:58:01 +0000
Subject: [issue15500] Python should support naming threads
In-Reply-To: <1343650770.87.0.181202709436.issue15500@psf.upfronthosting.co.za>
Message-ID: <1415275081.46.0.928838965561.issue15500@psf.upfronthosting.co.za>


Kovid Goyal added the comment:

Just FYI, a pure python2 implementation that monkey patches Thread.start() to set the OS level thread name intelligently.

        import ctypes, ctypes.util, threading
        libpthread_path = ctypes.util.find_library("pthread")
        if libpthread_path:
            libpthread = ctypes.CDLL(libpthread_path)
            if hasattr(libpthread, "pthread_setname_np"):
                pthread_setname_np = libpthread.pthread_setname_np
                pthread_setname_np.argtypes = [ctypes.c_void_p, ctypes.c_char_p]
                pthread_setname_np.restype = ctypes.c_int
                orig_start = threading.Thread.start
                def new_start(self):
                    orig_start(self)
                    try:
                        name = self.name
                        if not name or name.startswith('Thread-'):
                            name = self.__class__.__name__
                            if name == 'Thread':
                                name = self.name
                        if name:
                            if isinstance(name, unicode):
                                name = name.encode('ascii', 'replace')
                            ident = getattr(self, "ident", None)
                            if ident is not None:
                                pthread_setname_np(ident, name[:15])
                    except Exception:
                        pass  # Don't care about failure to set name
                threading.Thread.start = new_start

----------
nosy: +kovid

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

From report at bugs.python.org  Thu Nov  6 14:01:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 13:01:18 +0000
Subject: [issue20289] Make cgi.FieldStorage a context manager
In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za>
Message-ID: <1415278878.92.0.859151913163.issue20289@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------
nosy: +serhiy.storchaka
type: behavior -> enhancement

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

From report at bugs.python.org  Thu Nov  6 14:15:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 13:15:25 +0000
Subject: [issue21579] Python 3.4: tempfile.close attribute does not work
In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za>
Message-ID: <1415279725.01.0.558098959813.issue21579@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If it is possible to cancel the effect of the O_TEMPORARY flag, we can use it to implement this feature on all platforms. But if it is not possible, we have several options:

1. Just close this issue and do nothing more. This was undocumented and non-portable feature.

2. Implement delete as readonly property. This is similar to 1 but makes the failure loud.

3. Implement this feature on non-Windows, document that it is non-Windows only feature, and raise an exception in delete setter on Windows.

4. Same as 3, but emit deprecation warning in delete setter on non-Windows. In future this should be replaced with solution 2.

----------

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

From report at bugs.python.org  Thu Nov  6 14:38:53 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Nov 2014 13:38:53 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <20141106133832.85190.63920@psf.io>


Roundup Robot added the comment:

New changeset 39536b377241 by Georg Brandl in branch '3.4':
#22650: test suite: load Unicode test data files from www.pythontest.net
https://hg.python.org/cpython/rev/39536b377241

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

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

From report at bugs.python.org  Thu Nov  6 14:42:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 13:42:22 +0000
Subject: [issue21579] Python 3.4: tempfile.close attribute does not work
In-Reply-To: <1401083279.44.0.182194375794.issue21579@psf.upfronthosting.co.za>
Message-ID: <1415281342.4.0.0103653134261.issue21579@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue14243.

----------

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

From report at bugs.python.org  Thu Nov  6 14:48:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 13:48:44 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415281724.68.0.00773359525784.issue22766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I've posted to python-list and python-dev.  I'll report back here the findings, if any.

http://comments.gmane.org/gmane.comp.python.devel/150073

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

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

From report at bugs.python.org  Thu Nov  6 14:50:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 13:50:51 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1415281851.83.0.863601116345.issue19094@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

About acceptable behavior with wrong arguments types see discussions in issue22766 and http://comments.gmane.org/gmane.comp.python.devel/150073 .

----------
nosy: +serhiy.storchaka
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Nov  6 14:57:05 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Nov 2014 13:57:05 +0000
Subject: [issue22650] set up and use VM for net access in the test suite
In-Reply-To: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>
Message-ID: <20141106135652.113454.91139@psf.io>


Roundup Robot added the comment:

New changeset 0af36ea1d010 by Georg Brandl in branch '2.7':
#22650: test suite: load Unicode test data files from www.pythontest.net
https://hg.python.org/cpython/rev/0af36ea1d010

----------

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

From report at bugs.python.org  Thu Nov  6 15:08:52 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Nov 2014 14:08:52 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415282932.68.0.986139742656.issue20220@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> May be issue6478 is related.

I'm not sure. issue6478 looks like a Python stdlib bug, while this issue looks like a libc problem.

----------

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

From report at bugs.python.org  Thu Nov  6 15:09:36 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Nov 2014 14:09:36 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415282976.26.0.654975780917.issue20220@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

David, could you try the patch in msg230703 and see if it fixes the problem on your buildbot?

----------

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

From report at bugs.python.org  Thu Nov  6 15:45:25 2014
From: report at bugs.python.org (David Edelsohn)
Date: Thu, 06 Nov 2014 14:45:25 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415285125.7.0.63446926177.issue20220@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Unfortunately, the patch does not fix the failures of running test_imaplib before test_tarfile or test_datetime.

----------

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

From report at bugs.python.org  Thu Nov  6 15:48:35 2014
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Nov 2014 14:48:35 +0000
Subject: [issue22805] Having pythontest.net index.html link to hg repo
Message-ID: <1415285315.17.0.355776153146.issue22805@psf.upfronthosting.co.za>


New submission from Brett Cannon:

For pythontest.net, it would be nice if the index.html page that is (supposed to be) served linked to the hg repo to make it more discoverable how to add files to the domain.

----------
assignee: brett.cannon
messages: 230747
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Having pythontest.net index.html link to hg repo
type: enhancement

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

From report at bugs.python.org  Thu Nov  6 15:59:16 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2014 14:59:16 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
Message-ID: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>


New submission from Georg Brandl:

A quick way to select only tests that are modified in the checkout.

----------
components: Tests
files: regrtest_changed.diff
keywords: patch
messages: 230748
nosy: georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: regrtest: add switch -c to run only modified tests
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37138/regrtest_changed.diff

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

From report at bugs.python.org  Thu Nov  6 16:21:38 2014
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 06 Nov 2014 15:21:38 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1415281724.68.0.00773359525784.issue22766@psf.upfronthosting.co.za>
Message-ID: <CA+OGgf5wgyLaXqRYqLsHj72aUV4a3NZ073RwPsOjhSKmtoZWcA@mail.gmail.com>


Jim Jewett added the comment:

I wish there were an APIMismatchError superclass to unify
(AttributeError, TypeError).  But the wart probably isn't enough to
justify the surgery.

On Thu, Nov 6, 2014 at 8:48 AM, Serhiy Storchaka <report at bugs.python.org> wrote:
>
> Serhiy Storchaka added the comment:
>
>> I've posted to python-list and python-dev.  I'll report back here the findings, if any.
>
> http://comments.gmane.org/gmane.comp.python.devel/150073
>
> ----------
> nosy: +serhiy.storchaka
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22766>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Nov  6 16:39:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Nov 2014 15:39:59 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1415288399.61.0.980240957896.issue22806@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately this doesn't work with tests for pickle, json or tkinter.

I'm afraid this feature would make false promise. Without careful check you can not be confident that all modified tests are selected. If you going to add this switch, it should emit a

********************
*                  *
*   LOUD WARNING   *
*                  *
********************

and enumerate all modified files containing 'test' in its path which are not recognized as valid test name.

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

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

From report at bugs.python.org  Thu Nov  6 16:58:54 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 06 Nov 2014 15:58:54 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1415289534.67.0.99875835639.issue22806@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I agree this is more dangerous than useful.
(even if you haven't modified a test it may still be impacted by some other change)

----------

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

From report at bugs.python.org  Thu Nov  6 17:28:51 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2014 16:28:51 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1415291331.74.0.383020386971.issue22806@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, this is not meant as a comprehensive "run ALL impacted tests" because that is impossible in general :)

An alternate suggestion would be to allow filenames like "Lib/test/test_foo.py" as arguments to regrtest. Then I could run without the switch using

.../regrtest.py `hg status -amn`

----------

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

From report at bugs.python.org  Thu Nov  6 17:48:49 2014
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 06 Nov 2014 16:48:49 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1415292529.0.0.899166397902.issue20160@psf.upfronthosting.co.za>


Matthias Klose added the comment:

steve, please can we keep this issue open until this is forwarded and accepted upstream?

----------
nosy: +doko
resolution: fixed -> remind
status: closed -> open

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

From report at bugs.python.org  Thu Nov  6 17:54:29 2014
From: report at bugs.python.org (Matt Frank)
Date: Thu, 06 Nov 2014 16:54:29 +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: <1415292869.44.0.690170855157.issue16353@psf.upfronthosting.co.za>


Matt Frank added the comment:

In msg174930 Christian Heimes (christian.heimes) wrote:
> I've tested confstr("CS_PATH") on Linux, Mac OS X, Solaris, HP-UX
> and BSD. It works and the path to `sh` is always included.

In msg230713 Ned Deily(ned.deily) wrote:
> ignore Lib/macpath.py.
> [...]
> OS X uses Lib/posixpath.py.

These two messages have convinced me that the correct approach is to kick the can down the road.  I will file a new issue and patch to fix os.defpath (by initializing os.defpath by calling confstr("CS_PATH")).  Then I will file a new issue and patch that will define a reasonable os.confstr() for platforms where HAVE_CONFSTR is not defined.

----------

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

From report at bugs.python.org  Thu Nov  6 18:26:05 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Nov 2014 17:26:05 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1415294765.35.0.120963827819.issue22806@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov  6 19:25:14 2014
From: report at bugs.python.org (Matt Frank)
Date: Thu, 06 Nov 2014 18:25:14 +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: <1415298314.32.0.0430576457537.issue16353@psf.upfronthosting.co.za>


Matt Frank added the comment:

In msg230720 Akira Li (akira) wrote:
> os.defpath is supposed to be ':'+CS_PATH, e.g., look at glibc (C library
> used on Linux) sysdeps/posix/spawni.c I don't know whether it is
> possible to change CS_PATH without recompiling every statically linked
> executable on a system, sysdeps/unix/confstr.h:
>
>   #define CS_PATH "/bin:/usr/bin"
>
> Though this issue is about the path to the standard shell sh/cmd.exe.
> It is not about os.defpath.

I understand this issue is about the path to the standard shell.
My argument is that os.defpath is the wrong tool for finding that
path, and os.confstr('CS_PATH') is the correct tool, as you originally
suggested in msg224514.

> The patch [1] has tests. Have you tried to run them?
> The tests *pass* at least on one system ;)
>
> [...]
>
> os.get_shell_executable() does not use cwd. Neither the documentation
> nor the code in the patch suggest that.

I ran the tests (and the entire Python test suite) before I wrote my
first message.  But you didn't test what happens when there is a bogus
'sh' somewhere along the path.  You also have a bug in your path
searching loop that interprets an empty element on the path as "/".
Here's the current failure mode:

Go to root on your Posix system.  With "su" or "sudo" create an
executable file named sh.  (for example "cd /; sudo touch sh; sudo
chmod +x sh").  Then go back to your python interpreter (with the
patch applied) and run "os.get_shell_executable()".  The returned
result will be '/sh'.

The loop _should_ be treating empty path elements as current working
directory.  (In the glibc sysdeps/posix/spawni.c file you pointed to
look around line 281, by the comment that says "/* Two adjacent
colons, or a colon at the beginning or the end of 'PATH' means to
search the current directory.*/")

But if you fix the loop to iterate over the path correctly (including
'cwd') then you will find that putting an executable named 'sh' in the
current working directory will make os.get_shell_executable() return
the "sh" in the current working directory (because os.defpath says it
should).

Note also, that glibc's spawni() uses two different "default paths".
One is for if the user didn't specify their PATH variable (that's the
one where they use ":/bin:/usr/bin") and a completely different (built
in path is used in the spawn*p* version) if it turns out that the file
is a script that needs to run under the system sh.  (On line 290 they
call maybe_script_execute(), which calls script_execute(), which uses
_PATH_BSHELL.)

> os.defpath is the default search path used by exec*p* and spawn*p*
> i.e., if os.defpath is incorrect for these system then os.exec*p* and
> os.spawn*p* functions could also be broken.

I'll look into it.

> I don't remember exactly the motivation to use os.defpath instead of
> os.confstr('CS_PATH').

The motivation was in msg224514.  You wrote:
> In the absense of os.confstr('CS_PATH') on Android (msg175006),
> os.defpath seems appropriate than os.environ['PATH'] to expand 'sh'
> basename to the full path to be used by subprocess later.

But os.defpath doesn't work on Android either (because it is hardcoded
to ':/bin:/usr/bin').

----------

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

From report at bugs.python.org  Thu Nov  6 19:59:59 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 06 Nov 2014 18:59:59 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415300399.94.0.353557892875.issue22789@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

FWIW, LZ4HC compression sounds like an obvious choice for write-once-read-many data like .pyc files to me. Blosc shows that you can achieve a pretty major performance improvement just by stuffing more data into less space (although it does it for RAM and CPU cache, not disk). And even if it ends up not being substantially faster for the specific case of .pyc files, there is really no reason why they should take more space on disk than necessary, so it's a sure win in any case.

----------
nosy: +scoder

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

From report at bugs.python.org  Thu Nov  6 20:08:33 2014
From: report at bugs.python.org (Matt Frank)
Date: Thu, 06 Nov 2014 19:08:33 +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: <1415300913.83.0.611412310806.issue16255@psf.upfronthosting.co.za>


Matt Frank added the comment:

Assuming issue16353 is fixed using http://bugs.python.org/file36196/os.get_shell_executable.patch the appropriate way to find the path to the default shell is by calling os.get_shell_executable().

This is the 1-liner patch that uses os.get_shell_executable() in Popen() instead of the hard-coded string "/bin/sh".

----------
keywords: +patch
Added file: http://bugs.python.org/file37139/popen-no-hardcode-bin-sh.patch

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

From report at bugs.python.org  Thu Nov  6 20:41:22 2014
From: report at bugs.python.org (Tim Graham)
Date: Thu, 06 Nov 2014 19:41:22 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1415302882.63.0.309286629617.issue22796@psf.upfronthosting.co.za>


Tim Graham added the comment:

Django's test suite doesn't reveal any regressions. All the changes there are expected as far as I can see.

----------

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

From report at bugs.python.org  Thu Nov  6 21:07:26 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2014 20:07:26 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
Message-ID: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

I'm classifying this as a security issue, since using uuid_generate_time() -- i.e. the not _safe() variety -- does return collisions in real world cases that we've seen, and those could have security implications. However, I don't know that this can be exploited in any real world cases, so I'm not making it private or sending to security at .

The basic problem is that uuid.uuid1() uses uuid_generate_time(3), but if the synchronization methods used in that C function's manpage are not used, then two concurrent processes can -- and do in our cases -- return the same UUID.

I would propose that if uuid_generate_time_safe() is available, this should be used instead, and the return value should be checked to see if a safe method was used.  If not, then uuid1() should fall back to the pure-Python approach.

----------
components: Library (Lib)
keywords: security_issue
messages: 230759
nosy: barry
priority: normal
severity: normal
status: open
title: uuid.uuid1() should use uuid_generate_time_safe() if available
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Nov  6 21:10:09 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 06 Nov 2014 20:10:09 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>
Message-ID: <1415304609.69.0.847515590166.issue22807@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

FWIW, I'm not convinced the pure python fallback code is sufficient either; time.time() doesn't have the necessary resolution AFAIK? Also clock_seq is generated using the random module's messerne twister, not SystemRandom().

----------
nosy: +alex

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

From report at bugs.python.org  Thu Nov  6 21:18:31 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 06 Nov 2014 20:18:31 +0000
Subject: [issue16353] add function to os module for getting path to default
 shell
In-Reply-To: <1415298314.32.0.0430576457537.issue16353@psf.upfronthosting.co.za>
 (Matt Frank's message of "Thu, 06 Nov 2014 18:25:14 +0000")
Message-ID: <87zjc45bja.fsf@gmail.com>


Akira Li added the comment:

> Matt Frank added the comment:
>
> In msg230720 Akira Li (akira) wrote:
>> os.defpath is supposed to be ':'+CS_PATH, e.g., look at glibc (C library
>> used on Linux) sysdeps/posix/spawni.c I don't know whether it is
>> possible to change CS_PATH without recompiling every statically linked
>> executable on a system, sysdeps/unix/confstr.h:
>>
>>   #define CS_PATH "/bin:/usr/bin"
>>
>> Though this issue is about the path to the standard shell sh/cmd.exe.
>> It is not about os.defpath.
>
> I understand this issue is about the path to the standard shell.
> My argument is that os.defpath is the wrong tool for finding that
> path, and os.confstr('CS_PATH') is the correct tool, as you originally
> suggested in msg224514.
>

I'll repeat os.defpath definition that I've cited in the same message
msg224514:

  The default search path used by exec*p* and spawn*p* if the
  environment doesn?t have a 'PATH' key. Also available via os.path.

1. os.defpath should work (contain the path to the standard shell)
   everywhere where os.confstr("CS_PATH") works.

2. And it might be easier to customize e.g., on systems where there is
   no os.confstr or where changing CS_PATH involves recompiling crucial
   system processes.

If these two statements are not true then os.defpath could be dropped.

>> The patch [1] has tests. Have you tried to run them?
>> The tests *pass* at least on one system ;)
>>
>> [...]
>>
>> os.get_shell_executable() does not use cwd. Neither the documentation
>> nor the code in the patch suggest that.
>
> I ran the tests (and the entire Python test suite) before I wrote my
> first message.  But you didn't test what happens when there is a bogus
> 'sh' somewhere along the path.  You also have a bug in your path
> searching loop that interprets an empty element on the path as "/".
> Here's the current failure mode:
>
> Go to root on your Posix system.  With "su" or "sudo" create an
> executable file named sh.  (for example "cd /; sudo touch sh; sudo
> chmod +x sh").  Then go back to your python interpreter (with the
> patch applied) and run "os.get_shell_executable()".  The returned
> result will be '/sh'.
> But if you fix the loop to iterate over the path correctly (including
> 'cwd') then you will find that putting an executable named 'sh' in the
> current working directory will make os.get_shell_executable() return
> the "sh" in the current working directory (because os.defpath says it
> should).
>

Comment in the patch explicitly says that '' is interpreted as '/'. The
intent is to exclude the current working directory, thinking that /sh
executable can create only root. And root can do anything to the machine
anyway.

I agree. It is a misfeature. I've uploaded a new patch that excludes ''
completely. The previous code tried to be too cute.

> The loop _should_ be treating empty path elements as current working
> directory.  (In the glibc sysdeps/posix/spawni.c file you pointed to
> look around line 281, by the comment that says "/* Two adjacent
> colons, or a colon at the beginning or the end of 'PATH' means to
> search the current directory.*/")

yes. Empty path element stands for the current working directory e.g.,

   $ PATH= python
   $ PATH=: python
   $ PATH=:/ python
   $ PATH=/: python

run ./python on my system.

The current working directory is intentionally excluded (in the original
and in the current patches) otherwise os.get_exec_path(env={}) would be
used.

> Note also, that glibc's spawni() uses two different "default paths".
> One is for if the user didn't specify their PATH variable (that's the
> one where they use ":/bin:/usr/bin") and a completely different (built
> in path is used in the spawn*p* version) if it turns out that the file
> is a script that needs to run under the system sh.  (On line 290 they
> call maybe_script_execute(), which calls script_execute(), which uses
> _PATH_BSHELL.)

glibc hardcodes the path (like subprocess module does currently):

  #define	_PATH_BSHELL	"/bin/sh"

os.get_shell_executable() is an enhancement that allows
(Unix) systems to configure the path via os.defpath.

> But os.defpath doesn't work on Android either (because it is hardcoded
> to ':/bin:/usr/bin').

As I've mentioned in msg224514 before posting my original patch:

- "Andriod uses /system/bin/sh"
- "os.defpath could be tweaked on Android"

i.e., yes. Default os.defpath doesn't work there and it should be
configured on Android to include the path to the standard shell.

----------

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

From report at bugs.python.org  Thu Nov  6 21:19:45 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 06 Nov 2014 20:19:45 +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: <1415305184.99.0.959007131538.issue16353@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Added file: http://bugs.python.org/file37140/os.get_shell_executable-3.patch

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

From report at bugs.python.org  Thu Nov  6 21:29:02 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2014 20:29:02 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
In-Reply-To: <1415304609.69.0.847515590166.issue22807@psf.upfronthosting.co.za>
Message-ID: <20141106152850.16d37545@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Nov 06, 2014, at 08:10 PM, Alex Gaynor wrote:

>FWIW, I'm not convinced the pure python fallback code is sufficient either;
>time.time() doesn't have the necessary resolution AFAIK? Also clock_seq is
>generated using the random module's messerne twister, not SystemRandom().

Perhaps, but that's a different bug. ;)

-----snip snip-----
from uuid import UUID
import ctypes
import ctypes.util

lib = ctypes.CDLL(ctypes.util.find_library('uuid'))
_ugts = lib.uuid_generate_time_safe

_buffer = ctypes.create_string_buffer(16)
retval = _ugts(_buffer)

# Remember, this is C!
is_safe = (retval == 0)

print('{} is safe? {}'.format(UUID(bytes=_buffer.raw), is_safe))
-----snip snip-----

On Ubuntu 14.10, gives me:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is safe? True

----------

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

From report at bugs.python.org  Thu Nov  6 21:38:18 2014
From: report at bugs.python.org (Steve Dower)
Date: Thu, 06 Nov 2014 20:38:18 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1415306298.57.0.500920068797.issue20160@psf.upfronthosting.co.za>


Steve Dower added the comment:

Upstream as in libffi? I'm fairly sure they've fixed it already, but their current code bears little relation to what we have, so it's not easy to tell and I didn't look all that closely.

Who's doing the forwarding?

----------

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

From report at bugs.python.org  Thu Nov  6 22:07:10 2014
From: report at bugs.python.org (Mark Grandi)
Date: Thu, 06 Nov 2014 21:07:10 +0000
Subject: [issue22808] Typo in asyncio-eventloop.rst, time() link is wrong
Message-ID: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>


New submission from Mark Grandi:

In the asyncio documentation, specifically asyncio-eventloop.rst, in the description for BaseEventLoop.call_at(), it has:

   Arrange for the *callback* to be called at the given absolute timestamp *when* (an int or float), using the same time reference as :meth:`time`.

This links to the time module's time.time() method, which is incorrect as well as confusing, as the event loop's clock is NOT the same as time.time(), and it even says so on the top of the 'delayed calls' section

According the python documentation guide, it should have a period before it to make it refer to a method that is within the same module. I however decided to change it to `BaseEventLoop.time()`, because when i  see the text 'time()', even if it links to the right method, still makes me think of time.time(), which is again confusing and generally incorrect. 

Attached is a patch file, its a trivial change, but i did regenerate the docs and confirmed that it works, and clicking the link takes you to the right method in the page.

----------
assignee: docs at python
components: Documentation
files: markgrandi_asyncio-eventloop.rst.patch
keywords: patch
messages: 230764
nosy: docs at python, markgrandi
priority: normal
severity: normal
status: open
title: Typo in asyncio-eventloop.rst, time() link is wrong
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37141/markgrandi_asyncio-eventloop.rst.patch

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

From report at bugs.python.org  Thu Nov  6 22:12:58 2014
From: report at bugs.python.org (Matt Frank)
Date: Thu, 06 Nov 2014 21:12:58 +0000
Subject: [issue22809] Include/graminit.h and Python/graminit.c always rebuilt
 (breaks cross builds)
Message-ID: <1415308378.14.0.442875510175.issue22809@psf.upfronthosting.co.za>


New submission from Matt Frank:

changeset 92496:c2a53aa27cad (issue22359) broke cross builds.  (Now "make touch; make" always tries to rebuild Include/graminit.h and Python/graminit.c by running "pgen".  But "pgen" is a host executable and won't run on the build machine during a cross-build.)

I think the problem is here, around Makefile.pre.in line 750.  The dependency was on PGENSRCS and is now on PGEN.  Will changing it back to PGENSRCS break something else?

@@ -745,15 +746,13 @@
 
 $(IO_OBJS): $(IO_H)
 
-$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGENSRCS)
+$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN)

----------
components: Build, Cross-Build
messages: 230765
nosy: WanderingLogic
priority: normal
severity: normal
status: open
title: Include/graminit.h and Python/graminit.c always rebuilt (breaks cross builds)
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov  6 22:13:42 2014
From: report at bugs.python.org (Matt Frank)
Date: Thu, 06 Nov 2014 21:13:42 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1415308422.91.0.948008994468.issue22359@psf.upfronthosting.co.za>


Matt Frank added the comment:

Sorry, I'm complaining.  Cross builds broke.  Please see issue22809.

----------
nosy: +WanderingLogic

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

From report at bugs.python.org  Thu Nov  6 22:26:16 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 06 Nov 2014 21:26:16 +0000
Subject: [issue22786] Message could not be delivered
In-Reply-To: <1415001683.94.0.832135728788.issueNone@psf.upfronthosting.co.za>
Message-ID: <1415309176.14.0.328867491192.issue22786@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Thu Nov  6 22:37:12 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 06 Nov 2014 21:37:12 +0000
Subject: [issue22809] Include/graminit.h and Python/graminit.c always rebuilt
 (breaks cross builds)
In-Reply-To: <1415308378.14.0.442875510175.issue22809@psf.upfronthosting.co.za>
Message-ID: <1415309832.71.0.987174017696.issue22809@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Duplicate of #22625.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> When cross-compiling, don?t try to execute binaries

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

From report at bugs.python.org  Thu Nov  6 23:49:12 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 06 Nov 2014 22:49:12 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1415314152.86.0.804478097427.issue22636@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/issue22636>
_______________________________________

From report at bugs.python.org  Fri Nov  7 00:24:06 2014
From: report at bugs.python.org (lccat)
Date: Thu, 06 Nov 2014 23:24:06 +0000
Subject: [issue22810] tkinter:  "alloc: invalid block:" after askopenfilename
Message-ID: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za>


New submission from lccat:

After running the Tkinter file dialog ( tkinter.filedialog.askopenfilename() ), and closing the tkinter window the following error message is displayed:
alloc: invalid block: 0xb035e0: b0 0
To reproduce see the attached python script "tktest". This does not stop the program as far as i can see.  Also happens for the directory selector.
Platform is linux.

----------
components: Tkinter
files: tktest.py
messages: 230768
nosy: lccat
priority: normal
severity: normal
status: open
title: tkinter:  "alloc: invalid block:" after askopenfilename
versions: Python 3.4
Added file: http://bugs.python.org/file37142/tktest.py

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

From report at bugs.python.org  Fri Nov  7 00:46:21 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 06 Nov 2014 23:46:21 +0000
Subject: [issue22808] Typo in asyncio-eventloop.rst, time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <1415317581.59.0.4423536426.issue22808@psf.upfronthosting.co.za>


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


----------
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov
stage:  -> patch review
versions: +Python 3.5

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

From report at bugs.python.org  Fri Nov  7 00:48:44 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Nov 2014 23:48:44 +0000
Subject: [issue22808] Typo in asyncio-eventloop.rst, time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <1415317724.34.0.232888074163.issue22808@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LG, can someone commit this? Should be backported to the 3.4 docs as well.

----------

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

From report at bugs.python.org  Fri Nov  7 01:23:12 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Nov 2014 00:23:12 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>
Message-ID: <1415319792.04.0.633473952401.issue22807@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Fri Nov  7 07:05:12 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 06:05:12 +0000
Subject: [issue22811] _top_level_dir state leaks on defaultTestLoader
Message-ID: <1415340312.36.0.0686984074156.issue22811@psf.upfronthosting.co.za>


New submission from Robert Collins:

TestProgram uses defaultTestLoader to load tests. Calling discover() on a TestLoader sets _top_level_dir. Calling discover with no top_level_dir implictly sets _top_level_dir but only the first time: the second time it is called with a different start_dir the prior one is used.

This leads to errors like:
======================================================================
ERROR: test_run_list_failed_import (testtools.tests.test_run.TestRun)
testtools.tests.test_run.TestRun.test_run_list_failed_import
----------------------------------------------------------------------
_StringException: Traceback (most recent call last):
  File "/home/robertc/personal/testtools/testtools/tests/test_run.py", line 175, in test_run_list_failed_import
    run.main, ['prog', 'discover', '-l', broken.package.base, '*.py'], out)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 420, in assertRaises
    self.assertThat(our_callable, matcher)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 431, in assertThat
    mismatch_error = self._matchHelper(matchee, matcher, message, verbose)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 481, in _matchHelper
    mismatch = matcher.match(matchee)
  File "/home/robertc/personal/testtools/testtools/matchers/_exception.py", line 108, in match
    mismatch = self.exception_matcher.match(exc_info)
  File "/home/robertc/personal/testtools/testtools/matchers/_higherorder.py", line 62, in match
    mismatch = matcher.match(matchee)
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 412, in match
    reraise(*matchee)
  File "/home/robertc/personal/testtools/testtools/matchers/_exception.py", line 101, in match
    result = matchee()
  File "/home/robertc/personal/testtools/testtools/testcase.py", line 965, in __call__
    return self._callable_object(*self._args, **self._kwargs)
  File "/home/robertc/personal/testtools/testtools/run.py", line 413, in main
    stdout=stdout)
  File "/home/robertc/personal/testtools/testtools/run.py", line 208, in __init__
    self.parseArgs(argv)
  File "/home/robertc/personal/testtools/testtools/run.py", line 252, in parseArgs
    self._do_discovery(argv[2:])
  File "/home/robertc/personal/testtools/testtools/run.py", line 368, in _do_discovery
    loaded = loader.discover(self.start, self.pattern, self.top)
  File "/home/robertc/.virtualenvs/testtools-2.7/local/lib/python2.7/site-packages/unittest2/loader.py", line 353, in discover
    raise ImportError('Start directory is not importable: %r' % start_dir)
ImportError: Start directory is not importable: '/tmp/tmpac4uwI'


When a test tries to test the behaviour of TestProgram (or a subclass thereof).

The fix is straight forward: at the end of discover restore the value of _top_level_dir that it had at entry.

----------
messages: 230770
nosy: rbcollins
priority: normal
severity: normal
status: open
title: _top_level_dir state leaks on defaultTestLoader

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

From report at bugs.python.org  Fri Nov  7 07:05:42 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 06:05:42 +0000
Subject: [issue22811] _top_level_dir state leaks on defaultTestLoader
In-Reply-To: <1415340312.36.0.0686984074156.issue22811@psf.upfronthosting.co.za>
Message-ID: <1415340342.48.0.0988537000558.issue22811@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
components: +Library (Lib)
versions: +Python 3.5

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

From report at bugs.python.org  Fri Nov  7 09:38:30 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 08:38:30 +0000
Subject: [issue22810] tkinter:  "alloc: invalid block:" after askopenfilename
In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za>
Message-ID: <1415349510.52.0.154428446331.issue22810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately I can't reproduce this bug (Python 3.4.0, Linux). When close the main window the output is:

Traceback (most recent call last):
  File "tktest.py", line 6, in <module>
    filename = tkinter.filedialog.askopenfilename()
  File "/usr/lib/python3.4/tkinter/filedialog.py", line 375, in askopenfilename
    return Open(**options).show()
  File "/usr/lib/python3.4/tkinter/commondialog.py", line 48, in show
    s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: can't invoke "grab" command: application has been destroyed

----------
nosy: +serhiy.storchaka
type:  -> behavior

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

From report at bugs.python.org  Fri Nov  7 10:17:29 2014
From: report at bugs.python.org (W. Trevor King)
Date: Fri, 07 Nov 2014 09:17:29 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1415351849.72.0.974335467454.issue22684@psf.upfronthosting.co.za>


W. Trevor King added the comment:

Here's an example from the notmuch list.  You can trigger the exception in Python 3.4 with:

  >>> import email.policy
  >>> import mailbox
  >>> mbox = mailbox.mbox('msg.mbox', factory=None, create=False)
  >>> message = mbox[0]
  >>> message.as_bytes(policy=email.policy.SMTP)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/home/wking/src/notmuch/ssoma_mda.py", line 319, in deliver
      message_bytes = message.as_bytes(policy=_email_policy.SMTP)
    File "/usr/lib64/python3.4/email/message.py", line 179, in as_bytes
      g.flatten(self, unixfrom=unixfrom)
    File "/usr/lib64/python3.4/email/generator.py", line 112, in flatten
      self._write(msg)
    File "/usr/lib64/python3.4/email/generator.py", line 192, in _write
      self._write_headers(msg)
    ?
    File "/usr/lib64/python3.4/email/_header_value_parser.py", line 195, in <genexpr>
      return ''.join(str(x) for x in self)
  RuntimeError: maximum recursion depth exceeded while getting the str of an object

Interestingly, it serializes fine using the default policy:

  >>> message.as_bytes()
  b'Return-Path: ?-----\n'

----------
nosy: +labrat
Added file: http://bugs.python.org/file37143/msg.mbox

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

From report at bugs.python.org  Fri Nov  7 10:30:57 2014
From: report at bugs.python.org (Denis Bilenko)
Date: Fri, 07 Nov 2014 09:30:57 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415352657.96.0.173505984903.issue22438@psf.upfronthosting.co.za>


Denis Bilenko added the comment:

gevent's ssl support is also broken by 2.7.9.

https://github.com/gevent/gevent/issues/477

IMO, it is totally unexpected to have some API (even though it's undocumented and internal) removed in non-major release.

Even though both gevent and eventlet can be fixed, there still be combinations of versions that break (python >= 2.7.9 & gevent <= 1.0.1)

Please put _ssl.sslwrap back. It would save a lot of people a lot of time. I don't mind fixing gevent not to use it, but there's nothing I can do about versions already released.

----------
nosy: +Denis.Bilenko

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

From report at bugs.python.org  Fri Nov  7 10:40:40 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 07 Nov 2014 09:40:40 +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: <1415353240.84.0.661351292952.issue22625@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Fri Nov  7 10:45:22 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 07 Nov 2014 09:45:22 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415353522.79.0.476016137678.issue22438@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Private API is expected to be allowed to be deleted or incompatibly changed in any micro release.

----------

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

From report at bugs.python.org  Fri Nov  7 10:53:47 2014
From: report at bugs.python.org (vila)
Date: Fri, 07 Nov 2014 09:53:47 +0000
Subject: [issue22807] uuid.uuid1() should use uuid_generate_time_safe() if
 available
In-Reply-To: <1415304446.34.0.331764401827.issue22807@psf.upfronthosting.co.za>
Message-ID: <1415354027.42.0.366924360255.issue22807@psf.upfronthosting.co.za>


Changes by vila <v.ladeuil+bugs-python at free.fr>:


----------
nosy: +vila

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

From report at bugs.python.org  Fri Nov  7 10:57:36 2014
From: report at bugs.python.org (W. Trevor King)
Date: Fri, 07 Nov 2014 09:57:36 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1415354256.07.0.964612400284.issue22684@psf.upfronthosting.co.za>


W. Trevor King added the comment:

The troublesome header formatting is:

  >>> import email.policy
  >>> email.policy.SMTP.fold_binary('Cc', 'notmuch\n\t<public-public-notmuch-gxuj+Tv9EO5zyzON3hdc1g-wOFGN7rlS/M9smdsby/KFg at plane.gmane.org>,\n\tpublic-notmuch-gxuj+Tv9EO5zyzON3hdc1g at plane.gmane.org,\n\tRainer M Krug <public-R.M.Krug-Re5JQEeQqe8AvxtiuMwx3w at plane.gmane.org>,\n\tJeremy Nickurak\n\t<public-public-not-much-kexSNQTsIoD754YsiR0rpA-wOFGN7rlS/M9smdsby/KFg at plane.gmane.org>')
  Traceback (most recent call last):
    ?
  RuntimeError: maximum recursion depth exceeded while getting the str of an object

Trimming that down a bit, a minimal trigger seems to be:

  >>> email.policy.SMTP.fold_binary('Cc', 'a\n\taaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,\n\ta')
  Traceback?

Where removing much of anything gives a working fold.

----------

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

From report at bugs.python.org  Fri Nov  7 10:58:16 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 09:58:16 +0000
Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual
In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za>
Message-ID: <1415354296.06.0.451323048924.issue22452@psf.upfronthosting.co.za>


Robert Collins added the comment:

https://code.google.com/p/unittest-ext/issues/detail?id=11

I think that the hamcrest inspired matchers stuff may help make this a reality too. OTOH if we had a clean patch now for the existing asserts that would be fine too.

----------

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

From report at bugs.python.org  Fri Nov  7 11:00:09 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:00:09 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
Message-ID: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://code.google.com/p/unittest-ext/issues/detail?id=13

The following is incorrect on Windows:

    python -m unittest discover -p '*.py'

It should be without the single quotes around the .py:

    python -m unittest discover -p *.py

This needs to be documented.

----------
assignee: docs at python
components: Documentation
messages: 230777
nosy: docs at python, rbcollins
priority: normal
severity: normal
status: open
title: Documentation of unittest -p usage wrong on windows.
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:05:59 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:05:59 +0000
Subject: [issue22813] No facility for test randomisation
Message-ID: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>


New submission from Robert Collins:

Unittest doesn't support a test randomisation feature.

Such a feature should support:
 - passing in a seed (to allow reproducing the order for debugging)
 - preserving the suite hierarchy, to preserve class and module setUp performance optimisations
 - and randomising globally with cloned suite hierarchies, for more comprehensive randomisation
 - allowing some scopes to opt out of randomisation (where tests really have dependencies on execution order and thats what the test author wants)

>From https://code.google.com/p/unittest-ext/issues/detail?id=6

----------
components: Library (Lib)
messages: 230778
nosy: rbcollins
priority: normal
severity: normal
status: open
title: No facility for test randomisation
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:08:03 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 10:08:03 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415354883.12.0.083099172568.issue22438@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Even though it may have been considered a private API (*), users certainly won't understand that their application just broke because of a Python patch level release upgrade, so if possible, I think the API should be added back and flagged as "private, but used by at least eventlet and gevent".

Alternatively: Why not add it back and make it an officially documented API ?

(*) The API is missing the leading underscore, so it's not really private by our usual conventions, it's just undocumented.

----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Nov  7 11:11:59 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 07 Nov 2014 10:11:59 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415355119.94.0.74501965021.issue22438@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

_ssl has leading underscore.
Privateness is "inherited", so both A._B.C and A._B._D are private.

----------

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

From report at bugs.python.org  Fri Nov  7 11:12:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 10:12:44 +0000
Subject: [issue22769] Tttk tag_has() throws TypeError when called without item
In-Reply-To: <1414709925.15.0.196086635074.issue22769@psf.upfronthosting.co.za>
Message-ID: <20141107101237.108367.1546@psf.io>


Roundup Robot added the comment:

New changeset b3a5b53173c0 by Serhiy Storchaka in branch '2.7':
Issue #22769: Fixed ttk.Treeview.tag_has() when called without arguments.
https://hg.python.org/cpython/rev/b3a5b53173c0

New changeset cd17aa63492e by Serhiy Storchaka in branch '3.4':
Issue #22769: Fixed ttk.Treeview.tag_has() when called without arguments.
https://hg.python.org/cpython/rev/cd17aa63492e

New changeset 0b56adcb737d by Serhiy Storchaka in branch 'default':
Issue #22769: Fixed ttk.Treeview.tag_has() when called without arguments.
https://hg.python.org/cpython/rev/0b56adcb737d

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

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

From report at bugs.python.org  Fri Nov  7 11:17:40 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:17:40 +0000
Subject: [issue22814] TestProgram loading fails when a script is used
Message-ID: <1415355460.06.0.807926995385.issue22814@psf.upfronthosting.co.za>


New submission from Robert Collins:

If someone has a TestProgram script - e.g. the unit2 script in unittest2, loading a module in cwd will fail, because the PYTHONPATH doesn't include '.'. We might want to consider adding cwd to the PYTHONPATH in TestProgram.

>From https://code.google.com/p/unittest-ext/issues/detail?id=18

----------
components: Library (Lib)
messages: 230782
nosy: rbcollins
priority: normal
severity: normal
status: open
title: TestProgram loading fails when a script is used
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:21:48 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:21:48 +0000
Subject: [issue22815] unexpected successes are not output
Message-ID: <1415355708.14.0.235525212407.issue22815@psf.upfronthosting.co.za>


New submission from Robert Collins:

Unexpected successes cause failures, but we don't output details about them at the end of the run.

>From https://code.google.com/p/unittest-ext/issues/detail?id=22

A complicating factor is that we don't have a backtrace to show - but we may have captured stdout/stderr or in future various test attachments to show.

----------
components: Library (Lib)
messages: 230783
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unexpected successes are not output
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 11:27:23 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 10:27:23 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <20141107102720.113470.18761@psf.io>


Roundup Robot added the comment:

New changeset e80cb046e764 by Serhiy Storchaka in branch '2.7':
Issue #17293: uuid.getnode() now determines MAC address on AIX using netstat.
https://hg.python.org/cpython/rev/e80cb046e764

New changeset ba4b31ed2952 by Serhiy Storchaka in branch '3.4':
Issue #17293: uuid.getnode() now determines MAC address on AIX using netstat.
https://hg.python.org/cpython/rev/ba4b31ed2952

New changeset 3e4f3cc4f1f9 by Serhiy Storchaka in branch 'default':
Issue #17293: uuid.getnode() now determines MAC address on AIX using netstat.
https://hg.python.org/cpython/rev/3e4f3cc4f1f9

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

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

From report at bugs.python.org  Fri Nov  7 11:30:35 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:30:35 +0000
Subject: [issue22452] addTypeEqualityFunc is not used in assertListEqual
In-Reply-To: <1411297928.75.0.716793613355.issue22452@psf.upfronthosting.co.za>
Message-ID: <1415356235.17.0.291077405083.issue22452@psf.upfronthosting.co.za>


Robert Collins added the comment:

See also https://code.google.com/p/unittest-ext/issues/detail?id=27

"Sorry, wrong wording of the bug.

I tested this on IronPython 2.6.1 and 2.7.b1. I see the same result as you and I consider the following wrong or at least misleading:

- [1, Decimal("1"), Decimal("2.00")]
?  ^                          ---

+ [2, Decimal("1.00"), Decimal("2")]
?  ^            +++

I mean the +++ and --- under Decimal numbers.

On the other hand I understand that these are differences in string representation of those lists..."

----------

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

From report at bugs.python.org  Fri Nov  7 11:30:51 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 10:30:51 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1415355119.94.0.74501965021.issue22438@psf.upfronthosting.co.za>
Message-ID: <545C9F52.50909@egenix.com>


Marc-Andre Lemburg added the comment:

On 07.11.2014 11:12, Arfrever Frehtes Taifersar Arahesis wrote:
> 
> Arfrever Frehtes Taifersar Arahesis added the comment:
> 
> _ssl has leading underscore.
> Privateness is "inherited", so both A._B.C and A._B._D are private.

No, the use of the underscore in _ssl is per convention that C
implementation part of stdlib modules are moved into modules that
start with an underscore. This doesn't mean that the APIs in
those modules are private, otherwise many C implementations we have
in the stdlib would be private :-)

Also note that _ssl.sslwrap is special in that it's the main
interface between _ssl and ssl.

BTW: The sslwrap_simple() API was also removed in 2.7.9.

Note: Any libraries that need to monkey patch the Python
network stdlib will need access to these APIs. Given that the
ssl implementation changed a lot in 2.7.9, I think special care
has to be taken not to break too many of these. Using gevent
and eventlet as test cases for whether backwards compatibility
is good enough sounds like a workable approach, IMO.

----------

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

From report at bugs.python.org  Fri Nov  7 11:31:12 2014
From: report at bugs.python.org (W. Trevor King)
Date: Fri, 07 Nov 2014 10:31:12 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1415356272.29.0.313184863412.issue22684@psf.upfronthosting.co.za>


W. Trevor King added the comment:

In email._header_value_parser._Folded.append_if_fits, if I shift:

            if token.has_fws:
                ws = token.pop_leading_fws()
                if ws is not None:
                    self.stickyspace += str(ws)
                    stickyspace_len += len(ws)
                token._fold(self)
                return True

to:

            if token.has_fws:
                ws = token.pop_leading_fws()
                if ws is not None:
                    self.stickyspace += str(ws)
                    stickyspace_len += len(ws)
                    token._fold(self)
                    return True

I can avoid the recursion.

The problem seems to be that the "a aaaa?aaa" token/part contains folding white space, but doesn't *start* with folding whitespace.  Maybe the folding should try to split on existing FWS, instead of just trying to pop leading FWS?

----------

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

From report at bugs.python.org  Fri Nov  7 11:36:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 10:36:21 +0000
Subject: [issue22769] Tttk tag_has() throws TypeError when called without item
In-Reply-To: <1414709925.15.0.196086635074.issue22769@psf.upfronthosting.co.za>
Message-ID: <1415356581.95.0.160385826887.issue22769@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/issue22769>
_______________________________________

From report at bugs.python.org  Fri Nov  7 11:37:20 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:37:20 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1415356640.63.0.854696875512.issue10611@psf.upfronthosting.co.za>


Robert Collins added the comment:

Hmm, so testtools went in a different direction here - the same unification stuff, but see https://github.com/testing-cabal/testtools/commit/18bc5741cf277f7a0d601568be6dccacc7b0783c

tl;dr - I think unittest should not prevent this causing the process to exit (but it should still fail the test and fail the test run as a whole), analgous to how KeyboardInterrupt is handled.

----------
nosy: +rbcollins

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

From report at bugs.python.org  Fri Nov  7 11:44:15 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:44:15 +0000
Subject: [issue10548] document (lack of) interaction between
 @expectedException on a test_method and setUp
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1415357055.01.0.934036413598.issue10548@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
title: Error in setUp not reported as expectedFailure (unittest) -> document (lack of) interaction between @expectedException on a test_method and setUp

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

From report at bugs.python.org  Fri Nov  7 11:52:29 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 07 Nov 2014 10:52:29 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415357549.56.0.574675000878.issue22438@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> No, the use of the underscore in _ssl is per convention that C
> implementation part of stdlib modules are moved into modules that
> start with an underscore. This doesn't mean that the APIs in
> those modules are private, otherwise many C implementations we have
> in the stdlib would be private :-)

The non-private C-implemented modules are these:

$ cd /usr/lib64/python2.7/lib-dynload ; echo [^_]*.so
array.so audioop.so binascii.so bz2.so cmath.so cPickle.so crypt.so cStringIO.so datetime.so dbm.so fcntl.so future_builtins.so gdbm.so grp.so itertools.so linuxaudiodev.so math.so mmap.so nis.so operator.so ossaudiodev.so parser.so pyexpat.so readline.so resource.so select.so spwd.so strop.so syslog.so termios.so time.so unicodedata.so zlib.so

_[^_]-prefixed, undocumented modules (amongst whom are both _[^_].py and _[^_].so) should be treated as private modules for usage only by public modules in standard library.

(_winreg is the only _[^_]-prefixed, documented module in CPython 2.7.)

----------

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

From report at bugs.python.org  Fri Nov  7 12:15:15 2014
From: report at bugs.python.org (Michael Foord)
Date: Fri, 07 Nov 2014 11:15:15 +0000
Subject: [issue10611] sys.exit() in a test causes a test run to die
In-Reply-To: <1291339519.59.0.737922107849.issue10611@psf.upfronthosting.co.za>
Message-ID: <1415358915.23.0.792839773399.issue10611@psf.upfronthosting.co.za>


Michael Foord added the comment:

Allowing sys.exit() to end the test run was particularly a problem for testing command line tools, where improper patching / unexpected code paths would trigger a sys.exit.

If a test framework author wants a way to end the test run I'm happy to provide that (a custom exception to raise or a flag to turn off sys.exit handling), but I don't think having sys.exit kill test runs is best for test authors.

----------

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

From report at bugs.python.org  Fri Nov  7 12:20:58 2014
From: report at bugs.python.org (lccat)
Date: Fri, 07 Nov 2014 11:20:58 +0000
Subject: [issue22810] tkinter:  "alloc: invalid block:" after askopenfilename
In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za>
Message-ID: <1415359258.01.0.0973168355919.issue22810@psf.upfronthosting.co.za>


lccat added the comment:

Your output is different because you did not close the file dialog by selecting something and the pressing OK, or pressing cancel before destroying the main window. This is also the case here:
Traceback (most recent call last):
  File "tktest.py", line 6, in <module>
    filename = tkinter.filedialog.askopenfilename()
  File "/usr/lib/python3.4/tkinter/filedialog.py", line 375, in askopenfilename
    return Open(**options).show()
  File "/usr/lib/python3.4/tkinter/commondialog.py", line 48, in show
    s = w.tk.call(self.command, *w._options(self.options))
_tkinter.TclError: can't invoke "grab" command: application has been destroyed
alloc: invalid block: 0x1d2cda0: a0 1
zsh: abort      python tktest.py

However, only the last two lines are relevant here, which you could not reproduce.

----------

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

From report at bugs.python.org  Fri Nov  7 12:26:49 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 11:26:49 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1415357549.56.0.574675000878.issue22438@psf.upfronthosting.co.za>
Message-ID: <545CAC71.4050700@egenix.com>


Marc-Andre Lemburg added the comment:

On 07.11.2014 11:52, Arfrever Frehtes Taifersar Arahesis wrote:
> 
> Arfrever Frehtes Taifersar Arahesis added the comment:
> 
>> No, the use of the underscore in _ssl is per convention that C
>> implementation part of stdlib modules are moved into modules that
>> start with an underscore. This doesn't mean that the APIs in
>> those modules are private, otherwise many C implementations we have
>> in the stdlib would be private :-)
> 
> The non-private C-implemented modules are these:
> 
> $ cd /usr/lib64/python2.7/lib-dynload ; echo [^_]*.so
> array.so audioop.so binascii.so bz2.so cmath.so cPickle.so crypt.so cStringIO.so datetime.so dbm.so fcntl.so future_builtins.so gdbm.so grp.so itertools.so linuxaudiodev.so math.so mmap.so nis.so operator.so ossaudiodev.so parser.so pyexpat.so readline.so resource.so select.so spwd.so strop.so syslog.so termios.so time.so unicodedata.so zlib.so
> 
> _[^_]-prefixed, undocumented modules (amongst whom are both _[^_].py and _[^_].so) should be treated as private modules for usage only by public modules in standard library.
> 
> (_winreg is the only _[^_]-prefixed, documented module in CPython 2.7.)

I think you're misunderstanding: just because an API is implemented
in one of the _module.c modules, doesn't imply that those APIs are
private. We have for a long time now used the approach to have a Python
module as main entry point and the _module.c modules providing the
C level bits needed by the Python module.

Regardless of whether the API can be considered private or not, packages
which have to monkey patch the low-level APIs in the network modules
will need access to those APIs in order to tap into the layers and
the sslwrap() function was/is such a low level API.

Also note that due to the major implementation changes in the ssl
module for 2.7.9 such quirks are actually expected and so it's good
that we are getting reports from eventlet and gevent on these
issues. After all, what use is a safer ssl module if your application
doesn't work anymore ;-)

----------

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

From report at bugs.python.org  Fri Nov  7 12:37:26 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 07 Nov 2014 11:37:26 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415360246.71.0.749087001542.issue22438@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Monkey-patching is as supported as using private API.
Maintainers of third-party projects monkey-patching something or using private API should expect to sporadically have to adjust their projects to new Python versions.

----------

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

From report at bugs.python.org  Fri Nov  7 12:49:48 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 11:49:48 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <545C9F52.50909@egenix.com>
Message-ID: <545CB1D4.5020806@egenix.com>


Marc-Andre Lemburg added the comment:

On 07.11.2014 11:30, Marc-Andre Lemburg wrote:
> BTW: The sslwrap_simple() API was also removed in 2.7.9.

Scratch that. I was in the wrong work dir :-)

----------

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

From report at bugs.python.org  Fri Nov  7 12:49:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 11:49:57 +0000
Subject: [issue22810] tkinter:  "alloc: invalid block:" after askopenfilename
In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za>
Message-ID: <1415360997.66.0.252062872728.issue22810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

When first close the file dialog (by pressing either Open, or Cancel, or close window button, or Alt-F4 keystroke), I don't see any output at all.

What Tk version (tkinter.TkVersion) is used? What Linux distribution name and version are?

----------

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

From report at bugs.python.org  Fri Nov  7 12:51:53 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 11:51:53 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <545CB1D4.5020806@egenix.com>
Message-ID: <545CB251.1090103@egenix.com>


Marc-Andre Lemburg added the comment:

On 07.11.2014 12:49, Marc-Andre Lemburg wrote:
>> BTW: The sslwrap_simple() API was also removed in 2.7.9.
> 
> Scratch that. I was in the wrong work dir :-)

Hmm, even though the API is still there, it uses _ssl.sslwrap() as
well, so it won't work anymore either.

----------

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

From report at bugs.python.org  Fri Nov  7 12:54:31 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 07 Nov 2014 11:54:31 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415361271.66.0.406515333005.issue22438@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> Hmm, even though the API is still there, it uses _ssl.sslwrap() as
> well, so it won't work anymore either.

It was fixed in bug #22523.

----------

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

From report at bugs.python.org  Fri Nov  7 13:03:08 2014
From: report at bugs.python.org (lccat)
Date: Fri, 07 Nov 2014 12:03:08 +0000
Subject: [issue22810] tkinter:  "alloc: invalid block:" after askopenfilename
In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za>
Message-ID: <1415361788.87.0.994053993018.issue22810@psf.upfronthosting.co.za>


lccat added the comment:

>>print(TkVersion)
8.6
Tk version in package manager:
python-pmw 2.0.0-2
Distribution:
arch linux, kernel 3.17.2-1-ARCH

----------

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

From report at bugs.python.org  Fri Nov  7 13:12:18 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Nov 2014 12:12:18 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415362338.62.0.267410333193.issue22438@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It's not a mere matter of putting back the code... The 3.x ssl implementation which was backported uses a slightly different approach from the 2.x implementation, so it's not obvious we can recreate an entirely compatible implementation of_ssl.sslwrap().

As a matter of fact, gevent's fix uses some frame locals hackery to lookup the caller's "self" variable, which means it probably won't work in the general case:
https://github.com/Eugeny/ajenti/commit/54442ccb2b9ee24af15500557e7dd7b2f58acb97

----------

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

From report at bugs.python.org  Fri Nov  7 13:12:54 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 12:12:54 +0000
Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code
In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za>
Message-ID: <20141107121243.108091.60114@psf.io>


Roundup Robot added the comment:

New changeset ad89a652b4ed by Serhiy Storchaka in branch '3.4':
Issue #22406: Fixed the uu_codec codec incorrectly ported to 3.x.
https://hg.python.org/cpython/rev/ad89a652b4ed

New changeset b18ef4a3e7c1 by Serhiy Storchaka in branch 'default':
Issue #22406: Fixed the uu_codec codec incorrectly ported to 3.x.
https://hg.python.org/cpython/rev/b18ef4a3e7c1

New changeset 7b82b58b8329 by Serhiy Storchaka in branch '2.7':
Backported tests for issue #22406.
https://hg.python.org/cpython/rev/7b82b58b8329

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

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

From report at bugs.python.org  Fri Nov  7 13:34:34 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 12:34:34 +0000
Subject: [issue22431] Change format of test runner output
In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za>
Message-ID: <1415363674.56.0.520955270048.issue22431@psf.upfronthosting.co.za>


Robert Collins added the comment:

I don't consider the console output of unittest to be a stable interface. Michael - do you?

Things that want to process unittest should be using the API.

----------
nosy: +rbcollins

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

From report at bugs.python.org  Fri Nov  7 13:39:33 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 07 Nov 2014 12:39:33 +0000
Subject: [issue22431] Change format of test runner output
In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za>
Message-ID: <1415363973.44.0.231535472428.issue22431@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I agree with Robert. However, since software authors' wishes can clearly be diverse here, perhaps there should be a simple way for them to customize the output?

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Nov  7 13:56:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 12:56:21 +0000
Subject: [issue22406] uu-codec trailing garbage workaround is Python 2 code
In-Reply-To: <1410702414.35.0.316849103636.issue22406@psf.upfronthosting.co.za>
Message-ID: <1415364981.76.0.649387736975.issue22406@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it is safer now just fix existing code than replace it with totally different code with the risk of incompatibility. In any case uu_codec needs rewriting because currently it doesn't support incremental encoding and decoding.

Thank you for your contribution Martin. And if you are going to do further contribution, please submit a contributor form (https://www.python.org/psf/contrib/).

Few notes. It is more handy to provide all changes as one patch. And your patches contain trailing spaces in blank lines.

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

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

From report at bugs.python.org  Fri Nov  7 13:56:49 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 12:56:49 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1415362338.62.0.267410333193.issue22438@psf.upfronthosting.co.za>
Message-ID: <545CC189.4070004@egenix.com>


Marc-Andre Lemburg added the comment:

On 07.11.2014 13:12, Antoine Pitrou wrote:
> 
> It's not a mere matter of putting back the code... The 3.x ssl implementation which was backported uses a slightly different approach from the 2.x implementation, so it's not obvious we can recreate an entirely compatible implementation of_ssl.sslwrap().
> 
> As a matter of fact, gevent's fix uses some frame locals hackery to lookup the caller's "self" variable, which means it probably won't work in the general case:
> https://github.com/Eugeny/ajenti/commit/54442ccb2b9ee24af15500557e7dd7b2f58acb97

Yes, that hack will probably only work for gevent.

Is there a reason why caller_self needs to be passed to
context._wrap_socket() ?

I can't even find the ssl_sock kw args used in the hack in the current
2.7.9 code. The method only has a server_name argument.

----------

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

From report at bugs.python.org  Fri Nov  7 13:59:22 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 07 Nov 2014 12:59:22 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <545CC189.4070004@egenix.com>
Message-ID: <545CC222.7070501@egenix.com>


Marc-Andre Lemburg added the comment:

Looking at recent comments on the gevent ticket, the 2.7.9
changes are already causing problems for people since apparently
the changes were backported to 2.7.8 by some vendors.

https://github.com/gevent/gevent/issues/477

----------

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

From report at bugs.python.org  Fri Nov  7 13:59:28 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 07 Nov 2014 12:59:28 +0000
Subject: [issue22438] eventlet broke by python 2.7.x
In-Reply-To: <1411075272.39.0.133162978572.issue22438@psf.upfronthosting.co.za>
Message-ID: <1415365168.14.0.195186093606.issue22438@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

FWIW, that code is all significantly simplified by the patch in http://bugs.python.org/issue22559

----------

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

From report at bugs.python.org  Fri Nov  7 15:34:32 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 07 Nov 2014 14:34:32 +0000
Subject: [issue22766] collections.Counter's in-place operators should return
 NotImplemented for unsupported types
In-Reply-To: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>
Message-ID: <1415370872.05.0.336764420253.issue22766@psf.upfronthosting.co.za>


Ethan Furman added the comment:

No real-world use-cases have surfaced.  Many thanks to everyone's explanations and examples.

----------

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

From report at bugs.python.org  Fri Nov  7 15:54:51 2014
From: report at bugs.python.org (Ferdinand)
Date: Fri, 07 Nov 2014 14:54:51 +0000
Subject: [issue22750] xmlapp.py display bug when validate XML by DTD
In-Reply-To: <1414490220.27.0.963002484178.issue22750@psf.upfronthosting.co.za>
Message-ID: <1415372091.68.0.8571628889.issue22750@psf.upfronthosting.co.za>


Ferdinand added the comment:

I found a solution :

from xml.sax import make_parser
from xml.sax.handler import feature_namespaces, feature_validation
from xml.sax.handler import ContentHandler, ErrorHandler, DTDHandler

With the library above, they is no display bug !

----------

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

From report at bugs.python.org  Fri Nov  7 15:57:09 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 07 Nov 2014 14:57:09 +0000
Subject: [issue22805] Having pythontest.net index.html link to hg repo
In-Reply-To: <1415285315.17.0.355776153146.issue22805@psf.upfronthosting.co.za>
Message-ID: <1415372229.67.0.0083131894884.issue22805@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Changeset b51c46800184 in the pythontestdotnet repo.

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

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

From report at bugs.python.org  Fri Nov  7 16:09:16 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Nov 2014 15:09:16 +0000
Subject: [issue22684] message.as_bytes() produces recursion depth exceeded
In-Reply-To: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>
Message-ID: <1415372956.15.0.313760264339.issue22684@psf.upfronthosting.co.za>


R. David Murray added the comment:

Something like that.  That folding algorithm is a bit...bizantine.  I need to sit down and completely rewrite it, I think.  But maybe I can fix this problem in the meantime, until I have time to do that.

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

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

From report at bugs.python.org  Fri Nov  7 16:16:27 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Nov 2014 15:16:27 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1415373387.76.0.823036220206.issue22812@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why doesn't it work with the quotes?  Wouldn't it be better to make it work?  Or is it as simple as changing the example to use double quotes?

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

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

From report at bugs.python.org  Fri Nov  7 16:22:44 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 15:22:44 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1415373764.75.0.201133413002.issue22812@psf.upfronthosting.co.za>


Robert Collins added the comment:

I agree. IIRC the windows shell passes the argument as "'*.py'" rather than as "*.py", so when we glob it we get no files, as no python files end with an apostrophe.

----------

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

From report at bugs.python.org  Fri Nov  7 16:27:53 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 15:27:53 +0000
Subject: [issue19645] decouple unittest assertions from the TestCase class
In-Reply-To: <1384785494.56.0.149196031493.issue19645@psf.upfronthosting.co.za>
Message-ID: <1415374073.28.0.387714920193.issue19645@psf.upfronthosting.co.za>


Robert Collins added the comment:

Hi, I'm glad you're interested in this. I very much want to see a matcher/hamcrest approach rather than a library of assertions per se - because match-or-except makes layering things harder.

----------

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

From report at bugs.python.org  Fri Nov  7 16:31:02 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 15:31:02 +0000
Subject: [issue11664] Add patch method to unittest.TestCase
In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za>
Message-ID: <1415374262.1.0.676364253642.issue11664@psf.upfronthosting.co.za>


Robert Collins added the comment:

+1 on a plain function or context manager.

w.r.t. addCleanUp taking a context manager, that could be interesting - perhaps we'd want a thing where you pass it the context manager, it __enter__'s the manager and then calls addCleanUp for you.

----------

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

From report at bugs.python.org  Fri Nov  7 16:37:18 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 07 Nov 2014 15:37:18 +0000
Subject: [issue9951] introduce bytes.hex method (also for bytearray and
 memoryview)
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1415374638.57.0.808940369568.issue9951@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/issue9951>
_______________________________________

From report at bugs.python.org  Fri Nov  7 17:29:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 16:29:46 +0000
Subject: [issue22242] Doc fix in the Import section in language reference.
In-Reply-To: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>
Message-ID: <20141107162942.85196.28486@psf.io>


Roundup Robot added the comment:

New changeset f473063318c3 by Brett Cannon in branch 'default':
Issue #22242: Try to make some import-related loader details clearer.
https://hg.python.org/cpython/rev/f473063318c3

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

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

From report at bugs.python.org  Fri Nov  7 17:31:41 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 07 Nov 2014 16:31:41 +0000
Subject: [issue22242] Doc fix in the Import section in language reference.
In-Reply-To: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>
Message-ID: <1415377901.07.0.727644278115.issue22242@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So the second point isn't contradictory, just more thorough (and had a mad mix of singular/plural wording). Loaders could add more than one module if they chose to. The key point is that when a load fails, only the modules that failed and that the loader itself was directly involved with loading should be removed from sys.modules.

I tried to fix the plurality of the words in the second part to help clear things up.

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

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

From report at bugs.python.org  Fri Nov  7 17:58:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 16:58:38 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1415379518.06.0.681214772514.issue17293@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as this hasn't broke buildbots.

Thank you Aivars for your patch. Thank you Natali and Victor for your suggestions and reviews.

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

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

From report at bugs.python.org  Fri Nov  7 18:17:33 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 07 Nov 2014 17:17:33 +0000
Subject: [issue17900] Recursive OrderedDict pickling
In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>
Message-ID: <1415380653.18.0.954897312115.issue17900@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/issue17900>
_______________________________________

From report at bugs.python.org  Fri Nov  7 18:20:27 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 07 Nov 2014 17:20:27 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1415380827.53.0.0795911765828.issue22806@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/issue22806>
_______________________________________

From report at bugs.python.org  Fri Nov  7 18:25:57 2014
From: report at bugs.python.org (Kieran Colford)
Date: Fri, 07 Nov 2014 17:25:57 +0000
Subject: [issue22816] repor
Message-ID: <545d00a2.0b6d8c0a.5ab0.ffffa52a@mx.google.com>


New submission from Kieran Colford:

[Click here if you cant view this message](http://186.148.231.148/?giwi=1&ji=1.6.3839&cnb=ce46347d8c015bd611c9870cd25e35b4&yzy=633678&azui=pzIjo3W0DTW1M3ZhpUy0nT9hYz9lMj%3D%3D)

----------
messages: 230818
nosy: Kieran.Colford
priority: normal
severity: normal
status: open
title: repor

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

From report at bugs.python.org  Fri Nov  7 18:29:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 17:29:55 +0000
Subject: [issue22816] repor
In-Reply-To: <545d00a2.0b6d8c0a.5ab0.ffffa52a@mx.google.com>
Message-ID: <1415381395.12.0.0443012187764.issue22816@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  7 18:35:14 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 07 Nov 2014 17:35:14 +0000
Subject: [issue22816] repor
Message-ID: <1415381714.3.0.879189574471.issue22816@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  7 18:44:20 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 07 Nov 2014 17:44:20 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <1415382260.91.0.87151781712.issue20152@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a new patch for fcntl. I would like a review since I had to get a bit tricky to handle the polymorphic arguments for fcntl and ioctl and I don't think the test suite is that thorough for this module.

----------
Added file: http://bugs.python.org/file37144/fcntl_derby.diff

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

From report at bugs.python.org  Fri Nov  7 18:51:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 17:51:44 +0000
Subject: [issue22808] Typo in asyncio-eventloop.rst, time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <20141107175130.108387.30076@psf.io>


Roundup Robot added the comment:

New changeset 8b1d8fcb494b by Berker Peksag in branch '3.4':
Issue #22808: Link to the correct time method in BaseEventLoop.call_at().
https://hg.python.org/cpython/rev/8b1d8fcb494b

New changeset 98f4bc1332c9 by Berker Peksag in branch 'default':
Issue #22808: Link to the correct time method in BaseEventLoop.call_at().
https://hg.python.org/cpython/rev/98f4bc1332c9

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

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

From report at bugs.python.org  Fri Nov  7 18:52:32 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 07 Nov 2014 17:52:32 +0000
Subject: [issue22808] Typo in asyncio-eventloop.rst, time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <1415382752.57.0.826451177619.issue22808@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Committed. Thanks for the patch, Mark.

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

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

From report at bugs.python.org  Fri Nov  7 19:00:00 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Nov 2014 18:00:00 +0000
Subject: [issue22816] spam
Message-ID: <1415383200.57.0.288129110731.issue22816@psf.upfronthosting.co.za>


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


----------
title: repor -> spam

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

From report at bugs.python.org  Fri Nov  7 20:32:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 19:32:50 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <1415388770.88.0.403758123969.issue20152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I found bugs or doubtful code in the fcntl module. They should be fixed before converting to Argument Clinic.

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

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

From report at bugs.python.org  Fri Nov  7 20:35:07 2014
From: report at bugs.python.org (Eldar Abusalimov)
Date: Fri, 07 Nov 2014 19:35:07 +0000
Subject: [issue22735] Fix various crashes exposed through mro() customization
In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za>
Message-ID: <1415388907.11.0.79892033589.issue22735@psf.upfronthosting.co.za>


Eldar Abusalimov added the comment:

Thank you for your replies.

I don't think forbidding reentrancy is a good idea, and I'm against it for the following reasons.

First of all, naive prohibition of type_set_bases within mro() on a class doesn't save from mro() reentrancy:

    def mro(cls):
        # cls is B,
        # B extends A

        A.__bases__ = ...  # What to do?

Changing bases of a class provokes MRO of all its subclasses to be updated as well. Therefore, one would also need to forbid changing __bases__ of any direct or indirect base of the class up to the 'object', and this doesn't feel natural at all. Why should mro() of some specialized class B prevent changing bases of its general parent class A?

Otherwise, there must be a check in mro_subclasses (mro_hierarchy in the patch), which will not recurse into a class flagged as being inside mro(). But in this case a running mro(B) will be unable to notice a change of MRO of the parent class A, in case if mro() involves some non-trivial logic, and A.__bases__ assignment occurs somewhere deep in the call stack and is done by a code from some unknown black-box module. Deferring mro() recalculation upon exiting from the outermost mro() in such case doesn't seem to be a good solution either, especially concerning its (most likely) tricky implementation.

    def mro(cls):
        # some complicated calculation based of MROs of bases:
        parent_mros = [base.__mro__ for base in cls.__bases__]

        # The line below does this:
        #   parent.__bases__ = ...
        # (deep-deep-deep in the call stack)
        third_party.do_mro(cls)

        # Either the line above raises an error,
        # or parent_mros becomes invalid.


Another example. Setting __bases__ from inside mro() may be useful for changing class behavior on the fly using a proxy base class (e.g. for debugging, logging, testing frameworks). The only place to do this except mro() is __new__, but in that case it is only possible to fix up bases at the moment of class creation. That is, a tricky class that change its __bases__ would break such framework by overriding a proxy base, which is necessary for this framework to function properly.

    def mro(cls):
        if cls or one of cls.__bases__ is not a proxy class:
            class Proxy(*cls.__bases__):
                ...
            cls.__bases__ = (Proxy,)  # reenter

        return type.mro(cls)

In other words, there should be a loophole to alter __bases__ upon assignment, and I suppose mro() is a good option.

Also, __bases__ assignment is known as the only reliable way to invoke MRO recalculation (http://stackoverflow.com/a/20832588/545027). Forbidding it from the inside mro() makes it not so obvious and reliable.

Actually, I encountered one of these bugs while working on a real metaclass providing an auto-inheriting attributes feature needed for a custom DSL built on top of Python. In a nutshell, if B extends A, then make B.V extend A.V automatically (https://github.com/abusalimov/mybuild/blob/6c7c89521b856c798b46732501adb5e06dec7e03/util/inherit.py, still work in progress).

I know, some of these use cases may sound a bit unreal (or even crazy), but neither me nor you can imagine all scenarios, that Python programmers could ever invent. Actually, there could already exist some: it is possible to workaround most of reentrancy issues through holding a reference to old_mro from inside a Python code. That is, backward compatibility comes into play too.

Finally, why do forbid something that was not prohibited before? I think of it as a feature with some issues to fix, not to remove at all. After all, there is a fix provided, it is more or less straightforward (I hope so), with tests showing a desired behavior. The desired behavior is also more or less obvious: take a __mro__ calculated by mro() invoked due to the very last __bases__ assignment, regardless reentrancy (the innermost one in such case).

Summarizing, that is why I believe that reentrancy should not be forbidden. Furthermore, I considered that way, and I'm pretty sure it is a wrong one. It implies too many corner cases, it has a non-obvious behavior from the point of view of a Python code, and a possible implementation doesn't seem to be more simple or robust than it is now.

I would be happy to hear opposite arguments, and if I convinced you, get a feedback on the patch, of course. I could also prepare a backport patch fixing 2.7 line as well.

----------

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

From report at bugs.python.org  Fri Nov  7 20:49:37 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 19:49:37 +0000
Subject: [issue814253] Grouprefs in lookbehind assertions
Message-ID: <20141107194915.108371.64120@psf.io>


Roundup Robot added the comment:

New changeset fac649bf2d10 by Serhiy Storchaka in branch '2.7':
Issues #814253, #9179: Group references and conditional group references now
https://hg.python.org/cpython/rev/fac649bf2d10

New changeset 9fcf4008b626 by Serhiy Storchaka in branch '3.4':
Issues #814253, #9179: Group references and conditional group references now
https://hg.python.org/cpython/rev/9fcf4008b626

New changeset 60fccf0aad83 by Serhiy Storchaka in branch 'default':
Issues #814253, #9179: Group references and conditional group references now
https://hg.python.org/cpython/rev/60fccf0aad83

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

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

From report at bugs.python.org  Fri Nov  7 20:49:37 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 19:49:37 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <20141107194915.108371.18136@psf.io>


Roundup Robot added the comment:

New changeset fac649bf2d10 by Serhiy Storchaka in branch '2.7':
Issues #814253, #9179: Group references and conditional group references now
https://hg.python.org/cpython/rev/fac649bf2d10

New changeset 9fcf4008b626 by Serhiy Storchaka in branch '3.4':
Issues #814253, #9179: Group references and conditional group references now
https://hg.python.org/cpython/rev/9fcf4008b626

New changeset 60fccf0aad83 by Serhiy Storchaka in branch 'default':
Issues #814253, #9179: Group references and conditional group references now
https://hg.python.org/cpython/rev/60fccf0aad83

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

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

From report at bugs.python.org  Fri Nov  7 20:55:19 2014
From: report at bugs.python.org (David Edelsohn)
Date: Fri, 07 Nov 2014 19:55:19 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415390119.56.0.4986864102.issue20220@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Any other ideas for a reliable method to restore the correct timezone after running a test?

----------

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

From report at bugs.python.org  Fri Nov  7 21:37:06 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 20:37:06 +0000
Subject: [issue814253] Grouprefs in lookbehind assertions
Message-ID: <20141107203659.108097.79606@psf.io>


Roundup Robot added the comment:

New changeset 0e2c7d774df3 by Serhiy Storchaka in branch '2.7':
Silence the failure of test_pyclbr after adding a property in sre_parse
https://hg.python.org/cpython/rev/0e2c7d774df3

New changeset 246c9570a757 by Serhiy Storchaka in branch '3.4':
Silence the failure of test_pyclbr after adding a property in sre_parse
https://hg.python.org/cpython/rev/246c9570a757

New changeset b2c17681404f by Serhiy Storchaka in branch 'default':
Silence the failure of test_pyclbr after adding a property in sre_parse
https://hg.python.org/cpython/rev/b2c17681404f

----------

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

From report at bugs.python.org  Fri Nov  7 21:38:49 2014
From: report at bugs.python.org (Doug Royal)
Date: Fri, 07 Nov 2014 20:38:49 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1415392729.14.0.800908498388.issue18473@psf.upfronthosting.co.za>


Doug Royal added the comment:

This patch only addresses the proven errors with UserList, UserString, and collections.

----------
keywords: +patch
nosy: +doug.royal
Added file: http://bugs.python.org/file37145/fix_issue18473.patch

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

From report at bugs.python.org  Fri Nov  7 22:27:30 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 21:27:30 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <1415395650.6.0.588211375363.issue9179@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/issue9179>
_______________________________________

From report at bugs.python.org  Fri Nov  7 22:29:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 21:29:40 +0000
Subject: [issue814253] Grouprefs in lookbehind assertions
Message-ID: <1415395780.3.0.801623226199.issue814253@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Now group references to groups with fixed width are supported in lookbehind assertions.

----------
assignee: effbot -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.2

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

From report at bugs.python.org  Fri Nov  7 22:31:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 21:31:42 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
 data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1415395902.18.0.992711924137.issue12728@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file36681/re_ignore_case.patch

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

From report at bugs.python.org  Fri Nov  7 22:32:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 21:32:20 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
 data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1415395940.0.0.0340420483082.issue12728@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file37087/re_cases.py

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

From report at bugs.python.org  Fri Nov  7 22:39:11 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 21:39:11 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
 data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1415396351.28.0.518765669073.issue12728@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review?

The script is updated so that it now is compatible with 2.7. There are some differences in equivalence table between 2.7 and 3.4 (e.g. '?' (U+0390) is not equivalent to '?' (U+1FD3) in 2.7).

----------
Added file: http://bugs.python.org/file37146/re_cases.py

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

From report at bugs.python.org  Fri Nov  7 22:42:01 2014
From: report at bugs.python.org (Rex Dwyer)
Date: Fri, 07 Nov 2014 21:42:01 +0000
Subject: [issue22817] re.split fails with lookahead/behind
Message-ID: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>


New submission from Rex Dwyer:

I would like to split a DNA sequence with a restriction enzyme.
A description enzyme can be describe as, e.g.  r'(?<CA)(?=GCTG)'
I cannot get re.split to split on this pattern as perl 5 does.

----------
components: Regular Expressions
messages: 230831
nosy: ezio.melotti, mrabarnett, rexdwyer
priority: normal
severity: normal
status: open
title: re.split fails with lookahead/behind
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  7 22:47:45 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 07 Nov 2014 21:47:45 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1415396865.61.0.659616659418.issue22817@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Can you provide a sample DNA sequence (or part of it), the exact code you used, the output you got, and what you expected?

----------

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

From report at bugs.python.org  Fri Nov  7 22:58:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 21:58:27 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1415397507.55.0.855078599603.issue22817@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> re.split(r'(?<=CA)(?=GCTG)', 'CAGCTG')
['CAGCTG']

I think expected output is ['CA', 'GCTG'].

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

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

From report at bugs.python.org  Fri Nov  7 23:08:07 2014
From: report at bugs.python.org (Rex Dwyer)
Date: Fri, 07 Nov 2014 22:08:07 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1415398087.21.0.102116868296.issue22817@psf.upfronthosting.co.za>


Rex Dwyer added the comment:

sorry if I wasn't clear.

s = 'ACGTCAGCTGAAACCCCAGCTGACGTACGT
re.split(r'(?<CA)(?=GCTG)',s)

expected output is:
acgtCA|GCTGaaacccCA|GCTGacgtacgt
-> ['ACGTCA', 'GCTGAAACCCCA', 'GCTGACGTACGT']

I would also be able to split a text on word boundaries:
re.split(r'\b', "the quick, brown fox")
-> ['the', ' ', 'quick', ', ', 'brown', ' ', 'fox']

but that doesn't work either so maybe it's a problem with all zero-width matches.

----------

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

From report at bugs.python.org  Fri Nov  7 23:11:00 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Nov 2014 22:11:00 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1415398260.76.0.031891036979.issue22817@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as one of existing issue about zero-length matches (issue1647489, issue10328).

----------

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

From report at bugs.python.org  Fri Nov  7 23:41:12 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2014 22:41:12 +0000
Subject: [issue22804] Can't run Idle in Windows 8 or windows 64
In-Reply-To: <1415268649.04.0.373697042917.issue22804@psf.upfronthosting.co.za>
Message-ID: <1415400072.94.0.841358487218.issue22804@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/issue22804>
_______________________________________

From report at bugs.python.org  Fri Nov  7 23:44:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Nov 2014 22:44:28 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1415400268.07.0.773078357474.issue22813@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, michael.foord

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

From report at bugs.python.org  Sat Nov  8 06:42:12 2014
From: report at bugs.python.org (sbspider)
Date: Sat, 08 Nov 2014 05:42:12 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1415425332.49.0.861706900173.issue22813@psf.upfronthosting.co.za>


sbspider added the comment:

To clarify - are you querying about 

a) Randomiser for tests, so that tests can have random variables
or 
b) That the order in which tests are called should have the option to be randomized

?

----------
nosy: +sbspider

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

From report at bugs.python.org  Sat Nov  8 06:47:38 2014
From: report at bugs.python.org (Robert Collins)
Date: Sat, 08 Nov 2014 05:47:38 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1415425658.28.0.484447278139.issue22813@psf.upfronthosting.co.za>


Robert Collins added the comment:

b)

----------

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

From report at bugs.python.org  Sat Nov  8 07:32:04 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Nov 2014 06:32:04 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415428324.35.0.673781895056.issue22789@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> there is really no reason why they should take more space on disk
> than necessary, so it's a sure win in any case.

That is a nice summary.

> FWIW, LZ4HC compression sounds like an obvious choice for
> write-once-read-many data like .pyc files to me.

+1

----------

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

From report at bugs.python.org  Sat Nov  8 10:11:19 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 09:11:19 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1415437879.71.0.116422408869.issue22817@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is possible to change this behavior (see example patch). With this patch:

>>> re.split(r'(?<=CA)(?=GCTG)', 'ACGTCAGCTGAAACCCCAGCTGACGTACGT')
['ACGTCA', 'GCTGAAACCCCA', 'GCTGACGTACGT']
>>> re.split(r'\b', "the quick, brown fox")
['', 'the', ' ', 'quick', ', ', 'brown', ' ', 'fox', '']

But unfortunately this is backward incompatible change and will likely break existing code (and breaks tests). Consider following example: re.split('(:*)', 'ab'). Currently the result is ['ab'], but with the patch it is ['', '', 'a', '', 'b', '', ''].

In third-part regex module [1] there is the V1 flag which switches incompatible bahavior change.

>>> regex.split('(:*)', 'ab')
['ab']
>>> regex.split('(?V1)(:*)', 'ab')
['', '', 'a', '', 'b', '', '']
>>> regex.split(r'(?<=CA)(?=GCTG)', 'ACGTCAGCTGAAACCCCAGCTGACGTACGT')
['ACGTCAGCTGAAACCCCAGCTGACGTACGT']
>>> regex.split(r'(?V1)(?<=CA)(?=GCTG)', 'ACGTCAGCTGAAACCCCAGCTGACGTACGT')
['ACGTCA', 'GCTGAAACCCCA', 'GCTGACGTACGT']
>>> regex.split(r'\b', "the quick, brown fox")
['the quick, brown fox']
>>> regex.split(r'(?V1)\b', "the quick, brown fox")
['', 'the', ' ', 'quick', ', ', 'brown', ' ', 'fox', '']

I don't know how to solve this issue without introducing such flag (or adding special boolean argument to re.split()).

As a workaround I suggest you to use the regex module.

[1] https://pypi.python.org/pypi/regex

----------
keywords: +patch
Added file: http://bugs.python.org/file37147/re_split_zero_width.patch

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

From report at bugs.python.org  Sat Nov  8 10:28:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 09:28:55 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415077245.4.0.700609350165.issue22789@psf.upfronthosting.co.za>
Message-ID: <1415438935.29.0.880721978493.issue22789@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Compressing pyc files one by one wouldn't save much space because disk space is allocated by blocks (up to 32 KiB on FAT32). If the size of pyc file is less than block size, we will not gain anything. ZIP file has advantage due more compact packing of files. In additional it can has less access time due to less fragmentation. Unfortunately it doesn't support the LZ4 compression, but we can store LZ4 compressed files in ZIP file without additional compression.

Uncompressed TAR file has same advantages but needs longer initialization time (for building the index).

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

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

From report at bugs.python.org  Sat Nov  8 10:39:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 09:39:13 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1415439553.08.0.227643901762.issue22817@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Previous attempts to solve this issue: issue852532, issue988761, issue3262.

----------

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

From report at bugs.python.org  Sat Nov  8 11:08:17 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 08 Nov 2014 10:08:17 +0000
Subject: [issue22789] Compress the marshalled data in PYC files
In-Reply-To: <1415438935.29.0.880721978493.issue22789@psf.upfronthosting.co.za>
Message-ID: <545DEB87.5040202@egenix.com>


Marc-Andre Lemburg added the comment:

On 08.11.2014 10:28, Serhiy Storchaka wrote:
> Compressing pyc files one by one wouldn't save much space because disk space is allocated by blocks (up to 32 KiB on FAT32). If the size of pyc file is less than block size, we will not gain anything. ZIP file has advantage due more compact packing of files. In additional it can has less access time due to less fragmentation. Unfortunately it doesn't support the LZ4 compression, but we can store LZ4 compressed files in ZIP file without additional compression.
> 
> Uncompressed TAR file has same advantages but needs longer initialization time (for building the index).

The aim is to reduce file load time, not really to save disk space.
By having less data to read from the disk, it may be possible
to achieve a small startup speedup.

However, you're right in that using a single archive with many PYC files
would be more efficient, since it lowers the number of stat() calls.
The trick to store LZ4 compressed data in a ZIP file would enable this.

BTW: We could add optional LZ4 compression to the marshal format to
make all this work transparently and without having to change the
import mechanism itself:

We'd just need to add a new flag or type code indicating that the rest
of the stream is LZ4 compressed. The PYC writer could then enable this
flag or type code per default (or perhaps enabled via some env var od
command line flag) and everything would then just work with both
LZ4 compressed byte code as well as non-compressed byte code.

----------

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

From report at bugs.python.org  Sat Nov  8 12:01:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 11:01:20 +0000
Subject: [issue22818] Deprecate splitting on possible zero-width re patterns
Message-ID: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now re.split doesn't split with zero-width regex. There are a number of issues for this (issue852532, issue988761, issue3262, issue22817). This is definitely a bug, but fixing this bug will likely break existing code which use regular expressions which can match zero-width (e.g. re.split('(:*)', 'ab')).

I propose to deprecate splitting on possible zero-width regular expressions. This expressions either not work at all as expected (r'\b' never split) or can be rewritten to not match empty string ('(:*)' to '(:+)').

In next release (3.6) we can convert deprecation warning to the exception, an then after transitional period change behavior to more correct handling zero-width matches without breaking backward compatibility.

----------
components: Extension Modules, Regular Expressions
files: re_deprecate_split_zero_width.patch
keywords: patch
messages: 230843
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate splitting on possible zero-width re patterns
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37148/re_deprecate_split_zero_width.patch

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

From report at bugs.python.org  Sat Nov  8 12:17:10 2014
From: report at bugs.python.org (Edward K. Ream)
Date: Sat, 08 Nov 2014 11:17:10 +0000
Subject: [issue22819] Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails
 with pythonw.exe
Message-ID: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za>


New submission from Edward K. Ream:

In Python3.2 xml.sax.saxutils.XMLGenerator.__init__ succeeds if the "out" keyword argument is not given and sys.stdout is None, which will typically be the case when using pythonw.exe.

Alas, on Python3.4, the ctor throws an exception in this case.

This is a major compatibility issue, and is completely unnecessary: the ctor should work as before.  An easy fix: allocate a file-like object as the out stream, or just do what is done in Python 3.2 ;-)

----------
components: Library (Lib)
messages: 230844
nosy: Edward.K..Ream
priority: normal
severity: normal
status: open
title: Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails with pythonw.exe
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov  8 12:23:39 2014
From: report at bugs.python.org (Edward Alexander)
Date: Sat, 08 Nov 2014 11:23:39 +0000
Subject: [issue22820] RESTART line with no output
Message-ID: <1415445819.89.0.337025555913.issue22820@psf.upfronthosting.co.za>


New submission from Edward Alexander:

Whenever i run my code on Python IDLE editor,
the output is as follows:

============================== RESTART================================

I am a newbie,it seems i cannot move from this point .
This is my code:
def convert_to_celsius(fahrenheit):
    return (fahrenheit - 32) * 5.0 / 9.0
convert_to_celsius(80)

----------
components: IDLE
messages: 230845
nosy: sukari
priority: normal
severity: normal
status: open
title: RESTART line with no output
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov  8 12:59:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 11:59:18 +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: <1415447958.72.0.395846219019.issue2636@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is my (slowly implemented) plan:

0. Recommend regex as advanced replacement of re (issue22594).

1. Fix all obvious bugs in the re module if this doesn't break backward compatibility (issue12728, issue14260, and many already closed issues).

2. Deprecate and then forbid behavior which looks as a bug, doesn't match regex in V1 mode and can't be fixed without breaking backward compatibility (issue22407, issue22493, issue22818).

3. Unify minor details with regex (issue22364, issue22578).

4. Fork regex and drop all advanced nonstandard features (such as fuzzy matching). Too many features make learning and using the module more hard. They should be in advanced module (regex).

5. Write benchmarks which cover all corner cases and compare re with regex case by case. Optimize slower module. Currently re is faster regex for all simple examples which I tried (may be as result of issue18685), but in total results of benchmarks (msg109447) re is slower.

6. May be implement some standard features which were rejected in favor of this issue (issue433028, issue433030). re should conform at least Level 1 of UTS #18 (http://www.unicode.org/reports/tr18/#Basic_Unicode_Support).

In best case in 3.7 or 3.8 we could replace re with simplified regex. Or at this time re will be free from bugs and warts.

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

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

From report at bugs.python.org  Sat Nov  8 13:03:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 12:03:01 +0000
Subject: [issue22819] Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails
 with pythonw.exe
In-Reply-To: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za>
Message-ID: <1415448181.19.0.576399336281.issue22819@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In any case XMLGenerator is not usable if the "out" keyword argument is not given and sys.stdout is None. Just the exception will be raised later. I consider early failure as a feature, not a bug.

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

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

From report at bugs.python.org  Sat Nov  8 13:14:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 12:14:26 +0000
Subject: [issue3511] Incorrect charset range handling with ignore case flag?
In-Reply-To: <1218051735.51.0.548930988583.issue3511@psf.upfronthosting.co.za>
Message-ID: <1415448866.6.0.711449334691.issue3511@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed in issue17381 (which has more realistic example than [9-A]).

----------
nosy: +serhiy.storchaka
resolution: wont fix -> duplicate
superseder:  -> IGNORECASE breaks unicode literal range matching

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

From report at bugs.python.org  Sat Nov  8 13:19:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 12:19:22 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1415449162.61.0.309717329263.issue433028@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree that they'd be nice. The regex module is too advanced and need much work and some transitional period for including in the stdlib, but this feature can be implemented right now.

----------
assignee: effbot -> serhiy.storchaka
nosy: +serhiy.storchaka
resolution: duplicate -> 
stage:  -> needs patch
superseder: Major reworking of Python 2.5.2 re module -> 
versions: +Python 3.5

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

From report at bugs.python.org  Sat Nov  8 13:25:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 12:25:41 +0000
Subject: [issue433027] SRE: (?-flag) is not supported.
Message-ID: <1415449541.1.0.813340837753.issue433027@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think issue433028 supersedes this and looks more preferable. No need to implement several ways to do same things.

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

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

From report at bugs.python.org  Sat Nov  8 13:27:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 12:27:50 +0000
Subject: [issue433024] SRE: (?flag) isn't properly scoped
Message-ID: <1415449670.95.0.24827768874.issue433024@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue22493.

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

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

From report at bugs.python.org  Sat Nov  8 13:41:48 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Nov 2014 12:41:48 +0000
Subject: [issue22819] Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails
 with pythonw.exe
In-Reply-To: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za>
Message-ID: <1415450508.48.0.0618352754585.issue22819@psf.upfronthosting.co.za>


R. David Murray added the comment:

Agreed.  I was going to ask what it was that 3.2 did that was useful.

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

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

From report at bugs.python.org  Sat Nov  8 13:50:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Nov 2014 12:50:38 +0000
Subject: [issue22820] RESTART line with no output
In-Reply-To: <1415445819.89.0.337025555913.issue22820@psf.upfronthosting.co.za>
Message-ID: <1415451038.27.0.675262706273.issue22820@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your code doesn't produce any output (ie: there are no print calls).  I don't use Idle myself, but I'm guessing that is why you don't see anything after the restart line.  If that is the case, do you see a place in whatever help or documentation you have read that it would be appropriate to mention this?  (The distinction is that the REPL window automatically prints the return value of whatever you type in, whereas in a program you get output only if you do the print yourself).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray, terry.reedy
type: crash -> behavior
versions: +Python 3.4, Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Nov  8 13:56:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 12:56:14 +0000
Subject: [issue22819] Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails
 with pythonw.exe
In-Reply-To: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za>
Message-ID: <1415451374.11.0.422162428927.issue22819@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

FYI the code was changed in issue1470548.

----------

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

From report at bugs.python.org  Sat Nov  8 14:16:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 13:16:22 +0000
Subject: [issue1282] re module needs to support bytes / memoryview well
In-Reply-To: <1192490811.67.0.131142181278.issue1282@psf.upfronthosting.co.za>
Message-ID: <1415452582.34.0.540380926758.issue1282@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually non-hashable patterns are not supported.

>>> re.match(bytearray(b'.'), b'x')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/re.py", line 163, in match
    return _compile(pattern, flags).match(string)
  File "/home/serhiy/py/cpython/Lib/re.py", line 281, in _compile
    p, loc = _cache[type(pattern), pattern, flags]
TypeError: unhashable type: 'bytearray'

Should it be considered as a bug?

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

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

From report at bugs.python.org  Sat Nov  8 14:26:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 13:26:22 +0000
Subject: [issue1708652] Exact matching
Message-ID: <1415453182.84.0.21070285603.issue1708652@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Was implemented as fullmatch() in issue16203.

----------
nosy: +serhiy.storchaka
resolution: rejected -> duplicate
superseder:  -> Proposal: add re.fullmatch() method

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

From report at bugs.python.org  Sat Nov  8 15:28:37 2014
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 08 Nov 2014 14:28:37 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <1415456917.85.0.465970345402.issue20152@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So I disagree that the code needs to be tweaked before converting to Argument Clinic. If the Clinic conversion is not adding to the problem then the code churn is just going to make applying this patch that much harder.

Thanks for the code review regardless, though!

----------

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

From report at bugs.python.org  Sat Nov  8 15:33:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 14:33:24 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <1415457204.91.0.87019903563.issue20152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If first convert to Argument Clinic then fixing bugs will be much harder.

----------

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

From report at bugs.python.org  Sat Nov  8 15:43:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 14:43:09 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <1415457789.25.0.737090749227.issue20152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

About argument names. You have changed argument names and docstrings in any case (e.g. was "op", now "code"). Why not conform with standard documentation? This wouldn't add additional code churn if change it now. But will add if change it later.

----------

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

From report at bugs.python.org  Sat Nov  8 15:44:28 2014
From: report at bugs.python.org (Rishi)
Date: Sat, 08 Nov 2014 14:44:28 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1415457868.02.0.288036673935.issue1610654@psf.upfronthosting.co.za>


Rishi added the comment:

Hi,
I have created a new patch with a small design change. The change is that in situations where I don't find the boundary instead of keeping the last x bytes in the buffer I simply drain the whole data and call a readline(). 
This seems like the right thing to do also. I managed to get rid of the two obfuscated helper functions keep_x_buffer and remove_x_buffer that I had and the code should look familiar (I hope) to a module owner.
This also helped me get rid of quite a few class member variables that I could move to locals of my main function(multi_read).
I still need to maintain an overlap, but only for the trailing CRLF boundary. 
Ran all the new and old tests and tested on apache with the ubuntu iso server image. Without the patch ubuntu iso server image took 93seconds .. with the patch it took 25seconds.

----------
Added file: http://bugs.python.org/file37149/issue1610654_3.patch

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

From report at bugs.python.org  Sat Nov  8 15:54:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 14:54:38 +0000
Subject: [issue22821] Argument of wrong type is passed to fcntl()
Message-ID: <1415458478.26.0.185263171518.issue22821@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Arguments of wrong type is passed to C function fcntl() in the fcntl module.

Third argument of fcntl() should be either pointer to binary structure or C int. But C long is passed instead. All works on platforms where sizeof(long) == sizeof(int) or on little-endian platforms, but on big-endian platform with sizeof(long) != sizeof(int) this will pass wrong value.

----------
components: Extension Modules
messages: 230861
nosy: brett.cannon, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument of wrong type is passed to fcntl()
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  8 16:06:08 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Nov 2014 15:06:08 +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: <1415459168.53.0.715422046332.issue2636@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Here is my (slowly implemented) plan:

Exciting. Perhaps you should post your plan on python-dev.

In any case, huge thanks for your work on the re module.

----------

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

From report at bugs.python.org  Sat Nov  8 16:15:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 15:15:20 +0000
Subject: [issue22821] Argument of wrong type is passed to fcntl()
In-Reply-To: <1415458478.26.0.185263171518.issue22821@psf.upfronthosting.co.za>
Message-ID: <1415459720.27.0.296805230178.issue22821@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. It is much easier than I expected.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37150/fcntl_arg_type.patch

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

From report at bugs.python.org  Sat Nov  8 16:21:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 15:21:17 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415460077.0.0.355568526832.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be atomic grouping or possessive quantifiers (issue433030) will help with this issue.

----------

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

From report at bugs.python.org  Sat Nov  8 16:23:16 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Nov 2014 15:23:16 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415460196.04.0.772537745229.issue22800@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Sat Nov  8 16:39:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 15:39:15 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za>
Message-ID: <1415461155.62.0.62909557183.issue22434@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please make a review of any patch Antoine? This would help me to debug re engine. It doesn't matter which patch apply, with good chance all this will be changed before 3.5 release and may be not once.

----------

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

From report at bugs.python.org  Sat Nov  8 16:58:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 15:58:31 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1415459168.53.0.715422046332.issue2636@psf.upfronthosting.co.za>
Message-ID: <3204870.511losUUBR@raxxla>


Serhiy Storchaka added the comment:

> Exciting. Perhaps you should post your plan on python-dev.

Thank you Antoine. I think all interested core developers are already aware 
about this issue. A disadvantage of posting on python-dev is that this would 
require manually copy links and may be titles of all mentioned issues, while 
here they are available automatically. Oh, I'm lazy.

----------

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

From report at bugs.python.org  Sat Nov  8 17:04:18 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 08 Nov 2014 16:04:18 +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: <1415462658.71.0.792741150045.issue2636@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

So you are suggesting to fix bugs in re to make it closer to regex, and then replace re with a forked subset of regex that doesn't include advanced features, or just to fix/improve re until it matches the behavior of regex?
If you are suggesting the former, I would also suggest checking the coverage and bringing it as close as possible to 100%.

----------

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

From report at bugs.python.org  Sat Nov  8 17:25:59 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Nov 2014 16:25:59 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415463959.36.0.0388786755905.issue22800@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The doc is unhelpful on this, but looking at the implementation and tests, only a prefix length is allowed, not an expanded netmask. This would therefore be a feature request.

----------
type: behavior -> enhancement
versions:  -Python 3.4

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

From report at bugs.python.org  Sat Nov  8 18:32:04 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Sat, 08 Nov 2014 17:32:04 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415467924.49.0.822525066783.issue22800@psf.upfronthosting.co.za>


Chris PeBenito added the comment:

That's unfortunate. The library provides factory functions so v4 and v6 addresses/networks are easily handled together, and yet it seems to have been overlooked that you can do this:

ipaddress.ip_network('192.168.1.0/255.255.255.0') 

but not this:

ipaddress.ip_network('ff00::/ff00::')

I'll open up another issue for the docs, as they are not simply unhelpful, they're misleading, as the IPv6Network docs clearly say that you should be able to use an expanded netmask.

----------

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

From report at bugs.python.org  Sat Nov  8 18:33:58 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 08 Nov 2014 17:33:58 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415468038.05.0.888698960094.issue22800@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't know enough about IPv6 to give more insight (perhaps Peter Moody can answer), but the tests have this comment: 

# We only support CIDR for IPv6, because expanded netmasks are not
# standard notation.

----------

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

From report at bugs.python.org  Sat Nov  8 18:43:49 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Sat, 08 Nov 2014 17:43:49 +0000
Subject: [issue22822] IPv6Network constructor docs incorrect about valid input
Message-ID: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za>


New submission from Chris PeBenito:

Here:

https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Network

In the constructor documentation, item 1 says:

"""
A string consisting of an IP address and an optional mask, separated by a slash (/). The IP address is the network address, and the mask can be either a single number, which means it?s a prefix, or a string representation of an IPv6 address. If it?s the latter, the mask is interpreted as a net mask. If no mask is provided, it?s considered to be /128.

For example, the following address specifications are equivalent: 2001:db00::0/24 and 2001:db00::0/ffff:ff00::.
"""

However in issue22800 it has been identified that using the expanded netmask (e.g. ff00::/ff00::) is not supported.

----------
assignee: docs at python
components: Documentation
messages: 230871
nosy: docs at python, pebenito
priority: normal
severity: normal
status: open
title: IPv6Network constructor docs incorrect about valid input
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov  8 19:04:49 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 08 Nov 2014 18:04:49 +0000
Subject: [issue1282] re module needs to support bytes / memoryview well
In-Reply-To: <1192490811.67.0.131142181278.issue1282@psf.upfronthosting.co.za>
Message-ID: <1415469889.25.0.128208963525.issue1282@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Hm, I don't see a reason why the *pattern* should be a bytearray or memoryview, only the string it is searching. But if you fixed it by casting it to bytes I won't stop you. :-)

----------

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

From report at bugs.python.org  Sat Nov  8 21:22:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 20:22:10 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1415462658.71.0.792741150045.issue2636@psf.upfronthosting.co.za>
Message-ID: <16272277.6LCEqyUnHx@raxxla>


Serhiy Storchaka added the comment:

> So you are suggesting to fix bugs in re to make it closer to regex, and then
> replace re with a forked subset of regex that doesn't include advanced
> features, or just to fix/improve re until it matches the behavior of regex?

Depends on what will be easier. May be some bugs are so hard to fix that 
replacing re with regex is only solution. But if fixed re will be simpler and 
faster than lightened regex and will contain all necessary features, there 
will be no need in the replacing. Currently the code of regex looks more high 
level and better structured, but the code of re looks simpler and is much 
smaller. In any case the closer will be re and regex the easier will be the 
migration.

----------

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

From report at bugs.python.org  Sat Nov  8 21:27:32 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Nov 2014 20:27:32 +0000
Subject: [issue1282] re module needs to support bytes / memoryview well
In-Reply-To: <1415469889.25.0.128208963525.issue1282@psf.upfronthosting.co.za>
Message-ID: <6077429.LFGXUCeej7@raxxla>


Serhiy Storchaka added the comment:

It is easy to fix with small (but non zero) cost, but I don't see a reason too. 
So I don't reopen this issue.

----------

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

From report at bugs.python.org  Sat Nov  8 21:40:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Nov 2014 20:40:51 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <20141108204048.108373.52185@psf.io>


Roundup Robot added the comment:

New changeset 9001298e3094 by Berker Peksag in branch '3.4':
Issue #22695: Fix rendering of the deprecated-removed role in HTML.
https://hg.python.org/cpython/rev/9001298e3094

New changeset ec81edc30221 by Berker Peksag in branch 'default':
Issue #22695: Fix rendering of the deprecated-removed role in HTML.
https://hg.python.org/cpython/rev/ec81edc30221

----------

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

From report at bugs.python.org  Sat Nov  8 21:42:58 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Nov 2014 20:42:58 +0000
Subject: [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1415479378.79.0.320735756352.issue22695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the reviews.

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

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

From report at bugs.python.org  Sat Nov  8 22:02:13 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 08 Nov 2014 21:02:13 +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: <1415480533.93.0.901828087335.issue2636@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Ok, regardless of what will happen, increasing test coverage is a worthy goal.  We might start by looking at the regex test suite to see if we can import some tests from there.

----------

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

From report at bugs.python.org  Sun Nov  9 03:52:26 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 02:52:26 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za>
Message-ID: <1415501546.92.0.728532376224.issue22434@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I reviewed re_named_consts.patch and it looks great (I especially like the removal of superfluous OPCODES dictionary lookups and improved repr for the integer codes).

Since the op codes are singletons, you can use identity tests instead of 
equality checks in sre_parse.py:

  -      if op == "in":
  +      if op == IN:

Also, I'll echo the suggestion to make NamedIntConstant private with a leading underscore.

Nice work.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Nov  9 03:54:03 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 02:54:03 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za>
Message-ID: <1415501643.8.0.999185119685.issue22434@psf.upfronthosting.co.za>


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


----------
nosy: +effbot

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

From report at bugs.python.org  Sun Nov  9 04:04:47 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 03:04:47 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
Message-ID: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

There are many places where the old-style of creating a set from a list still persists.  The literal notation is idiomatic, cleaner looking, and faster.

Here's a typical change:


  diff --git a/Lib/sre_compile.py b/Lib/sre_compile.py
  --- a/Lib/sre_compile.py
  +++ b/Lib/sre_compile.py
  @@ -22,10 +22,10 @@
   else:
       MAXCODE = 0xFFFFFFFF
 
  -_LITERAL_CODES = set([LITERAL, NOT_LITERAL])
  -_REPEATING_CODES = set([REPEAT, MIN_REPEAT, MAX_REPEAT])
  -_SUCCESS_CODES = set([SUCCESS, FAILURE])
  -_ASSERT_CODES = set([ASSERT, ASSERT_NOT])
  +_LITERAL_CODES = {LITERAL, NOT_LITERAL}
  +_REPEATING_CODES = {REPEAT, MIN_REPEAT, MAX_REPEAT}
  +_SUCCESS_CODES = {SUCCESS, FAILURE}
  +_ASSERT_CODES = {ASSERT, ASSERT_NOT}

Here are typical timings:

  $ py34 -m timeit '{10, 20, 30}'
   10000000 loops, best of 3: 0.145 usec per loop

  $ py34 -m timeit 'set([10, 20, 30])'
  1000000 loops, best of 3: 0.477 usec per loop

----------
components: Library (Lib)
keywords: easy
messages: 230879
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Use set literals instead of creating a set from a list
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov  9 04:22:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 03:22:18 +0000
Subject: [issue22824] Update reprlib to use set literals
Message-ID: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently reprlib outputs:

    >>> reprlib.repr(set('supercalifragilisticexpialidocious'))
    "set(['a', 'c', 'd', 'e', 'f', 'g', ...])"

This should be:

    "{'a', 'c', 'd', 'e', 'f', 'g', ...}"

----------
keywords: easy
messages: 230880
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Update reprlib to use set literals
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov  9 04:23:50 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 09 Nov 2014 03:23:50 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415503430.56.0.845147260087.issue22824@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/issue22824>
_______________________________________

From report at bugs.python.org  Sun Nov  9 04:24:27 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Nov 2014 03:24:27 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415503467.06.0.0537402477534.issue22824@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib)
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Sun Nov  9 04:25:39 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 03:25:39 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415503539.39.0.854853761708.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Note, to keep the tests stable, nothing in Lib/tests should be changed.  Any update should target the rest of Lib and Doc.

----------

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

From report at bugs.python.org  Sun Nov  9 04:42:12 2014
From: report at bugs.python.org (Akira Li)
Date: Sun, 09 Nov 2014 03:42:12 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415504532.4.0.509011714028.issue22791@psf.upfronthosting.co.za>


Akira Li added the comment:

>>> from datetime import datetime, timezone
  >>> datetime.fromtimestamp(0, timezone.utc)
  datetime.datetime(1970, 1, 1, 0, 0, tzinfo=datetime.timezone.utc)

already works and it is documented [1]

[1] https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp

Or it can be written as:

  >>> epoch = datetime(1970, 1, 1, tzinfo=timezone.utc)
  >>> aware_utc = epoch + timedelta(seconds=posix_timestamp)

----------
nosy: +akira

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

From report at bugs.python.org  Sun Nov  9 04:57:00 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 09 Nov 2014 03:57:00 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415505420.07.0.967559246131.issue22791@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I personally wish we could deprecate utcfromtimestamp.  With timezone.utc in stdlib and being a singleton there is no reason to put UTC time in naive datetime instances.

----------

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

From report at bugs.python.org  Sun Nov  9 05:06:22 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 09 Nov 2014 04:06:22 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415505982.08.0.886725146357.issue22823@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Sun Nov  9 05:22:26 2014
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 09 Nov 2014 04:22:26 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415506946.09.0.27520263643.issue22791@psf.upfronthosting.co.za>


INADA Naoki added the comment:

akira:

It seems cleaner than utcfromtimestamp().replace().
I think utcfromtimestamp() should have note about it.

"""
Note that it returns **naive** (tz=None) datetime.  Naive datetime is
treated as localtime in most functions.
If you want to create aware datetime, use `.fromtimestamp(ts, tz=timezone.utc)` instead.
"""

And I want to add this note to docstring too, since I read docstring before
document.

----------

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

From report at bugs.python.org  Sun Nov  9 13:37:17 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 09 Nov 2014 12:37:17 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1415480533.93.0.901828087335.issue2636@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eiyyjxFGgM_MhHo9VP+2GnyeHzeK4vx4dM7i0DbKFZyg@mail.gmail.com>


Nick Coghlan added the comment:

Thanks for pushing this one forward Serhiy! Your approach sounds like a
fine plan to me.

----------

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

From report at bugs.python.org  Sun Nov  9 15:45:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 14:45:41 +0000
Subject: [issue22825] Modernize TextFile
Message-ID: <1415544341.49.0.85924418958.issue22825@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes distutils.text_file.TextFile support context management and iterator protocols. It makes the use of TextFile simpler. The patch also includes other minor modernizations.

----------
components: Distutils
files: text_file.diff
keywords: patch
messages: 230886
nosy: dstufft, eric.araujo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Modernize TextFile
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37151/text_file.diff

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

From report at bugs.python.org  Sun Nov  9 16:49:10 2014
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sun, 09 Nov 2014 15:49:10 +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: <1415548150.47.0.594142862732.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs added the comment:

If I recall, I started this thread with a plan to update re itself with implementations of various features listed in the top post.  If you look at the list of files uploaded by me there are seme complete patches for Re to add various features like Atomic Grouping.  If we wish to therefore bring re to regex standard we could start with those features.

----------

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

From report at bugs.python.org  Sun Nov  9 17:07:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 16:07:35 +0000
Subject: [issue22826] Support context management protocol in bkfile
Message-ID: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes bkfile (file-like class used in freeze) support the context management protocol. This makes bkfile more file-like and makes the use of it simpler and more robust.

----------
components: Demos and Tools
files: bkfile.diff
keywords: patch
messages: 230888
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support context management protocol in bkfile
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37152/bkfile.diff

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

From report at bugs.python.org  Sun Nov  9 17:59:13 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 16:59:13 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
Message-ID: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>


New submission from Donald Stufft:

As specified in PEP 477, this backports PEP 453 (ensurepip) to the Python 2.7 branch. Key differences from PEP 453 are:

* It is not run by default in the Makefile
* There is no venv modules, so downstream can remove it (though are asked to patch it to provide instructions redirecting people to how they should install pip).
* The ``pip`` command is installed as well as ``pipX`` and ``pipX.Y``.
* Given the above, --default-pip is hidden and no-oped and --no-default-pip is added to restore the Python 3.x behavior.

This also includes a (slightly modified to make it work on 2.x) backport of unittest.mock as test._mock_backport in order to make it reasonable to run the ensurepip tests without actually installing pip.

This patch does not include any changes to the Windows installers or to the OS X installers. I've nosey'd Ned Deily for the OS X installer changes, I'm not sure who is doing the Windows Installers now adays.

Note: The attached patch does not contain the actual .whl files which are required. This is because it makes the patch into a 2M patch and the tracker didn't like that very much. This patch can be applied and then just copy over the Lib/ensurepip/_bundled directory from Python 3.4.

----------
files: pep-477.patch
keywords: needs review, patch
messages: 230889
nosy: doko, dstufft, ncoghlan, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Backport ensurepip to 2.7 (PEP 477)
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37154/pep-477.patch

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

From report at bugs.python.org  Sun Nov  9 18:00:27 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 17:00:27 +0000
Subject: [issue22828] Backport ensurepip to 2.7 (PEP 477)
Message-ID: <1415552424.14.0.477266117227.issue22828@psf.upfronthosting.co.za>


New submission from Donald Stufft:

As specified in PEP 477, this backports PEP 453 (ensurepip) to the Python 2.7 branch. Key differences from PEP 453 are:

* It is not run by default in the Makefile
* There is no venv modules, so downstream can remove it (though are asked to patch it to provide instructions redirecting people to how they should install pip).
* The ``pip`` command is installed as well as ``pipX`` and ``pipX.Y``.
* Given the above, --default-pip is hidden and no-oped and --no-default-pip is added to restore the Python 3.x behavior.

This also includes a (slightly modified to make it work on 2.x) backport of unittest.mock as test._mock_backport in order to make it reasonable to run the ensurepip tests without actually installing pip.

This patch does not include any changes to the Windows installers or to the OS X installers. I've nosey'd Ned Deily for the OS X installer changes, I'm not sure who is doing the Windows Installers now adays.

----------
files: pep-477.patch
keywords: needs review, patch
messages: 230890
nosy: doko, dstufft, ncoghlan, ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: Backport ensurepip to 2.7 (PEP 477)
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37153/pep-477.patch

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

From report at bugs.python.org  Sun Nov  9 18:01:30 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 17:01:30 +0000
Subject: [issue22828] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552424.14.0.477266117227.issue22828@psf.upfronthosting.co.za>
Message-ID: <1415552490.61.0.686918451493.issue22828@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Closing this in favor of http://bugs.python.org/issue22827

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Sun Nov  9 18:04:47 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 17:04:47 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415552687.52.0.26735299456.issue22827@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
nosy: +steve.dower

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

From report at bugs.python.org  Sun Nov  9 18:17:17 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 17:17:17 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415553437.08.0.401672408523.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Second patch just fixes the docs to specify the correct behavior for 2.7 and it fixes ensurepip.bootstrap() to match the default 2.7 behavior when executing python -m ensurepip.

----------
Added file: http://bugs.python.org/file37155/pep-477-2.patch

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

From report at bugs.python.org  Sun Nov  9 18:29:29 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 17:29:29 +0000
Subject: [issue22826] Support context management protocol in bkfile
In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>
Message-ID: <1415554169.66.0.456596879674.issue22826@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This looks correct and it improves readability.

One nit,  please put the doubled with on a single line instead of using the awkward line break (which looks weird with respect to the indentation of the with-block):

+    with open(config_c_in) as infp, bkfile.open(config_c, 'w') as outfp:

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Nov  9 18:59:17 2014
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Balcerzak?=)
Date: Sun, 09 Nov 2014 17:59:17 +0000
Subject: [issue22829] Add --prompt option to venv
Message-ID: <1415555957.14.0.777244809784.issue22829@psf.upfronthosting.co.za>


New submission from ?ukasz Balcerzak:

virtualenv tool allows to set alternative prompt prefix, Python's venv module should allow this too.

Basically, this allows one to run:

python -mvenv --prompt Quux myenv

And see "(Quux)" as a prefix after environment activation (instead of the "myenv" in this case).

----------
files: venv-prompt-argument.patch
keywords: patch
messages: 230894
nosy: ?ukasz.Balcerzak
priority: normal
severity: normal
status: open
title: Add --prompt option to venv
versions: Python 3.5
Added file: http://bugs.python.org/file37156/venv-prompt-argument.patch

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

From report at bugs.python.org  Sun Nov  9 19:05:18 2014
From: report at bugs.python.org (Eric Beurre)
Date: Sun, 09 Nov 2014 18:05:18 +0000
Subject: [issue21288] hashlib.pbkdf2_hmac Hash Constructor
In-Reply-To: <1397760292.99.0.128790868195.issue21288@psf.upfronthosting.co.za>
Message-ID: <1415556318.84.0.194700890836.issue21288@psf.upfronthosting.co.za>


Changes by Eric Beurre <hola at ericbeurre.com>:


----------
nosy: +egbutter

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

From report at bugs.python.org  Sun Nov  9 19:18:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 18:18:28 +0000
Subject: [issue22830] functools.cmp_to_key: misleading key function description
Message-ID: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/3.4/library/functools.html#functools.cmp_to_key says " A key function is a callable that accepts one argument and returns another value indicating the position in the desired collation sequence."  A python list poster (Veek M) 'value indicating the position' as meaning 0, 1, 2, ... and I would read it that way if I did not know better.

Entries for min() and max() say "The key argument specifies a one-argument ordering function like that used for list.sort()."  This would be reused here.  We also, now, have a Glossary entry for 'key function'.  This could be referred to instead.

----------
assignee: docs at python
components: Documentation
messages: 230895
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.cmp_to_key: misleading key function description
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  9 19:45:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 18:45:04 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <1415501546.92.0.728532376224.issue22434@psf.upfronthosting.co.za>
Message-ID: <8184788.6OkEFgrSc3@raxxla>


Serhiy Storchaka added the comment:

Thank you Raymond for the review.

> I especially like the removal of superfluous OPCODES dictionary lookups

The disadvantage is that now backporting patches to old branches is harder.

> Since the op codes are singletons, you can use identity tests instead of
> equality checks in sre_parse.py:

This is deliberate. There is small change that the opcodes could became an 
integers in future (after adding introspection to pattern object, or make it 
copyable, or allowing serialization of compiled codes). "is" instead of "==" 
can cause subtle bug. Note that "is" is used during parsing, but getwidth() is 
called from sre_compile.py.

----------

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

From report at bugs.python.org  Sun Nov  9 19:52:31 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 18:52:31 +0000
Subject: [issue22830] functools.cmp_to_key: misleading key function description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <1415559151.16.0.427193770445.issue22830@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll add a link to the glossary entry for key function and to the sorting howto.  Also, I'll change "value indicating the position" to "value to be used as the sort key".

The form sentence being discussed should probably remain close to how it is currently written.  It is part of a two sentence paragraph that contrasts cmp functions versus key functions, so the parallel sentence structure is part of what it is trying to communicate.

FWIW, interpreting "value indicating position" as 0, 1, 2, etc isn't incorrect.  That is a possible key function.

In general, I prefer doc changes to be very minor when they have a history of many people reading them correctly; otherwise, we risk moving away from something that was already working pretty well.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Sun Nov  9 19:56:44 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 18:56:44 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415559404.31.0.036565481067.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I will prepare a 3.5 patch for this.  There are not many instances other than those you found (but several times as many in tests).  I presume that most non-test instances were converted by the 2to3 fixer.

How about frozenset([...]) to frozenset({...})?  There are 4 occurrences of this. The semantic match between frozenset and {...} is better than with [...], but the visual gain in nearly nil.

I will leave the one idlelib instance in CodeContext for when I am editing the file anyway (for both 3.4 and 3.5), which should be soon.

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

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

From report at bugs.python.org  Sun Nov  9 20:07:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 19:07:05 +0000
Subject: [issue22826] Support context management protocol in bkfile
In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>
Message-ID: <1415560025.93.0.938574622576.issue22826@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Raymond. I found my old patch written 5 months ago. It drastically simplifies bkfile by using monkey-patching. What approach looks better to you?

----------
Added file: http://bugs.python.org/file37157/bkfile2.patch

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

From report at bugs.python.org  Sun Nov  9 20:10:52 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 19:10:52 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415560252.78.0.62135063007.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I did not look at Docs yet.

I could not repeat the timing results on my machine running from the command line, as I got '0.015 usec per loop' for both, and same for both frozenset variations.  Running timeit.repeat interactively and selecting the best reproduced your timing ratio: .16 to .42.  For frozenset, I get .36 to .42 in favor of changing to frozenset({...}).

----------

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

From report at bugs.python.org  Sun Nov  9 20:22:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 19:22:35 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
Message-ID: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is large patch which convert a code which potentially can leak file descriptor to use the with statement so files are always closed. This can make effect mainly on alternative Python implementation without reference counting. But even on CPython this will get rid from resource leaking warnings.

----------
components: Demos and Tools, Library (Lib), Tests
files: fd_leaks.diff
keywords: patch
messages: 230901
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use "with" to avoid possible fd leaks
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file37158/fd_leaks.diff

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

From report at bugs.python.org  Sun Nov  9 20:39:53 2014
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 09 Nov 2014 19:39:53 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1415561993.8.0.471969488015.issue22490@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> I don't quite understand why you use __PYVENV_LAUNCHER__

When I first developed the venv functionality it was definitely needed, but it looks as if it is not needed now. Perhaps to fix this completely, the following needs to be done, on the assumption that __PYVENV_LAUNCHER__ is no longer needed:

1. Remove the reference to it in distlib, and use sys.executable instead. Once pip incorporates this fix, the Homebrew problem should go away. (I have already made the change in the distlib repo, but this needs to be released in order for pip to consider vendoring it, and then pip needs to be released before Python can incorporate it).

2. Remove references to the environment variable in Python itself, using sys.executable instead.

As the env var was an implementation detail, ISTM it could be removed in a 3.4 point release - would you agree?

----------

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

From report at bugs.python.org  Sun Nov  9 20:42:48 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 19:42:48 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za>
Message-ID: <1415562168.39.0.058670156973.issue22434@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/issue22434>
_______________________________________

From report at bugs.python.org  Sun Nov  9 21:00:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 20:00:29 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415563229.7.0.289739818583.issue22823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Isn't such changes considered code churn?

If it is not, I have a huge patch which makes Python sources to use more modern idioms, including replacing set constructors with set literals (I have counted three occurrences not in tests). Are you interesting to look on it Raymond?

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

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

From report at bugs.python.org  Sun Nov  9 21:03:57 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 20:03:57 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415563437.77.0.908494924407.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[I will prepare a 3.5 patch for this.]

Thanks, I will review when you're done.

[How about frozenset([...]) to frozenset({...})? ]

Yes, the frozenset() examples should change to match the actual repr:

   >>> frozenset([10, 20, 30])
   frozenset({10, 20, 30})

----------

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

From report at bugs.python.org  Sun Nov  9 21:17:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 20:17:49 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415564269.36.0.990015097984.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Isn't such changes considered code churn?]

This sort of thing is always a judgment call.  The patch will affect very few lines of code, give a little speed-up, and make the code easier to read.  In the case of the docs, it is almost always worthwhile to update to the current, idiomatic form.  Also, the set literal case is special because it has built-in language support, possible peephole optimizations, and there was a repr change as well.  That said, it is rarely a good idea to change tests because we don't have tests for tests and because the end-user will never see any value.

On the balance, I think this one is a reasonable thing to do, but I would show a great deal more hesitancy for a "a huge patch which makes Python sources to use more modern idioms."

----------

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

From report at bugs.python.org  Sun Nov  9 21:22:55 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 20:22:55 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415564575.7.0.358075116114.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My timing for set((1,2,3)) is .29, faster than for set([1,2,3]) (.42) but still slower than for {1,2,3} (.16).  So I will change such instances also.

The same timing for frozenset((1,2,3)) (.29) is faster than the best timing for frozenset({1,2,3}), (.36), so I will not change that unless discussed and agreed on.

----------

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

From report at bugs.python.org  Sun Nov  9 21:25:18 2014
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 09 Nov 2014 20:25:18 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415564718.02.0.40363522433.issue22827@psf.upfronthosting.co.za>


Matthias Klose added the comment:

The mock backport doesn't come with a license.  Please either include it in the file, or make it clear that the backport has the same license as python (?).

----------
nosy: +michael.foord

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

From report at bugs.python.org  Sun Nov  9 21:25:55 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 20:25:55 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415564755.8.0.063679641055.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

The backport is taken from Python 3.4 so it's the same license as everything else.

----------

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

From report at bugs.python.org  Sun Nov  9 21:26:21 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 09 Nov 2014 20:26:21 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415564781.29.0.957122686723.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

IOW it's literally Lib/unittest/mock.py from the 3.x series.

----------

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

From report at bugs.python.org  Sun Nov  9 21:37:29 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 20:37:29 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415565449.39.0.917267073538.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> The same timing for frozenset((1,2,3)) (.29) is faster than the best
> timing for frozenset({1,2,3}), (.36),

I don't see the tuple form used anywhere in the code.
The timing is a bit quicker for the tuple form because the peephole optimizer constant folds the tuple (use dis to see this).


> so I will not change that 
> unless discussed and agreed on.

Maybe, I should just make the patch.  It's becoming harder to talk about than to just fix.

----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Sun Nov  9 21:46:27 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 20:46:27 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415565987.48.0.141666617348.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, about your 'huge patch' to modernize code:

I am more positive than some because:

1) To me, a one-time gentile change is not 'churning'.

2) As we link to many, most, or even all python-coded stdlib modules (I think there is a proposal for 'all'), there is more benefit to using modern idioms.

On the other hand, 'huge' patches can be too much to discuss, justify, and review all at once.

Using {.. } for sets consistently is a nice-sized chunk to consider.  We can identify, discuss, and decide on each sub-case (I have identified 4 so far).  It has the additional benefit of being a performance enhancement.
---

'set((...' is used in distutils (which I will not change) and in many tests.  So that is not an issue.  'frozenset((' is used 5 times in regular module code.

----------

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

From report at bugs.python.org  Sun Nov  9 21:53:43 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 20:53:43 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415566423.81.0.975556071088.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching a patch.  Doesn't change tests for the reasons mentioned above.  
Leaves idle, 2-to-3, and mocking for their respective module maintainers to deal with holistically (as part of their routine maintenance).

----------
keywords: +patch
Added file: http://bugs.python.org/file37159/set_literal.patch

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

From report at bugs.python.org  Sun Nov  9 22:02:47 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 21:02:47 +0000
Subject: [issue22830] functools.cmp_to_key: misleading key function description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <1415566967.1.0.482204679648.issue22830@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree with your comments and proposed changes and will leave this to you.

----------

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

From report at bugs.python.org  Sun Nov  9 22:05:54 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 21:05:54 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415567154.7.0.326922235571.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Okay, I missed the frozenset(( examples in my search.  There are all in one-time set-up code.  Attaching a patch for them as well.

----------
Added file: http://bugs.python.org/file37160/more_set_literals.patch

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

From report at bugs.python.org  Sun Nov  9 22:18:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Nov 2014 21:18:06 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415567886.69.0.491330120732.issue22823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You have missed Parser/asdl.py and Tools/clinic/clinic.py.

----------
Added file: http://bugs.python.org/file37161/set_literal_2.patch

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

From report at bugs.python.org  Sun Nov  9 22:37:47 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 21:37:47 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415569067.06.0.605612303761.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, as I said before, please omit idlelib/CodeContext.

You both skipped reprlib.py.  Should it be changed to produce the standard repr() result? The existing lines:

F:\Python\dev\35\lib\reprlib.py: 91:         return self._repr_iterable(x, level, 'set([', '])', self.maxset)
F:\Python\dev\35\lib\reprlib.py: 95:         return self._repr_iterable(x, level, 'frozenset([', '])',

If it is, its tests will have to be changed too.

----------
keywords:  -patch

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

From report at bugs.python.org  Sun Nov  9 22:41:08 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 21:41:08 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415569268.59.0.942429231967.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Hmm, didn't look at those parts of the tree.  I'll change the one-line in Parser and leave the little atrocities in clinic.py for Larry to fix :-)

Reprlib was skipped intentionally.  There is a separate tracker item for it.  http://bugs.python.org/issue22824

----------

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

From report at bugs.python.org  Sun Nov  9 22:48:52 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 21:48:52 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415569732.25.0.331312875656.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If there are no objections, I would like to apply my two patches (plus the one-line asdl.py change) and leave the rest to the discretion the module maintainers (mock, code context, clinic, and 2-to-3).

----------

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

From report at bugs.python.org  Sun Nov  9 23:39:55 2014
From: report at bugs.python.org (Akira Li)
Date: Sun, 09 Nov 2014 22:39:55 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1415572795.9.0.484215902388.issue22791@psf.upfronthosting.co.za>


Akira Li added the comment:

I agree the documentation should nudge towards aware
datetime objects.

I've attached a documentation patch as an example.

----------
keywords: +patch
Added file: http://bugs.python.org/file37162/issue22791-utcfromtimestamp-aware.diff

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

From report at bugs.python.org  Mon Nov 10 00:56:41 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Nov 2014 23:56:41 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <20141109235639.108365.99619@psf.io>


Roundup Robot added the comment:

New changeset 4480506137ed by Raymond Hettinger in branch 'default':
Issue #22823: Use set literals instead of creating a set from a list
https://hg.python.org/cpython/rev/4480506137ed

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

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

From report at bugs.python.org  Mon Nov 10 00:59:16 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 23:59:16 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415577556.7.0.945306068608.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Larry, would you care to apply or approve Serhiy's updates to clinic.py?

----------
assignee: rhettinger -> larry
nosy: +larry

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

From report at bugs.python.org  Mon Nov 10 01:12:23 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 00:12:23 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415578343.62.0.0382896375826.issue22824@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here's a patch to use set literals and frozenset({'a'}) in reprlib.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37163/issue22824.diff

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

From report at bugs.python.org  Mon Nov 10 01:21:27 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Nov 2014 00:21:27 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415578887.74.0.81454949642.issue22824@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

That looks great.  Go ahead an apply (with a MISC/NEWS entry and an update to the example on line 22 of Docs/tutorial/stdlib2.rst).

----------
assignee:  -> berker.peksag

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

From report at bugs.python.org  Mon Nov 10 01:29:27 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 00:29:27 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415579367.1.0.326433024996.issue22824@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the review, Raymond. Patch updated:

- Updated the documentation
- Added two test cases for set literals
- Replaced old run_unittest calls with ``unittest.main()``

----------
Added file: http://bugs.python.org/file37164/issue22824_v2.diff

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

From report at bugs.python.org  Mon Nov 10 02:10:31 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 01:10:31 +0000
Subject: [issue22830] functools.cmp_to_key: misleading key function description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <20141110011027.113478.19574@psf.io>


Roundup Robot added the comment:

New changeset dbe1744ec62e by Raymond Hettinger in branch '2.7':
Issue 22830:  Clarify docs for functools.cmp_to_key().
https://hg.python.org/cpython/rev/dbe1744ec62e

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

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

From report at bugs.python.org  Mon Nov 10 02:21:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 01:21:44 +0000
Subject: [issue22830] functools.cmp_to_key: misleading key function description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <20141110012128.719.65720@psf.io>


Roundup Robot added the comment:

New changeset 63274cf1b40d by Raymond Hettinger in branch '3.4':
Issue 22830:  Clarify docs for functools.cmp_to_key().
https://hg.python.org/cpython/rev/63274cf1b40d

----------

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

From report at bugs.python.org  Mon Nov 10 02:23:02 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 01:23:02 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <20141110012259.707.490@psf.io>


Roundup Robot added the comment:

New changeset 6e6532d313a1 by Brett Cannon in branch 'default':
Issue 20152, 22821: Port the fcntl module to Argument Clinic.
https://hg.python.org/cpython/rev/6e6532d313a1

----------

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

From report at bugs.python.org  Mon Nov 10 02:25:30 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Nov 2014 01:25:30 +0000
Subject: [issue22821] Argument of wrong type is passed to fcntl()
In-Reply-To: <1415458478.26.0.185263171518.issue22821@psf.upfronthosting.co.za>
Message-ID: <1415582730.98.0.736682457269.issue22821@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Fixed in 3.5 as part of 6e6532d313a1 as it was easier to integrate it as part of the Clinic patch.

----------
stage: patch review -> commit review
versions:  -Python 3.5

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

From report at bugs.python.org  Mon Nov 10 02:26:34 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Nov 2014 01:26:34 +0000
Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za>
Message-ID: <1415582794.41.0.337715217444.issue20152@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Finally finished!

I am never trusting Larry to count anything ever again. ;)

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

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

From report at bugs.python.org  Mon Nov 10 02:27:48 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Nov 2014 01:27:48 +0000
Subject: [issue22830] functools.cmp_to_key: misleading key function description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <1415582868.77.0.587779784593.issue22830@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/issue22830>
_______________________________________

From report at bugs.python.org  Mon Nov 10 02:32:31 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Nov 2014 01:32:31 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
Message-ID: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://bugs.python.org/review/20152/ is filled with various suggestions from Serhiy on how to update the function parameters in the fcntl module to more closely match what is in the man pages. This should be fully backwards-compatible as the parameters are positional-only. It should be easy as the code doesn't need to change thanks to Argument Clinic. Trick will be updating both the code and the docs.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 230931
nosy: brett.cannon, docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Tweak parameter names for fcntl module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 10 03:42:40 2014
From: report at bugs.python.org (py.user)
Date: Mon, 10 Nov 2014 02:42:40 +0000
Subject: [issue22833] The decode_header() function decodes raw part to bytes
 or str, depending on encoded part
Message-ID: <1415587360.95.0.777626227555.issue22833@psf.upfronthosting.co.za>


New submission from py.user:

It depends on encoded part in the header, what email.header.decode_header() returns.
If the header has both raw part and encoded part, the function returns (bytes, None) for the raw part. But if the header has only raw part, the function returns (str, None) for it.

>>> import email.header
>>> 
>>> s = 'abc=?koi8-r?q?\xc1\xc2\xd7?='
>>> email.header.decode_header(s)
[(b'abc', None), (b'\xc1\xc2\xd7', 'koi8-r')]
>>> 
>>> s = 'abc'
>>> email.header.decode_header(s)
[('abc', None)]
>>>

There should be (bytes, None) for both cases.

----------
components: Library (Lib), email
messages: 230932
nosy: barry, py.user, r.david.murray
priority: normal
severity: normal
status: open
title: The decode_header() function decodes raw part to bytes or str, depending on encoded part
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 10 03:42:56 2014
From: report at bugs.python.org (py.user)
Date: Mon, 10 Nov 2014 02:42:56 +0000
Subject: [issue22833] The decode_header() function decodes raw part to bytes
 or str, depending on encoded part
In-Reply-To: <1415587360.95.0.777626227555.issue22833@psf.upfronthosting.co.za>
Message-ID: <1415587376.12.0.48301205739.issue22833@psf.upfronthosting.co.za>


Changes by py.user <bugzilla-mail-box at yandex.ru>:


----------
type:  -> behavior

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

From report at bugs.python.org  Mon Nov 10 04:56:59 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 10 Nov 2014 03:56:59 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
Message-ID: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>


New submission from Martin Panter:

I encountered this when I added a unit test case that invoked os.chdir() with a temporary directory on Linux. After the directory was removed, some of the subsequent test cases failed, although I don?t think they should depend on a particular CWD.

I suspect the main problem might be code that is trying to dynamically import modules, and the interpreter is trying to search for modules in the current directory. I would expect it to happily go on to the other standard module directories or raise ImportError, just like if the current directory is valid but empty, or an nonexistent directory is in the module search path list.

Code to set up missing CWD:

import os
from tempfile import TemporaryDirectory
with TemporaryDirectory() as dir:
    os.chdir(dir)

Quick recovery:

os.chdir("/")

Examples of failures:

>>> "\N{COPYRIGHT SIGN}"
  File "<stdin>", line 1
SyntaxError: (unicode error) \N escapes not supported (can't load unicodedata module)
>>> datetime.strptime("", "")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2222, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2164, in _find_spec
  File "<frozen importlib._bootstrap>", line 1940, in find_spec
  File "<frozen importlib._bootstrap>", line 1911, in _get_spec
  File "<frozen importlib._bootstrap>", line 1879, in _path_importer_cache
FileNotFoundError: [Errno 2] No such file or directory
>>> HTTPConnection("localhost").request("GET", "/")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/http/client.py", line 1090, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.4/http/client.py", line 1128, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.4/http/client.py", line 1086, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.4/http/client.py", line 924, in _send_output
    self.send(msg)
  File "/usr/lib/python3.4/http/client.py", line 859, in send
    self.connect()
  File "/usr/lib/python3.4/http/client.py", line 836, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python3.4/socket.py", line 491, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/lib/python3.4/socket.py", line 530, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
  File "/usr/lib/python3.4/encodings/__init__.py", line 98, in search_function
    level=0)
  File "/usr/lib/python3.4/encodings/idna.py", line 3, in <module>
    import stringprep, re, codecs
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2222, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2164, in _find_spec
  File "<frozen importlib._bootstrap>", line 1940, in find_spec
  File "<frozen importlib._bootstrap>", line 1911, in _get_spec
  File "<frozen importlib._bootstrap>", line 1879, in _path_importer_cache
FileNotFoundError: [Errno 2] No such file or directory

>>> from datetime import datetime
>>> from http.client import HTTPConnection
These two also generate the FileNotFoundError

My workaround is to add this to my test case:
self.addCleanup(os.chdir, os.getcwd())

----------
components: Interpreter Core
messages: 230933
nosy: vadmium
priority: normal
severity: normal
status: open
title: Unexpected FileNotFoundError when current directory is removed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 10 06:57:07 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Mon, 10 Nov 2014 05:57:07 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
Message-ID: <1415599026.97.0.589284650072.issue22835@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

I am trying to do an authenticated-SSL request to an Nginx server using *requests*, which wraps urllib2/httplib. It's worked perfectly for months until Friday on my local system (Mac 10.9.5), and there have been no upgrades/patches. 

My Python 2.7.6 client fails when connecting to Nginx, locally. I get a 400, with this:

<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx/1.4.6 (Ubuntu)</center>
</body>
</html>

This is an example that uses urllib2/httplib, directly:

import urllib2
import httplib

cert_filepath = '/var/lib/rt_data/ssl/rt.crt.pem'
key_filepath = '/var/lib/rt_data/ssl/rt.private_key.pem'

url = 'https://deploy_api.local:8443/auth/admin/1/hosts'


class HTTPSClientAuthHandler(urllib2.HTTPSHandler):
    """Wrapper to allow for authenticated SSL connections."""

    def __init__(self, key, cert):
        urllib2.HTTPSHandler.__init__(self)
        self.key = key
        self.cert = cert

    def https_open(self, req):
        # Rather than pass in a reference to a connection class, we pass in
        # a reference to a function which, for all intents and purposes,
        # will behave as a constructor
        return self.do_open(self.getConnection, req)

    def getConnection(self, host, timeout=300):
        return httplib.HTTPSConnection(host, key_file=self.key, cert_file=self.cert)

opener = urllib2.build_opener(HTTPSClientAuthHandler(key_filepath, cert_filepath))
response = opener.open(url)

response_data = response.read()
print(response_data)

These are the factors:

- It works when connecting to the remote server. Both local and remote are Nginx with similar configs.
- cURL works perfectly:

  curl -s -v -X GET -k --cert /var/lib/rt_data/ssl/rt.crt.pem --key /var/lib/rt_data/ssl/rt.private_key.pem https://server.local:8443/auth/admin/1/hosts

- I've tried under Vagrant with Ubuntu 12.04 (2.7.3) and 14.04 (2.7.6). No difference.
- It works with Python 3.4 on the local system. This only has only affected 2.7 very suddenly.

Due to the error-message above, it seems like there's a break down in sending the certificate/key.

I have no idea what's going on, and this has caused me a fair amount of distress. Can you provide me a direction?

----------
components: Library (Lib)
messages: 230934
nosy: Dustin.Oprea
priority: normal
severity: normal
status: open
title: urllib2/httplib is rendering 400s for every authenticated-SSL request, suddenly
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 10 07:31:01 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 06:31:01 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <20141110063041.113466.5478@psf.io>


Roundup Robot added the comment:

New changeset 147fda13bec8 by Raymond Hettinger in branch 'default':
Issue #22824:  Updated reprlib output format for sets to use set literals.
https://hg.python.org/cpython/rev/147fda13bec8

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

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

From report at bugs.python.org  Mon Nov 10 07:31:33 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Nov 2014 06:31:33 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415601093.57.0.0353736903649.issue22824@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch.

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

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

From report at bugs.python.org  Mon Nov 10 08:08:06 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 07:08:06 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415603286.37.0.916459220756.issue22824@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/issue22824>
_______________________________________

From report at bugs.python.org  Mon Nov 10 08:12:36 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 07:12:36 +0000
Subject: [issue17554] Compact output for regrtest
In-Reply-To: <1364331735.49.0.0652208703783.issue17554@psf.upfronthosting.co.za>
Message-ID: <1415603556.23.0.498060402158.issue17554@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue17554-urlfetch.diff LGTM.

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

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

From report at bugs.python.org  Mon Nov 10 08:12:49 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Nov 2014 07:12:49 +0000
Subject: [issue22829] Add --prompt option to venv
In-Reply-To: <1415555957.14.0.777244809784.issue22829@psf.upfronthosting.co.za>
Message-ID: <1415603569.18.0.513127679964.issue22829@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ncoghlan, vinay.sajip

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

From report at bugs.python.org  Mon Nov 10 08:41:35 2014
From: report at bugs.python.org (sbspider)
Date: Mon, 10 Nov 2014 07:41:35 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1415605295.25.0.678499409994.issue22813@psf.upfronthosting.co.za>


sbspider added the comment:

And what do you think would it be useful for? I mean, it shouldn't be too hard to implement, a couple of hours at most, but I can't seem to see what would be the purpose. However, if you think that there is enough of a use case behind it, then I would be happy to have a crack at it :).

----------

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

From report at bugs.python.org  Mon Nov 10 08:56:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 07:56:43 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <20141110075635.108389.84593@psf.io>


Roundup Robot added the comment:

New changeset 58a871227e5b by Berker Peksag in branch 'default':
Issue #21650: Add an `--sort-keys` option to json.tool CLI.
https://hg.python.org/cpython/rev/58a871227e5b

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

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

From report at bugs.python.org  Mon Nov 10 08:58:05 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 07:58:05 +0000
Subject: [issue21650] add json.tool option to avoid alphabetic sort of fields
In-Reply-To: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>
Message-ID: <1415606285.56.0.969592644171.issue21650@psf.upfronthosting.co.za>


Berker Peksag 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/issue21650>
_______________________________________

From report at bugs.python.org  Mon Nov 10 09:23:23 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 08:23:23 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <1410970188.53.0.105353417029.issue22434@psf.upfronthosting.co.za>
Message-ID: <20141110082317.699.13395@psf.io>


Roundup Robot added the comment:

New changeset fc7dbba57869 by Serhiy Storchaka in branch 'default':
Issue #22434: Constants in sre_constants are now named constants (enum-like).
https://hg.python.org/cpython/rev/fc7dbba57869

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

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

From report at bugs.python.org  Mon Nov 10 09:33:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 08:33:41 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <1415608421.55.0.928742208209.issue22824@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The repr of empty array() should be fixed too.

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file37165/issue22824_3.diff

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

From report at bugs.python.org  Mon Nov 10 09:48:05 2014
From: report at bugs.python.org (Wolfgang Langner)
Date: Mon, 10 Nov 2014 08:48:05 +0000
Subject: [issue21301] pathlib missing Path.expandvars(env=os.environ)
In-Reply-To: <1397849465.53.0.177138390921.issue21301@psf.upfronthosting.co.za>
Message-ID: <1415609285.45.0.37656891864.issue21301@psf.upfronthosting.co.za>


Wolfgang Langner added the comment:

expandvars(), and expanduser() is part of os.path.

Boot functions are needed for path objects and very useful.
And yes it is a simple string substitution but very common.

----------
nosy: +tds333

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

From report at bugs.python.org  Mon Nov 10 09:53:23 2014
From: report at bugs.python.org (Wolfgang Langner)
Date: Mon, 10 Nov 2014 08:53:23 +0000
Subject: [issue19767] pathlib: iterfiles() and iterdirs()
In-Reply-To: <1385375147.52.0.820545347485.issue19767@psf.upfronthosting.co.za>
Message-ID: <1415609603.2.0.66735790191.issue19767@psf.upfronthosting.co.za>


Wolfgang Langner added the comment:

Why not implement this pattern with

def dirs(pattern)
and 
def files(pattern)

where both are a simple shortcut for
(p for p in mypath.glob(pattern) if p is_file())
or is_dir()

?

----------
nosy: +tds333

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

From report at bugs.python.org  Mon Nov 10 10:29:54 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 09:29:54 +0000
Subject: [issue22821] Argument of wrong type is passed to fcntl()
In-Reply-To: <1415458478.26.0.185263171518.issue22821@psf.upfronthosting.co.za>
Message-ID: <20141110092951.108093.19752@psf.io>


Roundup Robot added the comment:

New changeset 61e99438c237 by Serhiy Storchaka in branch '2.7':
Issue #22821: Fixed fcntl() with integer argument on 64-bit big-endian
https://hg.python.org/cpython/rev/61e99438c237

New changeset 45e8aed69767 by Serhiy Storchaka in branch '3.4':
Issue #22821: Fixed fcntl() with integer argument on 64-bit big-endian
https://hg.python.org/cpython/rev/45e8aed69767

New changeset 2d203a0b7908 by Serhiy Storchaka in branch 'default':
Issue #22821: Fixed fcntl() with integer argument on 64-bit big-endian
https://hg.python.org/cpython/rev/2d203a0b7908

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

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

From report at bugs.python.org  Mon Nov 10 10:31:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 09:31:58 +0000
Subject: [issue22821] Argument of wrong type is passed to fcntl()
In-Reply-To: <1415582730.98.0.736682457269.issue22821@psf.upfronthosting.co.za>
Message-ID: <4768917.HceDDsXM8H@raxxla>


Serhiy Storchaka added the comment:

> Fixed in 3.5 as part of 6e6532d313a1 as it was easier to integrate it as
> part of the Clinic patch.

6e6532d313a1 has introduced other bug ("l" was parsed to int). Changed to "I" 
for reasons described in the comment in fcntl_ioctl_impl().

----------

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

From report at bugs.python.org  Mon Nov 10 10:33:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 09:33:08 +0000
Subject: [issue22821] Argument of wrong type is passed to fcntl()
In-Reply-To: <1415458478.26.0.185263171518.issue22821@psf.upfronthosting.co.za>
Message-ID: <1415611988.2.0.161902124104.issue22821@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.5

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

From report at bugs.python.org  Mon Nov 10 10:45:31 2014
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 10 Nov 2014 09:45:31 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1415612731.04.0.437985423457.issue22490@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The environment variable itself cannot be removed from CPython, it is necessary to implement the correct behavior of pyvenv with framework builds of Python.

That said, I do think that the environment variable should be unset as soon as possible in the CPython startup code to avoid accidentally affecting other interpreters.

----------

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

From report at bugs.python.org  Mon Nov 10 10:49:59 2014
From: report at bugs.python.org (Michael Foord)
Date: Mon, 10 Nov 2014 09:49:59 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1415612999.88.0.222767007255.issue22813@psf.upfronthosting.co.za>


Michael Foord added the comment:

The point is that it is easy to have unintentional dependencies between tests. Test a sets up some state that test b relies on. This means that test b passes, so long as test a has already run. This is bad, tests should be isolated - it also means you can break test b when you change test a. Randomising test run order means you discover these unintentional dependencies earlier.

With test randomisation you ideally need the seed to be displayed as part of the test run, and you need to be able to run with a particular seed. This enables you to reproduce failures, or odd results, from any particular test run.

----------

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

From report at bugs.python.org  Mon Nov 10 10:51:23 2014
From: report at bugs.python.org (Michael Foord)
Date: Mon, 10 Nov 2014 09:51:23 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415613083.3.0.890438775791.issue22827@psf.upfronthosting.co.za>


Michael Foord added the comment:

mock in the Python standard library is licensed under the PSF license.

----------

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

From report at bugs.python.org  Mon Nov 10 11:22:49 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 10:22:49 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
Message-ID: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

When there's an unraisable exception (e.g. in __del__), and there's an exception in __repr__ as well, PyErr_WriteUnraisable returns after writing "Exception ignored in:" immediately.

I'd expect it to fall back to the default __repr__ instead.

See the attached example script.

Output with 3.4:

=== Obj ===
Exception ignored in: <bound method Obj.__del__ of <__main__.Obj object at 0x7fd842deb4a8>>
Traceback (most recent call last):
  File "test.py", line 4, in __del__
    raise Exception('in del')
Exception: in del
=== BrokenObj ===
Exception ignored in: (no newline)

Output with 2.7:

=== Obj ===
Exception Exception: Exception('in del',) in <bound method Obj.__del__ of <__main__.Obj object at 0x7fa824dbfa50>> ignored
=== BrokenObj ===
Exception Exception: Exception('in del',) in  ignored

The output with 2.7 is a bit more useful, but still confusing.

----------
components: Interpreter Core
files: repr_exception.py
messages: 230950
nosy: The Compiler
priority: normal
severity: normal
status: open
title: Broken "Exception ignored in:" message on exceptions in __repr__
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37166/repr_exception.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Mon Nov 10 11:47:07 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 10:47:07 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
 data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <20141110104703.108383.46444@psf.io>


Roundup Robot added the comment:

New changeset 4caa695af94c by Serhiy Storchaka in branch '2.7':
Issue #12728: Different Unicode characters having the same uppercase but
https://hg.python.org/cpython/rev/4caa695af94c

New changeset 47b3084dd6aa by Serhiy Storchaka in branch '3.4':
Issue #12728: Different Unicode characters having the same uppercase but
https://hg.python.org/cpython/rev/47b3084dd6aa

New changeset 09ec09cfe539 by Serhiy Storchaka in branch 'default':
Issue #12728: Different Unicode characters having the same uppercase but
https://hg.python.org/cpython/rev/09ec09cfe539

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12728>
_______________________________________

From report at bugs.python.org  Mon Nov 10 11:52:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 10:52:04 +0000
Subject: [issue12728] Python re lib fails case insensitive matches on Unicode
 data
In-Reply-To: <1313088501.39.0.822875623158.issue12728@psf.upfronthosting.co.za>
Message-ID: <1415616724.29.0.0470661822018.issue12728@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This solution (with hardcoded table of equivalent lowercases) is temporary. In future re engine will be changed to support correct caseless matching of different lowercase forms internally.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12728>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:09:48 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 10 Nov 2014 11:09:48 +0000
Subject: [issue22578] Add additional attributes to re.error
In-Reply-To: <1412772310.32.0.0247834995037.issue22578@psf.upfronthosting.co.za>
Message-ID: <1415617788.13.0.387170830545.issue22578@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22578>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:12:29 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 11:12:29 +0000
Subject: [issue22837] getpass returns garbage when typing tilde on Windows
 with deadkeys
Message-ID: <1415617949.23.0.398413273568.issue22837@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

When using getpass.getpass() on Windows and typing a tilde (~) with a layout with dead keys (e.g. Swiss German), one would typically type "~ " to get a single tilde.

However, this returns '\x00\x83~' with getpass. It seems this is what msvcrt.getch() returns.

Microsofts documentation at http://msdn.microsoft.com/en-us/library/aa297934(v=vs.60).aspx only says "When reading a function key or an arrow key, _getch and _getche must be called twice; the first call returns 0 or 0xE0, and the second call returns the actual key code." which doesn't really apply to this.

It seems to work fine with other dead keys like ` or ^.

Unless someone knows more about what's happening here I'd suggest replacing '\x00\x83~' by '~' in getpass.

----------
components: Library (Lib)
messages: 230954
nosy: The Compiler, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: getpass returns garbage when typing tilde on Windows with deadkeys
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22837>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:17:39 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 10 Nov 2014 11:17:39 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1415618259.95.0.742861248514.issue22836@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is one that has often bugged me. When your repr() implementation is broken, it is quite confusing figuring out what is going wrong. Falling back to object.__repr__() is one option, however I would probably be happy with a simple ?exception in repr()? message, and a proper newline.

Another way that I have come across this is:

$ python -c 'import sys; sys.stdout.detach()'
Exception ignored in: [no newline]

The workaround there is to set sys.stdout = None. In that case I think repr(sys.stdout) is trying to say ?ValueError: underlying buffer has been detached?.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:19:22 2014
From: report at bugs.python.org (Robert Muil)
Date: Mon, 10 Nov 2014 11:19:22 +0000
Subject: [issue21724] resetwarnings doesn't reset warnings registry
In-Reply-To: <1402503104.19.0.836333157517.issue21724@psf.upfronthosting.co.za>
Message-ID: <1415618362.07.0.739893367801.issue21724@psf.upfronthosting.co.za>


Changes by Robert Muil <robertmuil at gmail.com>:


----------
nosy: +robertmuil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21724>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:21:35 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 11:21:35 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1415618495.63.0.211887541998.issue22836@psf.upfronthosting.co.za>


Changes by Florian Bruhin <python.org at the-compiler.org>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:23:45 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 11:23:45 +0000
Subject: [issue22837] getpass returns garbage when typing tilde on Windows
 with deadkeys
In-Reply-To: <1415617949.23.0.398413273568.issue22837@psf.upfronthosting.co.za>
Message-ID: <1415618625.42.0.81481394297.issue22837@psf.upfronthosting.co.za>


Changes by Florian Bruhin <python.org at the-compiler.org>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22837>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:51:17 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 11:51:17 +0000
Subject: [issue22578] Add additional attributes to re.error
In-Reply-To: <1412772310.32.0.0247834995037.issue22578@psf.upfronthosting.co.za>
Message-ID: <20141110115106.85210.50032@psf.io>


Roundup Robot added the comment:

New changeset 292c4d853662 by Serhiy Storchaka in branch 'default':
Issue #22578: Added attributes to the re.error class.
https://hg.python.org/cpython/rev/292c4d853662

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22578>
_______________________________________

From report at bugs.python.org  Mon Nov 10 12:59:20 2014
From: report at bugs.python.org (Michael Foord)
Date: Mon, 10 Nov 2014 11:59:20 +0000
Subject: [issue22431] Change format of test runner output
In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za>
Message-ID: <1415620760.97.0.956792772425.issue22431@psf.upfronthosting.co.za>


Michael Foord added the comment:

I agree with Robert that the text output of the default runner should not be considered a part of the "api" that we make backwards compatible guarantees about. People who want to customise that should be customising the text runner/result. (Unfortunately it requires tinkering with both at the moment.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22431>
_______________________________________

From report at bugs.python.org  Mon Nov 10 13:35:29 2014
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Nov 2014 12:35:29 +0000
Subject: [issue22198] Odd floor-division corner case
In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za>
Message-ID: <1415622929.91.0.695036410766.issue22198@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

ping, could someone please review the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22198>
_______________________________________

From report at bugs.python.org  Mon Nov 10 13:35:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 12:35:51 +0000
Subject: [issue22578] Add additional attributes to re.error
In-Reply-To: <1412772310.32.0.0247834995037.issue22578@psf.upfronthosting.co.za>
Message-ID: <20141110123544.113460.87827@psf.io>


Roundup Robot added the comment:

New changeset 07f082b200a7 by Serhiy Storchaka in branch 'default':
Fixed IDLE tests after changing re error messages (issue #22578).
https://hg.python.org/cpython/rev/07f082b200a7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22578>
_______________________________________

From report at bugs.python.org  Mon Nov 10 13:43:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 12:43:24 +0000
Subject: [issue22578] Add additional attributes to re.error
In-Reply-To: <1412772310.32.0.0247834995037.issue22578@psf.upfronthosting.co.za>
Message-ID: <1415623404.82.0.586176161174.issue22578@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ezio for your review.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22578>
_______________________________________

From report at bugs.python.org  Mon Nov 10 15:06:02 2014
From: report at bugs.python.org (Florian Bruhin)
Date: Mon, 10 Nov 2014 14:06:02 +0000
Subject: [issue22837] getpass returns garbage when typing tilde on Windows
 with deadkeys
In-Reply-To: <1415617949.23.0.398413273568.issue22837@psf.upfronthosting.co.za>
Message-ID: <1415628362.56.0.00949770295779.issue22837@psf.upfronthosting.co.za>


Florian Bruhin added the comment:

Maybe this is related: U+0083 is the "no break here" char:

http://www.fileformat.info/info/unicode/char/0083/index.htm
http://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_set

>From wikipedia: "Follows the graphic character that is not to be broken."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22837>
_______________________________________

From report at bugs.python.org  Mon Nov 10 15:50:46 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Nov 2014 14:50:46 +0000
Subject: [issue22833] The decode_header() function decodes raw part to bytes
 or str, depending on encoded part
In-Reply-To: <1415587360.95.0.777626227555.issue22833@psf.upfronthosting.co.za>
Message-ID: <1415631046.02.0.625726872506.issue22833@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a duplicate of issue 6302.  Re-reading that issue (again), I'm not quite sure why we didn't fix it, but it may be too late to fix it now for backward compatibility reasons.

Since that issue strayed off into other topics, I'm going to leave this one open to consider whether or not we can/should fix this.  The new email API does avoid this problem, though.  Is there a reason you are choosing not to use the new API?

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22833>
_______________________________________

From report at bugs.python.org  Mon Nov 10 16:02:48 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Nov 2014 15:02:48 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1415631768.22.0.723285565606.issue22834@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks like importlib doesn't handle the case of a directory on the path being deleted?  If so, I'm surprised this hasn't been reported before.

----------
nosy: +brett.cannon, eric.snow, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Mon Nov 10 16:46:50 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Nov 2014 15:46:50 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <1415599026.97.0.589284650072.issue22835@psf.upfronthosting.co.za>
Message-ID: <1415634410.68.0.204285014528.issue22835@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you haven't updated Python, then it is hard to see how this could be a python bug.  Not impossible, but you'll have to narrow down the problem before you'd be able to demonstrate it as a python bug, I'm afraid.

If you want help diagnosing this, you might try the python-list mailing list, though it sounds like a nginx forum might be equally useful at this stage (determining what exactly is going on protocol wise that is different between your two test cases).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Mon Nov 10 16:49:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Nov 2014 15:49:38 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1415634578.03.0.162074807415.issue22836@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Mon Nov 10 17:50:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 16:50:24 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1415638224.53.0.481154466377.issue22364@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which makes re error messages match regex. It doesn't look to me that all these changes are enhancements.

----------
keywords: +patch
Added file: http://bugs.python.org/file37167/re_errors_regex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22364>
_______________________________________

From report at bugs.python.org  Mon Nov 10 18:10:56 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 17:10:56 +0000
Subject: [issue22838] Convert re tests to unittest
Message-ID: <1415639456.54.0.317814729132.issue22838@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Current re tests consists of two parts. One part use unittest and other part import test cases from Lib/test/re_tests.py, checks conditions and prints messages to stdout if they are false.

Proposed patch converts all test_re to using unittest.

----------
assignee: serhiy.storchaka
components: Regular Expressions, Tests
files: re_tests.patch
keywords: patch
messages: 230966
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Convert re tests to unittest
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37168/re_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22838>
_______________________________________

From report at bugs.python.org  Mon Nov 10 18:19:07 2014
From: report at bugs.python.org (=?utf-8?q?Domen_Ko=C5=BEar?=)
Date: Mon, 10 Nov 2014 17:19:07 +0000
Subject: [issue11907] SysLogHandler can't send long messages
In-Reply-To: <1303480338.6.0.255798757577.issue11907@psf.upfronthosting.co.za>
Message-ID: <1415639947.1.0.105185771136.issue11907@psf.upfronthosting.co.za>


Domen Ko?ar added the comment:

Note: same bug is relevant to DatagramHandler since it uses UDP transport.

----------
nosy: +iElectric

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11907>
_______________________________________

From report at bugs.python.org  Mon Nov 10 18:30:42 2014
From: report at bugs.python.org (Jonathan Sharpe)
Date: Mon, 10 Nov 2014 17:30:42 +0000
Subject: [issue22839] Incorrect link to statistics in tracemalloc documentation
Message-ID: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>


New submission from Jonathan Sharpe:

The link to "statistics" in the documentation for tracemalloc.Snapshot.compare_to (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Snapshot.compare_to) should be to the statistics method (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Snapshot.statistics), per the description, not to the statistics module (https://docs.python.org/3/library/statistics.html#module-statistics), where it currently points.

----------
assignee: docs at python
components: Documentation
messages: 230968
nosy: docs at python, jonrsharpe
priority: normal
severity: normal
status: open
title: Incorrect link to statistics in tracemalloc documentation
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22839>
_______________________________________

From report at bugs.python.org  Mon Nov 10 19:44:54 2014
From: report at bugs.python.org (pmoody)
Date: Mon, 10 Nov 2014 18:44:54 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415645094.96.0.844485940448.issue22800@psf.upfronthosting.co.za>


pmoody added the comment:

> # We only support CIDR for IPv6, because expanded netmasks are not
> # standard notation.

Yes, that's correct. I can double check this, but when I wrote ipaddress, I had yet to encounter a v6 netmask in anything other than cider notation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22800>
_______________________________________

From report at bugs.python.org  Mon Nov 10 19:52:43 2014
From: report at bugs.python.org (pmoody)
Date: Mon, 10 Nov 2014 18:52:43 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415645563.52.0.207723095252.issue22800@psf.upfronthosting.co.za>


pmoody added the comment:

Hey Chris,

What's the usecase for this? the netmask notation doesn't appear to be common for v6 (at all), so I'm hesitant to add support for this if it's just something like an academic exercise.

Cheers,
peter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22800>
_______________________________________

From report at bugs.python.org  Mon Nov 10 21:08:25 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Mon, 10 Nov 2014 20:08:25 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415650105.76.0.50386944461.issue22800@psf.upfronthosting.co.za>


Chris PeBenito added the comment:

I understand the resistance; I'm fine closing this as "won't implement", though this is not for academic use.  In a nutshell, my package currently has a set of classes to represent an SELinux policy, and the SELinux policy language represents networks with extended netmask[1].  I control the package, so I can change the internal representation from extended netmask to CIDR, so it's not the end of the world.

[1] example statement: nodecon ff00:: ff00:: system_u:object_r:multicast_node_t

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22800>
_______________________________________

From report at bugs.python.org  Mon Nov 10 21:50:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 20:50:34 +0000
Subject: [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1415652633.99.0.446291074214.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes remnants. It also corrects descriptions of parsing arguments format units.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37169/bytes_like.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22581>
_______________________________________

From report at bugs.python.org  Mon Nov 10 21:54:42 2014
From: report at bugs.python.org (pmoody)
Date: Mon, 10 Nov 2014 20:54:42 +0000
Subject: [issue22800] IPv6Network constructor sometimes does not recognize
 legitimate netmask
In-Reply-To: <1415201685.68.0.536631906861.issue22800@psf.upfronthosting.co.za>
Message-ID: <1415652882.3.0.513784925678.issue22800@psf.upfronthosting.co.za>


pmoody added the comment:

If you have the ability to use cidr, then closing this as wontfix is my preference. I've heard that there might be some network vendors that are starting support the mask notation for v6 addresses though, so this may end up getting implemented at some point in future anyway.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22800>
_______________________________________

From report at bugs.python.org  Mon Nov 10 22:15:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 21:15:43 +0000
Subject: [issue22839] Incorrect link to statistics in tracemalloc documentation
In-Reply-To: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>
Message-ID: <20141110211537.29008.29181@psf.io>


Roundup Robot added the comment:

New changeset 387bbada31e8 by Berker Peksag in branch '3.4':
Issue #22839: Fix Snapshot.statistics() link.
https://hg.python.org/cpython/rev/387bbada31e8

New changeset 524a004e93dd by Berker Peksag in branch 'default':
Issue #22839: Fix Snapshot.statistics() link.
https://hg.python.org/cpython/rev/524a004e93dd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22839>
_______________________________________

From report at bugs.python.org  Mon Nov 10 22:16:52 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 21:16:52 +0000
Subject: [issue22839] Incorrect link to statistics in tracemalloc documentation
In-Reply-To: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>
Message-ID: <1415654212.88.0.358126713241.issue22839@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the report, Jonathan.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22839>
_______________________________________

From report at bugs.python.org  Mon Nov 10 22:17:38 2014
From: report at bugs.python.org (py.user)
Date: Mon, 10 Nov 2014 21:17:38 +0000
Subject: [issue22833] The decode_header() function decodes raw part to bytes
 or str, depending on encoded part
In-Reply-To: <1415587360.95.0.777626227555.issue22833@psf.upfronthosting.co.za>
Message-ID: <1415654258.53.0.745648316941.issue22833@psf.upfronthosting.co.za>


py.user added the comment:

R. David Murray wrote:
"Is there a reason you are choosing not to use the new API?"

My program is for Python 3.x. I need to decode wild headers to pretty unicode strings. Now, I do it by decode_header() and try...except for AttributeError, since a unicode string has no .decode() method.

I don't know what is "new API", but I guess it's not compatible with Python 3.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22833>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:01:31 2014
From: report at bugs.python.org (Doug Gorley)
Date: Mon, 10 Nov 2014 22:01:31 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
Message-ID: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>


New submission from Doug Gorley:

strptime() is returning the wrong date if I try to parse today's date (2014-11-10) as a string with no separators, and if I ask strpdate() to look for nonexistent hour and minute fields.

>>> datetime.datetime.strptime('20141110', '%Y%m%d').isoformat()
'2014-11-10T00:00:00'
>>> datetime.datetime.strptime('20141110', '%Y%m%d%H%M').isoformat()
'2014-01-01T01:00:00'

----------
components: Library (Lib)
messages: 230977
nosy: dgorley
priority: normal
severity: normal
status: open
title: strpdate('20141110', '%Y%m%d%H%S') returns wrong date
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:21:36 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 10 Nov 2014 22:21:36 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <1415599026.97.0.589284650072.issue22835@psf.upfronthosting.co.za>
Message-ID: <1415658096.2.0.639977468704.issue22835@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

No upgrades on the server either?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:47:43 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Nov 2014 22:47:43 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415659663.32.0.713959930613.issue22840@psf.upfronthosting.co.za>


Ethan Furman added the comment:

What result did you expect?

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:53:18 2014
From: report at bugs.python.org (Doug Gorley)
Date: Mon, 10 Nov 2014 22:53:18 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415659998.88.0.0548353743536.issue22840@psf.upfronthosting.co.za>


Doug Gorley added the comment:

I expected the second call to strpdate() to throw an exception, because %Y consumed '2014', %m consumed '11', and %d consumed '10', leaving nothing for %H and %M to match.  That would be consistent with the first call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Mon Nov 10 23:59:23 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 10 Nov 2014 22:59:23 +0000
Subject: [issue22833] The decode_header() function decodes raw part to bytes
 or str, depending on encoded part
In-Reply-To: <1415587360.95.0.777626227555.issue22833@psf.upfronthosting.co.za>
Message-ID: <1415660363.64.0.237210240625.issue22833@psf.upfronthosting.co.za>


R. David Murray added the comment:

Certainly not with 3.0, but nobody in their right mind should be using that version any more :).

The new API for decoding headers is available as of Python 3.3, with additional new API features in 3.4.  See 

https://docs.python.org/3/library/email-examples.html#examples-using-the-provisional-api

for an example.  Note that although the API is 'provisional', I anticipate no non-trivial changes when it becomes final in 3.5.  (The only API change that has happened has been done such that you get warnings if you use it "wrong" in 3.4, and is in a relatively obscure method (is_attachment).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22833>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:27:17 2014
From: report at bugs.python.org (Aaron)
Date: Mon, 10 Nov 2014 23:27:17 +0000
Subject: [issue22719] os.path.isfile & os.path.exists bug in while loop
In-Reply-To: <1415078110.06.0.0662956257256.issue22719@psf.upfronthosting.co.za>
Message-ID: <CAD8ve4T-YvyzdDyu62CVT8+SxueFa4bvjL--8aDsC3D+1XL=ZQ@mail.gmail.com>


Aaron added the comment:

Python 3.3.0, Windows 7, both 64 bit.

Has it been resolved with the newer version, then?

On Mon, Nov 3, 2014 at 11:15 PM, Zachary Ware <report at bugs.python.org>
wrote:

>
> Zachary Ware added the comment:
>
> Aaron, what version of Python are you using on what version of Windows?
> Also, 32 or 64 bit on both?
>
> I can't reproduce this with any Python 3.3.6 or newer on 64-bit Windows
> 8.1.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22719>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22719>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:29:29 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Nov 2014 23:29:29 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415662169.73.0.00965106031925.issue22840@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The documentation certainly appears to say that %m, for example, will consume two digits, but it could just as easily be only for output (i.e. strftime).

I suspect this is simply a documentation issue as opposed to a bug, but let's see what the others think.

----------
nosy: +belopolsky, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:35:47 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Mon, 10 Nov 2014 23:35:47 +0000
Subject: [issue22841] Avoid to use coroutine with add_signal_handler()
Message-ID: <1415662547.93.0.350675273647.issue22841@psf.upfronthosting.co.za>


New submission from Ludovic Gasc:

Hi,

Victor Stinner suggested me during PyCON-FR to send you this:
It's a pico-patch to forbid a coroutine as parameter of add_signal_handler().

I've added a test for that, the patch is based on the latest commit in Tulip.

Thanks for your feedback.

Regards.

----------
components: asyncio
files: add_signal_handler_no_coroutines.patch
keywords: patch
messages: 230984
nosy: Ludovic.Gasc, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Avoid to use coroutine with add_signal_handler()
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37170/add_signal_handler_no_coroutines.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22841>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:46:31 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Nov 2014 23:46:31 +0000
Subject: [issue22719] os.path.isfile & os.path.exists bug in while loop
In-Reply-To: <CAD8ve4T-YvyzdDyu62CVT8+SxueFa4bvjL--8aDsC3D+1XL=ZQ@mail.gmail.com>
Message-ID: <CAKJDb-Mfi3QRph6FoRYnH+QrymreeHuGZtL=+zLc8cCQnCJ_hw@mail.gmail.com>


Zachary Ware added the comment:

I haven't built 3.3.0 again yet to try to reproduce with it, but there
have been enough bug and security fixes in the more recent 3.3
releases that I'd strongly advise updating on general principle and
seeing if this issue goes away.  If not to 3.4.2, at least to 3.3.5
(the last 3.3 version to have a Windows installer).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22719>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:50:28 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 10 Nov 2014 23:50:28 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415663428.14.0.899306623849.issue22840@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I have recently closed a similar issue (#5979) as "won't fix".  The winning argument there was that Python behavior was consistent with C.  How does C strptime behave in this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 00:58:49 2014
From: report at bugs.python.org (David Wilson)
Date: Mon, 10 Nov 2014 23:58:49 +0000
Subject: [issue22842] zipfile simultaneous open broken and/or needlessly(?)
 consumes unreasonable number of file descriptors
Message-ID: <1415663928.91.0.265332652866.issue22842@psf.upfronthosting.co.za>


New submission from David Wilson:

There is some really funky behaviour in the zipfile module, where, depending on whether zipfile.ZipFile() is passed a string filename or a file-like object, one of two things happens:

a) Given a file-like object, zipfile does not (since it cannot) consume excess file descriptors on each call to '.open()', however simultaneous calls to .open() the zip file's members (from the same thread) will produce file-like objects for each member that appear intertwingled in some unfortunate manner:

Traceback (most recent call last):
  File "my.py", line 23, in <module>
    b()
  File "my.py", line 18, in b
    m.readline()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 689, in readline
    return io.BufferedIOBase.readline(self, limit)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 727, in peek
    chunk = self.read(n)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 763, in read
    data = self._read1(n)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/zipfile.py", line 839, in _read1
    data = self._decompressor.decompress(data, n)
zlib.error: Error -3 while decompressing data: invalid stored block lengths



b) Given a string filename, simultaneous use of .open() produces a new file descriptor for each opened member, which does not result in the above error, but triggers an even worse one: file descriptor exhaustion given a sufficiently large zip file.


This tripped me up rather badly last week during consulting work, and I'd like to see both these behaviours fixed somehow. The ticket is more an RFC to see if anyone has thoughts on how this fix should happen; it seems to me a no-brainer that, since the ZIP file format fundamentally always requires a seekable file, that in both the "constructed using file-like object" case, and the "constructed using filename" case, we should somehow reuse the sole file object passed to us to satisfy all reads of compressed member data.

It seems the problems can be fixed in both cases without damaging interface semantics by simply tracking the expected 'current' read offset in each ZipExtFile instance. Prior to any read, we simply call .seek() on the file object prior to performing any .read().

Of course the result would not be thread safe, but at least in the current code, ZipExtFile for a "constructed from a file-like object" edition zipfile is already not thread-safe. With some additional work, we could make the module thread-safe in both cases, however this is not the current semantic and doesn't appear to be guaranteed by the module documentation.

---

Finally as to why you'd want to simultaneously open huge numbers of ZIP members, well, ZIP itself easily supports streamy reads, and ZIP files can be quite large, even larger than RAM. So it should be possible, as I needed last week, to read streamily from a large number of members.

---

The attached my.zip is sufficient to demonstrate both problems.

The attached my.py has function a() to demonstrate the FD leak and b() to demonstrate the interwingly state.

----------
components: Library (Lib)
files: mymy.zip
messages: 230987
nosy: dw
priority: normal
severity: normal
status: open
title: zipfile simultaneous open broken and/or needlessly(?) consumes unreasonable number of file descriptors
versions: Python 3.4
Added file: http://bugs.python.org/file37171/mymy.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22842>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:00:02 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 00:00:02 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415664002.7.0.200326723575.issue22840@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

With the following C code:

#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(){

  char buf[255];
  struct tm tm;

  memset(&tm, 0, sizeof(tm));
  strptime("20141110", "%Y%m%d%H%M", &tm);
  strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M", &tm);
  printf("%s\n", buf);

  return 0;
}

I get

$ ./a.out
2014-11-10 00:00

So I think Python behavior is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:03:51 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 00:03:51 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415664231.98.0.141488410208.issue22840@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Here is the case that I think illustrates the current logic better:

>>> datetime.strptime("20141234", "%Y%m%d%H%M")
datetime.datetime(2014, 1, 2, 3, 4)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:04:43 2014
From: report at bugs.python.org (David Wilson)
Date: Tue, 11 Nov 2014 00:04:43 +0000
Subject: [issue22842] zipfile simultaneous open broken and/or needlessly(?)
 consumes unreasonable number of file descriptors
In-Reply-To: <1415663928.91.0.265332652866.issue22842@psf.upfronthosting.co.za>
Message-ID: <1415664283.16.0.555421203652.issue22842@psf.upfronthosting.co.za>


David Wilson added the comment:

As a random side-note, this is another case where I really wish Python had a .pread() function. It's uniquely valuable for coordinating positioned reads in a threaded app without synchronization (at user level anyway) or extraneous system calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22842>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:07:44 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 00:07:44 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415664464.4.0.721529138919.issue22840@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Looking at the POSIX standard

http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html

It appears that Python may be compliant:

%H The hour (24-hour clock) [00,23]; leading zeros are permitted but not required.
%m The month number [01,12]; leading zeros are permitted but not required.
%M The minute [00,59]; leading zeros are permitted but not required.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:11:57 2014
From: report at bugs.python.org (Tim Smith)
Date: Tue, 11 Nov 2014 00:11:57 +0000
Subject: [issue22269] Resolve distutils option conflicts with priorities
In-Reply-To: <1408919544.9.0.398406846461.issue22269@psf.upfronthosting.co.za>
Message-ID: <1415664717.67.0.865705916773.issue22269@psf.upfronthosting.co.za>


Tim Smith added the comment:

Ping! Any chance for feedback here? This behavior took me by surprise again today. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22269>
_______________________________________

From report at bugs.python.org  Tue Nov 11 01:13:30 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 00:13:30 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415664810.06.0.6170651199.issue22840@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Here is another interesting bit from the standard: "The application shall ensure that there is white-space or other non-alphanumeric characters between any two conversion specifications."

This is how they get away from not specifying whether parser of variable width fields should be greedy or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:26:04 2014
From: report at bugs.python.org (Clayton Kirkwood)
Date: Tue, 11 Nov 2014 01:26:04 +0000
Subject: [issue22843] doc error: 6.2.4. Match Objects
Message-ID: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>


New submission from Clayton Kirkwood:

Documentation says:
> Match objects always have a boolean value of True. Since match() and
> search() return None when there is no match, you can test whether 
> there was a match with a simple if statement:
>
> match = re.search(pattern, string)
> if match:
>     process(match)

What happens:
blah = <_sre.SRE_Match object; span=(0, 28), match='<BR>Nov. 10, 08:16:09 PM EST'>
     if blah == True:
           print("True")
     if blah:
            print('blah True')

blah True
///

Blah is not True

One suggestion: instead, the passage above should say ?evaluates true in a boolean context?.

----------
assignee: docs at python
components: Documentation
messages: 230994
nosy: crkirkwood, docs at python
priority: normal
severity: normal
status: open
title: doc error: 6.2.4. Match Objects
type: resource usage
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22843>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:37:58 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Nov 2014 01:37:58 +0000
Subject: [issue22842] zipfile simultaneous open broken and/or needlessly(?)
 consumes unreasonable number of file descriptors
In-Reply-To: <1415663928.91.0.265332652866.issue22842@psf.upfronthosting.co.za>
Message-ID: <1415669878.98.0.404651254735.issue22842@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a duplicate of issue 16569 and issue 14099.  Since the former links to the latter I'm using that as the superseder.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Preventing errors of simultaneous access in zipfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22842>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:42:14 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Nov 2014 01:42:14 +0000
Subject: [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415670134.2.0.344236359804.issue22843@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's what "have a boolean value of True" means.  (ie: bool(<matchobject>) is True).  I'm neutral on whether or not it is worth changing the wording.

----------
nosy: +r.david.murray
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22843>
_______________________________________

From report at bugs.python.org  Tue Nov 11 02:53:08 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 11 Nov 2014 01:53:08 +0000
Subject: [issue22844] test_gdb failure on Debian Wheezy for Z
Message-ID: <1415670788.7.0.445632155994.issue22844@psf.upfronthosting.co.za>


New submission from David Edelsohn:

I added a Buildbot on another zLinux system running Debian Wheezy and it shows a different GDB error message: linux-vdso64.so.  Can you please add something like the following to allow test_gdb to pass?

diff -r 524a004e93dd Lib/test/test_gdb.py
--- a/Lib/test/test_gdb.py	Mon Nov 10 23:15:56 2014 +0200
+++ b/Lib/test/test_gdb.py	Mon Nov 10 20:51:49 2014 -0500
@@ -169,6 +169,8 @@
             'linux-vdso.so',
             'warning: Could not load shared library symbols for '
             'linux-gate.so',
+            'warning: Could not load shared library symbols for '
+            'linux-vdso64.so',
             'Do you need "set solib-search-path" or '
             '"set sysroot"?',
             'warning: Source file is more recent than executable.',

----------
components: Tests
messages: 230997
nosy: David.Edelsohn, haypo
priority: normal
severity: normal
status: open
title: test_gdb failure on Debian Wheezy for Z
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22844>
_______________________________________

From report at bugs.python.org  Tue Nov 11 04:16:44 2014
From: report at bugs.python.org (David Wilson)
Date: Tue, 11 Nov 2014 03:16:44 +0000
Subject: [issue16569] Preventing errors of simultaneous access in zipfile
In-Reply-To: <1354112511.94.0.436567820333.issue16569@psf.upfronthosting.co.za>
Message-ID: <1415675804.01.0.780876925492.issue16569@psf.upfronthosting.co.za>


David Wilson added the comment:

Compared to the cost of everything else ZipExtFile must do (e.g. 4kb string concatenation in a loop, zlib), its surprising that lseek() would measurable at all. 

The attached file 'patch' is the minimal change I tested. It represents, in terms of computation and system call overhead, all required to implement the "seek before read" solution to simultaneous access. On OSX, churning over ever member of every ZIP in my downloads directory (about 400mb worth), this change results in around 0.9% overhead compared to the original module.

Subsequently I'm strongly against the patch here. It is in effect papering over an implementation deficiency of the current zipfile module, one that could easily and cheaply be addressed.

(My comment on this ticket is in the context of the now-marked-duplicate issue22842).

----------
nosy: +dw
Added file: http://bugs.python.org/file37172/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16569>
_______________________________________

From report at bugs.python.org  Tue Nov 11 07:27:35 2014
From: report at bugs.python.org (sbspider)
Date: Tue, 11 Nov 2014 06:27:35 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1415687255.88.0.372840776042.issue22813@psf.upfronthosting.co.za>


sbspider added the comment:

Right makes sense. I'll see what I can do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22813>
_______________________________________

From report at bugs.python.org  Tue Nov 11 07:35:32 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 11 Nov 2014 06:35:32 +0000
Subject: [issue22719] os.path.isfile & os.path.exists bug in while loop
In-Reply-To: <1414166412.24.0.659144032685.issue22719@psf.upfronthosting.co.za>
Message-ID: <1415687732.72.0.918566493359.issue22719@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I have had a chance to build 3.3.0 and I was able to reproduce the bug with it, so it is in fact fixed in later versions.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22719>
_______________________________________

From report at bugs.python.org  Tue Nov 11 07:50:53 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Tue, 11 Nov 2014 06:50:53 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <1415599026.97.0.589284650072.issue22835@psf.upfronthosting.co.za>
Message-ID: <1415688653.54.0.978686180241.issue22835@psf.upfronthosting.co.za>


Dustin Oprea added the comment:

I think I was getting mixed results by using requests and urllib2/3. After nearly being driven crazy, I performed the following steps:

1. Recreated client certificates, and verified that the correct CA was being used from Nginx.

2. Experimenting using an SSL-wrapped client-socket directly, in tandem with s_client.

3. I then removed all of my virtualhosts except for a new one that pointed to a flat directory, just to make sure that I wasn't activating the wrong virtualhost, and there weren't any other complexities.

4. Implemented a bonafide, signed, SSL certificate on my local system, and overriding the hostname using /etc/hosts.

5. This got me past the 400. I switched back to using my local hostname with my self-signed certificate, and told wrap_socket to not verify (at this point, I stopped checking with s_client).

6. I started reactivating all of my normal virtualhost includes, one include at a time.

7. Reverted back to using the standard, proprietary client, and verified that it worked.

I'm guessing that a) something happened to my original certificates, b) I might've had an incorrect CA certificate for authentication, and/or c) I had added a default virtualhost on the non-standard port that I am using that always returns Forbidden, and this might've been unexpectedly catching the wrong requests.

Since I verified my client certificates against my internal issuer in the beginning, I don't think it's (a) or (b).

I could've done without these problems. I can't even say what started it all.

----------
nosy: +dsoprea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Tue Nov 11 07:52:57 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Nov 2014 06:52:57 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415688777.45.0.625689584057.issue22823@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Serhiy: set_literal_2.patch doesn't apply cleanly, so I don't get a "review" link.  And apparently Raymond checked in some other changes separately.  Could you redo your patch so it has the Clinic changes, and ensure I get a "review" link?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Tue Nov 11 08:42:47 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 07:42:47 +0000
Subject: [issue22845] Minor tweaks dis documentation
Message-ID: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch changes dis documentation:

* formats the *file* parameter with stars, not ``backticks``.
* adds missed links to opcodes.
* fixes POP_STACK to POP_TOP.

I hesitate about TOS and TOS1 words. Should they be highlighted in any manner?

----------
assignee: docs at python
components: Documentation
files: doc_dis.patch
keywords: patch
messages: 231003
nosy: docs at python, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Minor tweaks dis documentation
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37173/doc_dis.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22845>
_______________________________________

From report at bugs.python.org  Tue Nov 11 08:51:23 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Nov 2014 07:51:23 +0000
Subject: [issue22845] Minor tweaks dis documentation
In-Reply-To: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>
Message-ID: <1415692283.3.0.454716070109.issue22845@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM. While at it, could you add a period after these:

+      Added *file* parameter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22845>
_______________________________________

From report at bugs.python.org  Tue Nov 11 08:53:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 07:53:22 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415692402.74.0.557204462877.issue22823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch for clinic only.

----------
keywords: +patch
Added file: http://bugs.python.org/file37174/set_literal_clinic.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Tue Nov 11 09:06:06 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Nov 2014 08:06:06 +0000
Subject: [issue22845] Minor tweaks dis documentation
In-Reply-To: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>
Message-ID: <20141111080602.9603.73263@psf.io>


Roundup Robot added the comment:

New changeset d676f2725699 by Serhiy Storchaka in branch '3.4':
Issue #22845: Improved formatting of dis documentation.
https://hg.python.org/cpython/rev/d676f2725699

New changeset ac0334665459 by Serhiy Storchaka in branch 'default':
Issue #22845: Improved formatting of dis documentation.
https://hg.python.org/cpython/rev/ac0334665459

New changeset 0a32764004ab by Serhiy Storchaka in branch '2.7':
Issue #22845: Improved formatting of dis documentation.
https://hg.python.org/cpython/rev/0a32764004ab

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22845>
_______________________________________

From report at bugs.python.org  Tue Nov 11 09:16:19 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 08:16:19 +0000
Subject: [issue22845] Minor tweaks dis documentation
In-Reply-To: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>
Message-ID: <1415693779.94.0.80978850775.issue22845@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Done. Thank you Georg for your review.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22845>
_______________________________________

From report at bugs.python.org  Tue Nov 11 09:29:28 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Nov 2014 08:29:28 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
Message-ID: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

When I try to build APSW (http://rogerbinns.github.io/apsw/index.html) with Python 3.3 or 3.4 on Debian stable 64-bit I get the error output shown below.

I dug into the source and it seems that the problem is that distutils/ccompiler.py's gen_preprocess_options() functions expects to get a sequence of macros and each macro *must* be a 1 or 2 item tuple.

But for some reason during the APSW build it gets a 2 item list which it then chokes on.

Now, the code really does need a tuple because in some cases it uses Python's % print formatting option as in "-D%s=%s" % macro -- and this won't work if macro is a list.

I solved this problem for me by adding two lines, shown here in context:

    pp_opts = []
    for macro in macros:
        if isinstance(macro, list): # NEW
            macro = tuple(macro)    # NEW

I don't know how safe or wise a fix this is, but it did work for me for a locally built (from www.python.org tarball) 3.3 and 3.4.


$ /home/mark/opt/python34/bin/python3 setup.py fetch --all build --enable-all-extensions install
running fetch
  Getting download page to work out current SQLite version
    Fetching https://sqlite.org/download.html
    Version is 3.8.7.1
  Getting the SQLite amalgamation
    Fetching https://sqlite.org/2014/sqlite-autoconf-3080701.tar.gz
    Length: 1998389  SHA1: 5601be1263842209d7c5dbf6128f1cc0b6bbe2e5  MD5: 8ee4541ebb3e5739e7ef5e9046e30063
    Checksums verified
    Running configure to work out SQLite compilation flags
setup.py:53: DeprecationWarning: 'U' mode is deprecated
  f=open(name, mode)
running build
running build_ext
SQLite: Using amalgamation /home/mark/zip/apsw-3.8.7.1-r1/sqlite3/sqlite3.c
setup.py:624: ResourceWarning: unclosed file <_io.TextIOWrapper name=4 encoding='UTF-8'>
  for part in shlex.split(os.popen("icu-config --cppflags", "r").read()):
setup.py:637: ResourceWarning: unclosed file <_io.TextIOWrapper name=4 encoding='UTF-8'>
  for part in shlex.split(os.popen("icu-config --ldflags", "r").read()):
ICU: Added includes, flags and libraries from icu-config
building 'apsw' extension
Traceback (most recent call last):
  File "setup.py", line 862, in <module>
    'win64hackvars': win64hackvars}
  File "/home/mark/opt/python34/lib/python3.4/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/mark/opt/python34/lib/python3.4/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/home/mark/opt/python34/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build.py", line 126, in run
    self.run_command(cmd_name)
  File "/home/mark/opt/python34/lib/python3.4/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/mark/opt/python34/lib/python3.4/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "setup.py", line 661, in run
    v=beparent.run(self)
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build_ext.py", line 339, in run
    self.build_extensions()
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build_ext.py", line 448, in build_extensions
    self.build_extension(ext)
  File "/home/mark/opt/python34/lib/python3.4/distutils/command/build_ext.py", line 503, in build_extension
    depends=ext.depends)
  File "/home/mark/opt/python34/lib/python3.4/distutils/ccompiler.py", line 566, in compile
    depends, extra_postargs)
  File "/home/mark/opt/python34/lib/python3.4/distutils/ccompiler.py", line 341, in _setup_compile
    pp_opts = gen_preprocess_options(macros, incdirs)
  File "/home/mark/opt/python34/lib/python3.4/distutils/ccompiler.py", line 1061, in gen_preprocess_options
    % macro)
TypeError: bad macro definition '['_FORTIFY_SOURCE', '2']': each element of 'macros' list must be a 1- or 2-tuple

----------
components: Distutils
messages: 231008
nosy: dstufft, eric.araujo, mark
priority: normal
severity: normal
status: open
title: distutils needlessly fails to build apsw
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 09:35:03 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 11 Nov 2014 08:35:03 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415694903.03.0.444537132442.issue22823@psf.upfronthosting.co.za>


Larry Hastings added the comment:

The patch is totally fine.  I wonder why it was like that in the first place!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:12:11 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Nov 2014 09:12:11 +0000
Subject: [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415697131.29.0.935222371599.issue22843@psf.upfronthosting.co.za>


Georg Brandl added the comment:

"evaluates true" should not be used in any case, the objects do not equal to True in any case.

The phrase "is considered true in a boolean context" is already in the docs and could be used here too.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22843>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:15:53 2014
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Nov 2014 09:15:53 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415697353.78.0.975332393639.issue22846@psf.upfronthosting.co.za>


Ned Deily added the comment:

Have you reported this problem to the author of apsw?  It seems like figuring out why apsw is apparently creating an incorrect setup.py configuration should be a first step before suggesting a change to Distutils.  You might want to supply the values from your system for:

icu-config --cppflags
icu-config --ldflags

FWIW, with a current Debian testing, I get the following failure with either Python 3.4 or 2.7:

running build_ext
SQLite: Using amalgamation /tmp/e/apsw-3.8.7.1-r1/sqlite3/sqlite3.c
### icu-config: Can't find /usr/lib/i386-linux-gnu/libicuuc.so - ICU prefix is wrong.
###      Try the --prefix= option
###      or --detect-prefix
###      (If you want to disable this check, use  the --noverify option)
### icu-config: Exitting.
### icu-config: Can't find /usr/lib/i386-linux-gnu/libicuuc.so - ICU prefix is wrong.
###      Try the --prefix= option
###      or --detect-prefix
###      (If you want to disable this check, use  the --noverify option)
### icu-config: Exitting.
ICU: Unable to determine includes/libraries for ICU using icu-config
ICU: You will need to manually edit setup.py or setup.cfg to set them

So there may be issues with icu-config on Debian.  (Also, Python 3.3 is now in security-fix only mode.)

----------
nosy: +ned.deily
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:25:12 2014
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Nov 2014 09:25:12 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415697912.95.0.280952568649.issue22846@psf.upfronthosting.co.za>


Ned Deily added the comment:

Another data point: apsw appears to build OK on OS X with a MacPorts-supplied icu, including icu-config.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:35:09 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Nov 2014 09:35:09 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415698509.6.0.258347016761.issue22846@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

The first person I asked was the author of APSW (Roger Binns). He told me:

"The ultimate cause of that is some interaction with the compilation
environment.  Some sort of CFLAGS is ultimately ending up in some
Python code like above when it should be [ ('_FORTIFY_SOURCE', '2') ].
 Note this is not part of the APSW source - it is something external."

"I have seen it before when using the Ubuntu PPA build service.  When
building locally everything was fine, but the build service injected
_FORTIFY_SOURCE like above and got it wrong.  I presume your version
of Debian is doing something similar.  Sadly I have no idea how to fix it."

So clearly he believes it is not a problem with his setup.py file.

Also, it strikes me as a bit unpythonic that a function should demand a specific type (i.e., tuple) especially when this is just for the convenience of being able to use % formatting.

I'm not asking or expecting you to add my change to distutils; but at least now if someone encounters the same problem, they will have a potential fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:36:47 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Nov 2014 09:36:47 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415698607.88.0.935653060138.issue22846@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

Here are the flags you asked for:

$ icu-config --cppflags
-D_FORTIFY_SOURCE=2 -D_REENTRANT  -I/usr/include 
$ icu-config --ldflags
-Wl,-z,relro  -ldl -lm   -L/usr/lib/x86_64-linux-gnu -licui18n -licuuc -licudata  -ldl -lm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:43:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 09:43:26 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <1415688653.54.0.978686180241.issue22835@psf.upfronthosting.co.za>
Message-ID: <5461DA3A.1020300@free.fr>


Antoine Pitrou added the comment:

Le 11/11/2014 07:50, Dustin Oprea a ?crit :
> 
> Dustin Oprea added the comment:
> 
> I think I was getting mixed results by using requests and urllib2/3. After nearly being driven crazy, I performed the following steps:
> 
> 1. Recreated client certificates, and verified that the correct CA was being used from Nginx.
> 
> 2. Experimenting using an SSL-wrapped client-socket directly, in tandem with s_client.
> 
> 3. I then removed all of my virtualhosts except for a new one that pointed to a flat directory, just to make sure that I wasn't activating the wrong virtualhost, and there weren't any other complexities.
> 
> 4. Implemented a bonafide, signed, SSL certificate on my local system, and overriding the hostname using /etc/hosts.
> 
> 5. This got me past the 400.

Ah! Perhaps your HTTPS setup was relying on SNI to select the proper
virtual host ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Tue Nov 11 10:57:28 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 11 Nov 2014 09:57:28 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <5461DD83.9030604@egenix.com>


Marc-Andre Lemburg added the comment:

Shouldn't this be fixed in the APSW setup.py ?

The patch is you are proposing looks harmless, but it can also
mask programming errors in setup.py.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:07:04 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 10:07:04 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415700424.61.0.659487788144.issue22846@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> The ultimate cause of that is some interaction with the compilation
> environment.  Some sort of CFLAGS is ultimately ending up in some
> Python code like above when it should be [ ('_FORTIFY_SOURCE', '2') ].
> Note this is not part of the APSW source - it is something external.

That's as unhelpful as a bug report can get. If ICU doesn't provide the right types, the setup.py should fix them up.
(assuming ICU provides the preprocessor flags here - I haven't check)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:07:38 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 10:07:38 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415700458.47.0.517964681585.issue22846@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I suggest closing.

----------
nosy: +ncoghlan
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:10:12 2014
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Nov 2014 10:10:12 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415700612.22.0.212116875031.issue22846@psf.upfronthosting.co.za>


Ned Deily added the comment:

I was able to reproduce the behavior you saw with an older Debian system.  The following patch to the apsw setup.py file seems to fix the problem:

--- apsw-3.8.7.1-r1/setup.py	2014-11-04 19:23:36.000000000 -0800
+++ apsw-3.8.7.1-r1_PATCHED/setup.py	2014-11-11 02:01:16.000000000 -0800
@@ -628,7 +628,7 @@
                 elif part.startswith("-D"):
                     part=part[2:]
                     if '=' in part:
-                        part=part.split('=', 1)
+                        part=tuple(part.split('=', 1))
                     else:
                         part=(part, '1')
                     ext.define_macros.append(part)

Also, requiring a tuple is the documented behavior of Distutils:

https://docs.python.org/2/distutils/apiref.html#distutils.core.Extension

I agree that the issue should be closed and am closing it.

----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:18:31 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 11 Nov 2014 10:18:31 +0000
Subject: [issue22846] distutils needlessly fails to build apsw
In-Reply-To: <1415694568.83.0.41305678033.issue22846@psf.upfronthosting.co.za>
Message-ID: <1415701111.66.0.899122101408.issue22846@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

I've notified APSW's author and I'm sure he'll fix it. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22846>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:39:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 10:39:13 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1415702353.86.0.425645837359.issue18473@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that both UserDict.UserDict and UserDict.IterableUserDict should be mapped to collections.UserDict. And reverse mapping should map collections.UserDict to UserDict.IterableUserDict.

There are similar issues with other "multiple to single" mappings (e.g. to "io", "dbm", "http.server").

----------
nosy: +serhiy.storchaka
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:58:30 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 10:58:30 +0000
Subject: [issue20394] Coverity complains on audioop
In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za>
Message-ID: <1415703510.16.0.537813154935.issue20394@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/issue20394>
_______________________________________

From report at bugs.python.org  Tue Nov 11 11:58:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 10:58:37 +0000
Subject: [issue22407] re.LOCALE is nonsensical for Unicode
In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za>
Message-ID: <1415703517.29.0.0804434829558.issue22407@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/issue22407>
_______________________________________

From report at bugs.python.org  Tue Nov 11 12:02:03 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 11:02:03 +0000
Subject: [issue22407] re.LOCALE is nonsensical for Unicode
In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za>
Message-ID: <1415703723.72.0.419660382092.issue22407@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Convert re tests to unittest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22407>
_______________________________________

From report at bugs.python.org  Tue Nov 11 12:06:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 11:06:22 +0000
Subject: [issue22407] re.LOCALE is nonsensical for Unicode
In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za>
Message-ID: <1415703982.43.0.247368378073.issue22407@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If there are no objections I'll commit the re_deprecate_unicode_locale.patch patch. But it would be good if someone will review doc changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22407>
_______________________________________

From report at bugs.python.org  Tue Nov 11 12:10:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 11:10:58 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1415704258.93.0.970527301834.issue11820@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What do you think about this patch Terry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Tue Nov 11 14:08:04 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Nov 2014 13:08:04 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415711284.83.0.870486242263.issue22827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks Donald, left some review comments on Reitveld.

While I had some comments on the docs, I think the code changes all look fine - would it be worth incorporating this version immediately to make it easier to get started on the Windows and Mac OS X installer updates?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Tue Nov 11 14:24:28 2014
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 11 Nov 2014 13:24:28 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415712268.68.0.624974044955.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I've updated the patch with Nick's comments, except for pulling in the latest versions of the documentation.

----------
Added file: http://bugs.python.org/file37175/pep-477-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Tue Nov 11 15:20:32 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 11 Nov 2014 14:20:32 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415712268.68.0.624974044955.issue22827@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d=ncggh_BtYK1B=i1Cv=yRphRdLdgdOAvkE4e+ujQhYg@mail.gmail.com>


Nick Coghlan added the comment:

Thanks. I suggest committing that version, so the rest of the backport
(installer integration & packaging docs backport) can proceed in parallel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Tue Nov 11 15:43:25 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Tue, 11 Nov 2014 14:43:25 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <5461DA3A.1020300@free.fr>
Message-ID: <CAOr1xOF-8UTeJ7am3YRQqWTiPC_NUkW3xu2d4PQfiasJWN7Lrw@mail.gmail.com>


Dustin Oprea added the comment:

I usually use both on my local system.

Dustin
On Nov 11, 2014 4:43 AM, "Antoine Pitrou" <report at bugs.python.org> wrote:

>
> Antoine Pitrou added the comment:
>
> Le 11/11/2014 07:50, Dustin Oprea a ?crit :
> >
> > Dustin Oprea added the comment:
> >
> > I think I was getting mixed results by using requests and urllib2/3.
> After nearly being driven crazy, I performed the following steps:
> >
> > 1. Recreated client certificates, and verified that the correct CA was
> being used from Nginx.
> >
> > 2. Experimenting using an SSL-wrapped client-socket directly, in tandem
> with s_client.
> >
> > 3. I then removed all of my virtualhosts except for a new one that
> pointed to a flat directory, just to make sure that I wasn't activating the
> wrong virtualhost, and there weren't any other complexities.
> >
> > 4. Implemented a bonafide, signed, SSL certificate on my local system,
> and overriding the hostname using /etc/hosts.
> >
> > 5. This got me past the 400.
>
> Ah! Perhaps your HTTPS setup was relying on SNI to select the proper
> virtual host ?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22835>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Tue Nov 11 16:25:52 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 Nov 2014 15:25:52 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1415719552.52.0.809430945785.issue22834@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/issue22834>
_______________________________________

From report at bugs.python.org  Tue Nov 11 16:34:18 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 Nov 2014 15:34:18 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415720058.71.0.92264598752.issue22840@psf.upfronthosting.co.za>


Brett Cannon added the comment:

strptime very much follows the POSIX standard as I implemented strptime by reading that doc.

If you want to see how the behaviour is implemented you can look at https://hg.python.org/cpython/file/ac0334665459/Lib/_strptime.py#l178 . But the key thing here is that the OP has unused formatters. Since strptime uses regexes underneath the hood, the re module does its best to match the entire format. Since POSIX says that e.g. the leading 0 for %m is optional, the regex goes with the single digit version to let the %H format match _something_ (same goes for %d and %M). So without rewriting strptime to not use regexes to support unused formatters and to stop being so POSIX-compliant, I don't see how to change the behaviour. Plus it would be backwards-incompatible as this is how strptime has worked in 2002.

It's Alexander's call, but I vote to close this as "not a bug".

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 16:57:28 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 15:57:28 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1415721448.56.0.15277226922.issue22840@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

After reading the standard a few more times, I agree with Brett and Ethan that this is at most a call for better documentation.

I'll leave this open for a chance that someone will come up with a succinct description of what exactly datetime.strptime does. (Maybe we should just document the format to regexp translation implemented in _strptime.py.)

We may also include POSIX's directive "The application shall ensure that there is white-space or other non-alphanumeric characters between any two conversion specifications" as a recommendation.

----------
assignee:  -> belopolsky
components: +Documentation -Library (Lib)
type: behavior -> enhancement
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22840>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:10:47 2014
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 11 Nov 2014 16:10:47 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415722247.04.0.468076370076.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Merged in https://hg.python.org/cpython/rev/592a5414fabd, I forgot to mention the issue number.

I'm going to leave this open for the docs changes, however the OSX installer and Windows installer changes should be able to be made now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:13:28 2014
From: report at bugs.python.org (Josh Lee)
Date: Tue, 11 Nov 2014 16:13:28 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
 interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <1415722408.5.0.393744616676.issue13444@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/issue13444>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:13:46 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 16:13:46 +0000
Subject: [issue22847] Improve method cache efficiency
Message-ID: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The method cache is currently very small. Attached patch bumps the size a bit and improves the hash computation formula.

----------
components: Interpreter Core
files: methcache.patch
keywords: patch
messages: 231031
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve method cache efficiency
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file37176/methcache.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:19:14 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 16:19:14 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1415722754.3.0.224145979137.issue22847@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It's not easy to get stable benchmark runs, but here is an example:

Report on Linux fsol 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:07:32 UTC 2014 x86_64 x86_64
Total CPU cores: 4

### 2to3 ###
7.083762 -> 6.904087: 1.03x faster

### formatted_logging ###
Min: 0.351515 -> 0.330884: 1.06x faster
Avg: 0.352954 -> 0.332422: 1.06x faster
Significant (t=62.94)
Stddev: 0.00120 -> 0.00197: 1.6382x larger

### mako_v2 ###
Min: 0.035797 -> 0.034659: 1.03x faster
Avg: 0.036427 -> 0.035378: 1.03x faster
Significant (t=50.65)
Stddev: 0.00032 -> 0.00034: 1.0668x larger

### richards ###
Min: 0.174242 -> 0.163918: 1.06x faster
Avg: 0.175643 -> 0.165689: 1.06x faster
Significant (t=58.69)
Stddev: 0.00086 -> 0.00084: 1.0168x smaller

### simple_logging ###
Min: 0.300215 -> 0.287112: 1.05x faster
Avg: 0.301957 -> 0.288785: 1.05x faster
Significant (t=80.08)
Stddev: 0.00086 -> 0.00078: 1.1052x smaller

The following not significant results are hidden, use -v to show them:
django_v2, silent_logging, tornado_http.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Tue Nov 11 17:56:41 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 16:56:41 +0000
Subject: [issue22558] Missing hint to source code - complete
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1415725001.74.0.231294592897.issue22558@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

+1 "to add links to all the [Python] modules"

If the code is not readable, hard to understand or not self-documenting that's the reason to improve the code not to make it harder to find and see.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Tue Nov 11 18:41:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 17:41:01 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1415727661.72.0.616163585574.issue22847@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current hashing algorithm takes middle bits, proposed code takes low bits. Doesn't this make the hash worse?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Tue Nov 11 18:51:37 2014
From: report at bugs.python.org (Brett Hannigan)
Date: Tue, 11 Nov 2014 17:51:37 +0000
Subject: [issue22848] Subparser help does not respect SUPPRESS argument
Message-ID: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>


New submission from Brett Hannigan:

When adding an argument to a subparser and passing help=argparse.SUPPRESS, I would expect this argument to not show up when running help.  Instead, I find that the argument is listed and the help given is ==SUPPRESS==.  For example (also in attached python script):
import argparse

parser = argparse.ArgumentParser('test')
subparsers = parser.add_subparsers()
parser_foo = subparsers.add_parser('foo', help='This is help for foo')
parser_bar = subparsers.add_parser('bar', help=argparse.SUPPRESS)

parser.parse_args(['-h'])

usage: test [-h] {foo,bar} ...

positional arguments:
  {foo,bar}
    foo       This is help for foo
    bar       ==SUPPRESS==

optional arguments:
  -h, --help  show this help message and exit

I believe I have found the proper fix in argparse.py
In the class _SubParsersAction look at the method add_parser().
There is the following block of code:

if 'help' in kwargs:
            help = kwargs.pop('help')
            choice_action = self._ChoicesPseudoAction(name, help)
            self._choices_actions.append(choice_action)

This should instead check to see if help is SUPPRESS or not like so:

if 'help' in kwargs:
            help = kwargs.pop('help')
            if help != SUPPRESS:
                choice_action = self._ChoicesPseudoAction(name, help)
                self._choices_actions.append(choice_action)

If I make this change locally, then the above code does in fact suppress printing the bar option.

----------
components: Library (Lib)
files: argparse_test.py
messages: 231035
nosy: Brett.Hannigan
priority: normal
severity: normal
status: open
title: Subparser help does not respect SUPPRESS argument
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37177/argparse_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22848>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:08:54 2014
From: report at bugs.python.org (Brett Hannigan)
Date: Tue, 11 Nov 2014 18:08:54 +0000
Subject: [issue22848] Subparser help does not respect SUPPRESS argument
In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>
Message-ID: <1415729334.08.0.598684626691.issue22848@psf.upfronthosting.co.za>


Changes by Brett Hannigan <bhannigan at dnanexus.com>:


Added file: http://bugs.python.org/file37178/argparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22848>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:09:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 18:09:59 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1415729399.64.0.923565406459.issue22847@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

FYI method cache optimization was added in issue1700288.

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:44:00 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 18:44:00 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415731440.74.0.228067178257.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch which solves the algorithmic complexity issue by using a different scheme: instead of splitting, match words incrementally.

----------
keywords: +patch
nosy: +pitrou
stage: needs patch -> patch review
versions:  -Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37179/wordsplit_complexity.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 19:44:31 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 18:44:31 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1415731471.14.0.726437300696.issue22847@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The low bits of the unicode hash should be as good as the middle bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:00:25 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 19:00:25 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415732425.39.0.371381714693.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Actually, it is enough to change the regexp while still using re.split(). Updated patch attached.

----------
Added file: http://bugs.python.org/file37180/wordsplit_complexity2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:04:18 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 19:04:18 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1415732658.44.0.915430736643.issue22847@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

In addition, the tp_version_tag evolves incrementally, so the low bits should be better when the same name is looked up on different types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:17:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 19:17:05 +0000
Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported
Message-ID: <1415733425.19.0.820180004417.issue433030@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Some unrelated to the topic changes from the patch are committed in 30a6c74ad87f.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433030>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:21:32 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 19:21:32 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <1415599026.97.0.589284650072.issue22835@psf.upfronthosting.co.za>
Message-ID: <1415733692.57.0.157766536549.issue22835@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

In any case, it sounds like your problem is fixed, so we can close this issue.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:23:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 19:23:50 +0000
Subject: [issue22434] Use named constants internally in the re module
In-Reply-To: <8184788.6OkEFgrSc3@raxxla>
Message-ID: <4318662.XZodpmD8qV@raxxla>


Serhiy Storchaka added the comment:

> Since the op codes are singletons, you can use identity tests instead of
> equality checks in sre_parse.py:

Please ignore my reply in previous message. Op codes are always tested for 
identity in sre_compile.py, so I have applied your suggestion in sre_parse.py 
(30a6c74ad87f).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22434>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:42:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 19:42:36 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415734956.32.0.119801832462.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately there are two disadvantages:

1. wordsep_re and wordsep_simple_re are public attributes and user code can depend on this. Changing their is a way to customize TextWrapper.

2. This is slowdown common case (no abnormally long words):

$ ./python -m timeit -s 'import textwrap; s = "abcde " * 10**4' -- 'textwrap.wrap(s)'

Unpatched: 178 msec per loop
Patched: 285 msec per loop

First reason stopped me from writing a patch.

When change the way how to split words, I suggest to use undocumented re scanner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:46:12 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 19:46:12 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415735172.13.0.38551691058.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Are you sure? I get the reverse results here (second patch):

Unpatched:
$ ./python -m timeit -s 'import textwrap; s = "abcde " * 10**4' -- 'textwrap.wrap(s)'
10 loops, best of 3: 27 msec per loop

Patched:
$ ./python -m timeit -s 'import textwrap; s = "abcde " * 10**4' -- 'textwrap.wrap(s)'
10 loops, best of 3: 19.2 msec per loop

> wordsep_re and wordsep_simple_re are public attributes and user code can depend on this. Changing their is a way to customize TextWrapper.

With my second patch, that shouldn't be a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:49:15 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 19:49:15 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415735355.2.0.179941975035.issue20220@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Any other ideas for a reliable method to restore the correct timezone after running a test?

No. The best would be for you to investigate. Perhaps contact some glibc guys.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20220>
_______________________________________

From report at bugs.python.org  Tue Nov 11 20:56:51 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Tue, 11 Nov 2014 19:56:51 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1415735811.52.0.217890898063.issue22619@psf.upfronthosting.co.za>


Dmitry Kazakov added the comment:

I updated the patch.

----------
Added file: http://bugs.python.org/file37181/traceback.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:14:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 20:14:16 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1415735172.13.0.38551691058.issue22687@psf.upfronthosting.co.za>
Message-ID: <7152586.pS4QJsiVuP@raxxla>


Serhiy Storchaka added the comment:

Oh, sorry, I tested your first patch. Your second patch is faster than current 
code to me. But it changes behavior.

>>> textwrap.wrap('"1a-2b', width=5)
['"1a-', '2b']

With the patch the result is ['"1a-2', 'b'].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:23:03 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 20:23:03 +0000
Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported
Message-ID: <1415737383.05.0.885373937311.issue433030@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Reopened because definitely regex will be not adopted in 3.5.

Here is updated to 3.5 Jeffrey's patch.

----------
resolution: duplicate -> 
status: closed -> open
versions: +Python 3.5 -Python 3.2
Added file: http://bugs.python.org/file37182/re_atomic_groups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433030>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:24:41 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 11 Nov 2014 20:24:41 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415737481.61.0.983478805664.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes... but in both cases the result is nonsensical, and untested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:44:37 2014
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 11 Nov 2014 20:44:37 +0000
Subject: [issue20220] TarFile.list() outputs wrong time
In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za>
Message-ID: <1415738677.37.0.101184034839.issue20220@psf.upfronthosting.co.za>


David Edelsohn added the comment:

It doesn't fail on the Debian system.  The Debian system will be successful after the test_gdb patch is installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20220>
_______________________________________

From report at bugs.python.org  Tue Nov 11 21:48:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 20:48:14 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415738894.79.0.885303960776.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Possessive quantifiers (issue433030) is not a panacea. They allow to speed up regular expressions, but the complexity is still quadratic. Antoine's patch makes the complexity linear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Nov 11 22:37:17 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Tue, 11 Nov 2014 21:37:17 +0000
Subject: [issue22835] urllib2/httplib is rendering 400s for every
 authenticated-SSL request, suddenly
In-Reply-To: <1415733692.57.0.157766536549.issue22835@psf.upfronthosting.co.za>
Message-ID: <CAG0x-EAgaEphvq1Zv5xP5uO6BuanHkFQWkDXv_xcZi_wQK1PmA@mail.gmail.com>


Dustin Oprea added the comment:

Agreed. Thank you, @Antoine.

On Tue, Nov 11, 2014 at 2:21 PM, Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou added the comment:
>
> In any case, it sounds like your problem is fixed, so we can close this
> issue.
>
> ----------
> resolution:  -> not a bug
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22835>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22835>
_______________________________________

From report at bugs.python.org  Tue Nov 11 23:55:26 2014
From: report at bugs.python.org (Tim Hatch)
Date: Tue, 11 Nov 2014 22:55:26 +0000
Subject: [issue22849] Double DECREF in TextIOWrapper
Message-ID: <1415746526.05.0.824048300267.issue22849@psf.upfronthosting.co.za>


New submission from Tim Hatch:

There's a reproducible bug in textio.c that causes a double DECREF on codecs.  The conditions to trigger are probably rare in real life, so not remotely exploitable (sandbox escape is the worst I can think of on its own, and I'm not aware of any on 3.x):

* You need to create a TextIOWrapper wrapping a file-like object that only partially supports the protocol.  For example, supporting readable(), writable(), and seekable() but not tell().

The crash I experience most of the time appears to be that the memory being reused, such that the PyObject ob_type field is no longer a valid pointer.

Affected:
  Source 3.5.0a0 (latest default branch yesterday, 524a004e93dd)
  Archlinux: 3.3.5 and 3.4.2
  Ubuntu: 3.4.0
Unaffected:
  Centos: 3.3.2
  All 2.7 branch (doesn't contain the faulty commit)

Here's where it's introduced -- https://hg.python.org/cpython/rev/f3ec00d2b75e/#l5.76

/* Modules/_io/textio.c line 1064 */

Py_DECREF(codec_info); 
/* does not set codec_info = NULL; */
...
if(...) goto error;
...
error:
  Py_XDECREF(codec_info);

The attached script is close to minimal -- I think at most you can reduce by one TextIOWrapper instantiation.  Sample stacktrace follows (which is after the corruption occurs, on subsequent access to v->ob_type (which is invalid).

#0  0x00000000004c8829 in PyObject_GetAttr (v=<unknown at remote 0x7ffff7eb9688>, 
    name='_is_text_encoding') at Objects/object.c:872
#1  0x00000000004c871d in _PyObject_GetAttrId (v=<unknown at remote 0x7ffff7eb9688>, 
    name=0x945d50 <PyId__is_text_encoding.10143>) at Objects/object.c:835
#2  0x00000000005c6674 in _PyCodec_LookupTextEncoding (
    encoding=0x7ffff6f40220 "utf-8", alternate_command=0x6c2fcd "codecs.open()")
    at Python/codecs.c:541
#3  0x000000000064286e in textiowrapper_init (self=0x7ffff7f9ecb8, 
    args=(<F at remote 0x7ffff6f40a18>,), kwds={'encoding': 'utf-8'})
    at ./Modules/_io/textio.c:965

----------
components: Library (Lib)
files: segv.py
messages: 231054
nosy: thatch
priority: normal
severity: normal
status: open
title: Double DECREF in TextIOWrapper
type: crash
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37183/segv.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22849>
_______________________________________

From report at bugs.python.org  Wed Nov 12 00:51:08 2014
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 11 Nov 2014 23:51:08 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1415749868.44.0.418498101854.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Ping! It's been about 3 months since this was given the green light...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21514>
_______________________________________

From report at bugs.python.org  Wed Nov 12 01:39:24 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Nov 2014 00:39:24 +0000
Subject: [issue11820] idle3 shell os.system swallows shell command output
In-Reply-To: <1302421540.99.0.957938249964.issue11820@psf.upfronthosting.co.za>
Message-ID: <1415752764.69.0.871719787342.issue11820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Currently, when Idle is started from a command line or console interpreter, "import os; os.system('dir')" produces the listing in the console window, as expected.

Reading the patch, it *augments* one-channel socket communication, which properly* combines and serializes stdout and stderr messages, with two-channel pipe communication.  This is rather messy and leads to inter-mixed displays, as reported.  If sensibly possible, the process stdout/err (fileno 1&2) written to by the os functions in question should forward bytes to the idle process via the rpc channel, properly labelled as stdout or stderr.

* There is a bug where the second prompt of a shell session gets intermixed with previous output or clipboard content, but I do not have a repeatable test case yet. 

Issue #18823 is about *replacing* the socket with pipes (whether using subprocess or multi-processing or whatever.).  (There should still be just one channel, not two, from user process to Idle process to keep the rpc protocol in control of what the Idle process receives.)  About last August, Roger sent at least a few of us somewhat large proof of concept patch, which I have not reviewed yet.

The patch uses Tk.createfilehandler, which seems not to exist on Windows, so I cannot review further.

  File "F:\Python\dev\34\lib\tkinter\__init__.py", line 1932, in __getattr__
    return getattr(self.tk, attr)
AttributeError: 'tkapp' object has no attribute 'createfilehandler'
  File "F:\Python\dev\34\lib\tkinter\__init__.py", line 1932, in __getattr__
    return getattr(self.tk, attr)
AttributeError: 'tkapp' object has no attribute 'createfilehandler'  File "F:\Python\dev\34\lib\tkinter\__init__.py", line 1932, in __getattr__
    return getattr(self.tk, attr)
AttributeError: 'tkapp' object has no attribute 'createfilehandler'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11820>
_______________________________________

From report at bugs.python.org  Wed Nov 12 01:46:21 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 12 Nov 2014 00:46:21 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1415753181.85.0.461471932347.issue22364@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I already said we should either stick with what we have if better (and gave examples, including sticking with 'cannot') or possibly combine the best of both if we can improve on both.  13 should use 'bytes-like' (already changed?). There is no review button.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22364>
_______________________________________

From report at bugs.python.org  Wed Nov 12 02:17:25 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 01:17:25 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1415755045.36.0.0348056608893.issue21514@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/issue21514>
_______________________________________

From report at bugs.python.org  Wed Nov 12 02:52:24 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 01:52:24 +0000
Subject: [issue22849] Double DECREF in TextIOWrapper
In-Reply-To: <1415746526.05.0.824048300267.issue22849@psf.upfronthosting.co.za>
Message-ID: <1415757144.2.0.0425790156767.issue22849@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +ncoghlan, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22849>
_______________________________________

From report at bugs.python.org  Wed Nov 12 04:07:23 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Nov 2014 03:07:23 +0000
Subject: [issue19494] Add urllib2.HTTPBasicPriorAuthHandler for use with APIs
 that don't return 401 errors
In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za>
Message-ID: <1415761643.94.0.769767259983.issue19494@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated the issue title to reflect the current state of the proposal - adding a new Handler class for use when you want to send the auth details unconditionally, rather than requiring that the server send a 401 response before resubmitting the request with authentication attached.

The use of a separate class addresses the concerns around sending credentials unconditionally, and the restriction to 3.5+ matches the general conclusion that it's a new feature.

I'll commit this shortly (just making sure my local build environment is properly configured after upgrading to the F21 beta release).

----------
stage: patch review -> commit review
title: urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar -> Add urllib2.HTTPBasicPriorAuthHandler for use with APIs that don't return 401 errors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19494>
_______________________________________

From report at bugs.python.org  Wed Nov 12 05:30:33 2014
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Nov 2014 04:30:33 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
Message-ID: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>


New submission from Steve Dower:

I've merged the changes from when ensurepip was added to Python 3 into msi.py (and also fixed up the new externals dir location), but I'm no expert on this script, so at least a second set of eyes would be appreciated. It seems to build and work okay.

----------
assignee: steve.dower
components: Windows
files: ensurepipmsi.diff
keywords: patch
messages: 231059
nosy: benjamin.peterson, dstufft, loewis, ncoghlan, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Backport ensurepip Windows installer changes to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37184/ensurepipmsi.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 05:31:43 2014
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Nov 2014 04:31:43 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1415766703.0.0.783858416293.issue22850@psf.upfronthosting.co.za>


Steve Dower added the comment:

Issue #22827 was the ensurepip backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 05:40:29 2014
From: report at bugs.python.org (Donald Stufft)
Date: Wed, 12 Nov 2014 04:40:29 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1415767229.14.0.465097854452.issue22850@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I don't know anything about msi or this script so I can't offer any help there, but thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 06:23:35 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 12 Nov 2014 05:23:35 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
 interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <1415769815.26.0.628502713991.issue13444@psf.upfronthosting.co.za>


Martin Panter added the comment:

Shouldn?t this issue be marked closed and fixed?

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13444>
_______________________________________

From report at bugs.python.org  Wed Nov 12 06:49:16 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 05:49:16 +0000
Subject: [issue13444] closed stdout causes error on stderr when the
 interpreter unconditionally flushes on shutdown
In-Reply-To: <1321888700.56.0.103830046171.issue13444@psf.upfronthosting.co.za>
Message-ID: <1415771356.98.0.464540400996.issue13444@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13444>
_______________________________________

From report at bugs.python.org  Wed Nov 12 07:33:44 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 06:33:44 +0000
Subject: [issue19796] urllib2.HTTPError.reason is not documented as "Added in
 2.7"
In-Reply-To: <1385459958.78.0.648544615764.issue19796@psf.upfronthosting.co.za>
Message-ID: <1415774024.52.0.429754158087.issue19796@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue 13211 was about a bug in exception hierarchy of the urllib2 module(not an addition to the public API - see msg147318 for detailed explanation). I don't think we need to update documentation.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19796>
_______________________________________

From report at bugs.python.org  Wed Nov 12 07:53:10 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Nov 2014 06:53:10 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1415775190.53.0.063720377488.issue22850@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This looks to match the relevant pieces of the Python 3 version to me.

However, it occurs to me that Python 2 will still be missing other Windows usability enhancements that make pip easier to use:

- bundling the py launcher
- providing the installer option to enable PATH modifications that add the Scripts directory to the path

I forgot about those when writing PEP 477.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 09:34:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Nov 2014 08:34:21 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1415738894.79.0.885303960776.issue22687@psf.upfronthosting.co.za>
Message-ID: <3191135.2MNFfpqdv0@raxxla>


Serhiy Storchaka added the comment:

Current regex produces insane result.

$ ./python -c "import textwrap; print(textwrap.wrap('this-is-a-useful-feature', width=1, break_long_words=False))"
['this-', 'is-a', '-useful-', 'feature']

Antoine's regex produces more correct result for this case: ['this-', 'is-', 'a-', 'useful-', 'feature']. But this is not totally correct, one-letter word should not be separated. This can be easy fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Wed Nov 12 10:41:42 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Nov 2014 09:41:42 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415785302.9.0.0882994146253.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> But this is not totally correct, one-letter word should not be
> separated.

Why not? I guess it depends on English's rules for word splitting, which I don't know.
In any case, this issue is not about improving correctness, only performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:06:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Nov 2014 10:06:55 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1415785302.9.0.0882994146253.issue22687@psf.upfronthosting.co.za>
Message-ID: <7081372.a5YBIvlUoA@raxxla>


Serhiy Storchaka added the comment:

> Why not? I guess it depends on English's rules for word splitting, which I
> don't know.

I suppose this is common rule in many languages. And current code supports it (there is a special code in the regex to ensure this rule).

> In any case, this issue is not about improving correctness,
> only performance.

But the patch shouldn't add a regression.

$ ./python -c "import textwrap; print(textwrap.wrap('this-is-a-useful', width=1, break_long_words=False))"

Current code: ['this-', 'is-a-useful']
Patched: ['this-', 'is-', 'a-', 'useful']

Just use lookahead assertion to ensure that the hyphen is followed by at least two letters.

My previous message is about that current code is not always correct so it is acceptable to replace it with not absolutely equivalent code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:13:27 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Nov 2014 10:13:27 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415787207.48.0.645602003078.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I suppose this is common rule in many languages.

I frankly don't know about this rule. And the tests don't check for it, so for me it's not broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:20:31 2014
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 12 Nov 2014 10:20:31 +0000
Subject: [issue22851] core crashes
Message-ID: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with the current 2.7 branch:

$ cat > x.py
def foo(): yield
gen = foo()
print gen.gi_frame.f_restricted
for i in gen: pass
print gen.gi_frame
gen = foo()
print gen.next()
print gen.gi_frame.f_restricted

$ python x.py 
False
None
None
Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
0x0000000000462b44 in frame_getrestricted (
    f=Frame 0x7ffff7f58410, for file x.py, line 1, in foo (), closure=0x0)
    at ../Objects/frameobject.c:383
383     ../Objects/frameobject.c: No such file or directory.
(gdb) bt
#0  0x0000000000462b44 in frame_getrestricted (
    f=Frame 0x7ffff7f58410, for file x.py, line 1, in foo (), closure=0x0)
    at ../Objects/frameobject.c:383

----------
components: Interpreter Core
messages: 231069
nosy: doko
priority: normal
severity: normal
status: open
title: core crashes
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:23:31 2014
From: report at bugs.python.org (Stian Soiland-Reyes)
Date: Wed, 12 Nov 2014 10:23:31 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
Message-ID: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>


New submission from Stian Soiland-Reyes:

urllib.parse can't handle URIs with empty #fragments. The fragment is removed and not reconsituted.

http://tools.ietf.org/html/rfc3986#section-3.5 permits empty fragment strings:


      URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
      fragment    = *( pchar / "/" / "?" )

And even specifies component recomposition to distinguish from not being defined and being an empty string:

http://tools.ietf.org/html/rfc3986#section-5.3


   Note that we are careful to preserve the distinction between a
   component that is undefined, meaning that its separator was not
   present in the reference, and a component that is empty, meaning that
   the separator was present and was immediately followed by the next
   component separator or the end of the reference.


This seems to be caused by missing components being represented as '' instead of None.

>>> import urllib.parse
>>> urllib.parse.urlparse("http://example.com/file#")
ParseResult(scheme='http', netloc='example.com', path='/file', params='', query='', fragment='')
>>> urllib.parse.urlunparse(urllib.parse.urlparse("http://example.com/file#"))
'http://example.com/file'

>>> urllib.parse.urlparse("http://example.com/file#").geturl()
'http://example.com/file'

>>> urllib.parse.urlparse("http://example.com/file# ").geturl()
'http://example.com/file# '

>>> urllib.parse.urlparse("http://example.com/file#nonempty").geturl()
'http://example.com/file#nonempty'

>>> urllib.parse.urlparse("http://example.com/file#").fragment
''

The suggested fix is to use None instead of '' to represent missing components, and to check with "if fragment is not None" instead of "if not fragment".


The same issue applies to query and authority. E.g.

http://example.com/file? != http://example.com/file

... but be careful about the implications of

file:///file != file:/file

----------
components: Library (Lib)
messages: 231070
nosy: soilandreyes
priority: normal
severity: normal
status: open
title: urllib.parse wrongly strips empty #fragment
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:26:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2014 10:26:19 +0000
Subject: [issue22851] core crashes
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1415787979.32.0.236179568055.issue22851@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/issue22851>
_______________________________________

From report at bugs.python.org  Wed Nov 12 11:42:26 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 12 Nov 2014 10:42:26 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1415788946.72.0.715653258927.issue22852@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Wed Nov 12 12:06:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Nov 2014 11:06:15 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1415787207.48.0.645602003078.issue22687@psf.upfronthosting.co.za>
Message-ID: <2468972.v3zeg8pcLy@raxxla>


Serhiy Storchaka added the comment:

Tests are not perfect. But this is intentional design. The part of initial 
regex:

    r'\w{2,}-(?=\w{2,})|'     # hyphenated words

Now it is more complicated. Note '(?=\w{2,})'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Wed Nov 12 12:38:14 2014
From: report at bugs.python.org (eryksun)
Date: Wed, 12 Nov 2014 11:38:14 +0000
Subject: [issue22851] core crashes
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1415792294.05.0.44644646515.issue22851@psf.upfronthosting.co.za>


eryksun added the comment:

This is related to the fix for issue 14432. gen_send_ex sets f->f_tstate to NULL, so PyFrame_IsRestricted segfaults: 

    #define PyFrame_IsRestricted(f) \
        ((f)->f_builtins != (f)->f_tstate->interp->builtins)

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Wed Nov 12 13:29:31 2014
From: report at bugs.python.org (Florian Finkernagel)
Date: Wed, 12 Nov 2014 12:29:31 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
Message-ID: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>


New submission from Florian Finkernagel:

If you import a module that creates a multiprocessing.Queue, puts a value, and then waits for to be received again from the queue, you run into a deadlock.

The issue is that Queue._feed does 'from .util import is_existing' - which needs the import lock, but is still being held by the main thread.

Attached a script that illustrates this.

Patch is a two line change, import is_exiting in line 49, remove the import inside the thread:

49c49
< from multiprocessing.util import debug, info, Finalize, register_after_fork
---
> from multiprocessing.util import debug, info, Finalize, register_after_fork, is_exiting
232d231
<         from .util import is_exiting

----------
files: show_queue_import_bug.py
messages: 231073
nosy: ffinkernagel
priority: normal
severity: normal
status: open
title: Multiprocessing.Queue._feed deadlocks on import
versions: Python 2.7
Added file: http://bugs.python.org/file37185/show_queue_import_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22853>
_______________________________________

From report at bugs.python.org  Wed Nov 12 13:54:43 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 12 Nov 2014 12:54:43 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1415796883.37.0.388087504416.issue22850@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I'm not working on Python 2.7 anymore, so I can't offer help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 13:57:50 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2014 12:57:50 +0000
Subject: [issue22851] core crashes
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1415797070.55.0.914650579448.issue22851@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Related change:

New changeset aa324af42c0e by Victor Stinner in branch '2.7':
Issue #14432: Generator now clears the borrowed reference to the thread state
http://hg.python.org/cpython/rev/aa324af42c0e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Wed Nov 12 14:34:47 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Nov 2014 13:34:47 +0000
Subject: [issue19494] Add urllib2.HTTPBasicPriorAuthHandler for use with APIs
 that don't return 401 errors
In-Reply-To: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za>
Message-ID: <20141112133402.24858.82939@psf.io>


Roundup Robot added the comment:

New changeset fb3061ba6fd2 by Nick Coghlan in branch 'default':
Close #19494: add urrlib.request.HTTPBasicPriorAuthHandler
https://hg.python.org/cpython/rev/fb3061ba6fd2

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19494>
_______________________________________

From report at bugs.python.org  Wed Nov 12 14:49:57 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Nov 2014 13:49:57 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415800197.84.0.217089035131.issue22827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The Windows installer integration backport is in issue 22850.

Reviewing that made me release that the parallel version section in https://docs.python.org/3/installing/#work-with-multiple-versions-of-python-installed-in-parallel may need tweaking to account for the fact that the "py" launcher only comes with Python 3.

That said, it's unlikely anyone will be wanting to switch between 2.6 and 2.7 on Windows at this point, so maybe we should just ignore it and wait and see if anyone complains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Wed Nov 12 14:58:25 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 12 Nov 2014 13:58:25 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1415800705.69.0.984909440317.issue22850@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

After digging a little further, I see Brian backported the PATH modification support from issue #3561 in https://hg.python.org/cpython/rev/a9d34685ec47

This should probably be noted in the What's New document - while it's not technically part of PEP 477, that's still a good home for it in the What's New doc.

The lack of the Python launcher in Python 2 likely isn't a problem - at this point in history, switching between Python 2 and 3 is the most likely scenario, and in that situation, the launcher would have been installed together with the Python 3 installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 16:06:27 2014
From: report at bugs.python.org (Stanislaw Pitucha)
Date: Wed, 12 Nov 2014 15:06:27 +0000
Subject: [issue22854] Documentation/implementation out of sync for IO
Message-ID: <1415804787.06.0.347049835041.issue22854@psf.upfronthosting.co.za>


New submission from Stanislaw Pitucha:

The docstring on for fileno() method says:

"An IOError is raised if the IO object does not use a file descriptor."

In reality, UnsupportedOperation is raised instead:

```
: io.StringIO().fileno()
UnsupportedOperation: fileno
```

----------
components: IO
messages: 231079
nosy: viraptor
priority: normal
severity: normal
status: open
title: Documentation/implementation out of sync for IO
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22854>
_______________________________________

From report at bugs.python.org  Wed Nov 12 16:08:34 2014
From: report at bugs.python.org (Stanislaw Pitucha)
Date: Wed, 12 Nov 2014 15:08:34 +0000
Subject: [issue22854] Documentation/implementation out of sync for IO
In-Reply-To: <1415804787.06.0.347049835041.issue22854@psf.upfronthosting.co.za>
Message-ID: <1415804914.79.0.224529704848.issue22854@psf.upfronthosting.co.za>


Stanislaw Pitucha added the comment:

Just in case: yes, UnsupportedOperation is an IOError - but shouldn't docstring here be more specific?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22854>
_______________________________________

From report at bugs.python.org  Wed Nov 12 16:24:01 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Nov 2014 15:24:01 +0000
Subject: [issue22849] Double DECREF in TextIOWrapper
In-Reply-To: <1415746526.05.0.824048300267.issue22849@psf.upfronthosting.co.za>
Message-ID: <1415805841.33.0.414962345385.issue22849@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Thanks for the excellent bug report!

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22849>
_______________________________________

From report at bugs.python.org  Wed Nov 12 16:24:13 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Nov 2014 15:24:13 +0000
Subject: [issue22849] Double DECREF in TextIOWrapper
In-Reply-To: <1415746526.05.0.824048300267.issue22849@psf.upfronthosting.co.za>
Message-ID: <20141112152405.4055.91735@psf.io>


Roundup Robot added the comment:

New changeset ec1948191461 by Benjamin Peterson in branch '3.4':
fix possible double free in TextIOWrapper.__init__ (closes #22849)
https://hg.python.org/cpython/rev/ec1948191461

New changeset a664b150b6c2 by Benjamin Peterson in branch 'default':
merge 3.4 (#22849)
https://hg.python.org/cpython/rev/a664b150b6c2

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22849>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:05:03 2014
From: report at bugs.python.org (Eric Haszlakiewicz)
Date: Wed, 12 Nov 2014 17:05:03 +0000
Subject: [issue22855] csv writer with blank lineterminator breaks quoting
Message-ID: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>


New submission from Eric Haszlakiewicz:

I'm trying to emit a single line of csv without any line terminators, but specifying lineterminator=None results in a "lineterminator must be set" error, and setting lineterminator='' results in lack of quotes around certain fields.

    with open("foo.csv", "wb") as csvfile:
        csvw = csv.writer(csvfile, quoting=csv.QUOTE_MINIMAL, lineterminator='')
        csvw.writerow(["col1","col2\ndata", "col3"])

I expected the contents of the file to be:
    col1,"col2
    data",col3

It should be possible to change the lineterminator without changing the quoting behavior.
At the very least, the documentation needs to explain better what logic is used to determine whether something gets quoted, and what affects that.

----------
components: Library (Lib)
messages: 231083
nosy: Eric.Haszlakiewicz
priority: normal
severity: normal
status: open
title: csv writer with blank lineterminator breaks quoting
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22855>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:30:32 2014
From: report at bugs.python.org (shayan)
Date: Wed, 12 Nov 2014 17:30:32 +0000
Subject: [issue22856] Function Summons
Message-ID: <1415813432.04.0.821666971594.issue22856@psf.upfronthosting.co.za>


New submission from shayan:

Hi Everybody...
I'm SH4Y4N From Ashiyane Digital Security Team....
I found the Bug "Function Summons" From Python 2.7...
When You Try To  Summons some Function It's Regular...
But What Happend When You're Calling two Function Simultaneous?
Your 2 Functions Run But the thing is that It contain some Error...
That's Strange To Run Some Code Within Some Traceback Error....
I Could Take You SOme Tips To Prevent this Action...
=-=-=-=
def Ashiyane():
  print 'Ashiyane Digital Security Team'

def Shayan():
  print "Bug Hunter For Ever"

print Shayan()+Ashiyane()

Show :
Bug Hunter For Ever
Ashiyane Digital Security Team

Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    k()+h()
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
=-=-=-=
You See The result....
=-=-=-=
Special Tnx To : Angel--D3m0n , C4T , MR.CICILI

----------
components: Build
files: bug.py
messages: 231084
nosy: SH4Y4N
priority: normal
severity: normal
status: open
title: Function Summons
versions: Python 2.7
Added file: http://bugs.python.org/file37186/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22856>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:30:57 2014
From: report at bugs.python.org (=?utf-8?b?0JDRgNGC0ZHQvCDQodC60L7RgNC10YbQutC40Lk=?=)
Date: Wed, 12 Nov 2014 17:30:57 +0000
Subject: [issue22857] strftime should support %f to print milliseconds
Message-ID: <1415813457.86.0.468998367577.issue22857@psf.upfronthosting.co.za>


New submission from ????? ?????????:

Now you cannot get milli (micro) seconds using strftime. It should be fixed.

AFAIK %f should be the right pattern for this

----------
messages: 231085
nosy: tonn81
priority: normal
severity: normal
status: open
title: strftime should support %f to print milliseconds
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22857>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:31:12 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:31:12 +0000
Subject: [issue22855] csv writer with blank lineterminator breaks quoting
In-Reply-To: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>
Message-ID: <1415813472.18.0.569377428939.issue22855@psf.upfronthosting.co.za>


R. David Murray added the comment:

If the line terminator is not \n, there is no reason to quote values with \n in them.  (Try your code with lineterminator set to 'd' to see what I mean.)

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22855>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:32:13 2014
From: report at bugs.python.org (=?utf-8?b?0JDRgNGC0ZHQvCDQodC60L7RgNC10YbQutC40Lk=?=)
Date: Wed, 12 Nov 2014 17:32:13 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1415813533.89.0.369953231878.issue16991@psf.upfronthosting.co.za>


????? ????????? added the comment:

Any progress? It was planned for 3.5 release

----------
nosy: +tonn81

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:37:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:37:39 +0000
Subject: [issue22855] csv writer with blank lineterminator breaks quoting
In-Reply-To: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>
Message-ID: <1415813859.24.0.623525412645.issue22855@psf.upfronthosting.co.za>


R. David Murray added the comment:

Also, it is hard to see how to make this clearer:

csv.QUOTE_MINIMAL
Instructs writer objects to only quote those fields which contain special characters such as delimiter, quotechar or any of the characters in lineterminator.

Hmm.  Perhaps it would be a bit clearer if it said "... which contain the special characters delimiter, quotechar, ..."

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22855>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:37:50 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:37:50 +0000
Subject: [issue22855] csv writer with blank lineterminator breaks quoting
In-Reply-To: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>
Message-ID: <1415813870.62.0.103956759063.issue22855@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22855>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:43:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:43:32 +0000
Subject: [issue22856] Function Summons
In-Reply-To: <1415813432.04.0.821666971594.issue22856@psf.upfronthosting.co.za>
Message-ID: <1415814212.31.0.721267084549.issue22856@psf.upfronthosting.co.za>


R. David Murray added the comment:

I have to tell you, I almost closed this as spam due to the spamish prose styling of the text.

Please read the python tutorial, or email the python-tutors list if you want to learn more about why your code produced the results it did.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22856>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:45:55 2014
From: report at bugs.python.org (Ben Finney)
Date: Wed, 12 Nov 2014 17:45:55 +0000
Subject: [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415814355.25.0.0850788834647.issue22843@psf.upfronthosting.co.za>


Ben Finney added the comment:

The current wording of the passage ?Match objects always have a boolean value of True? implies that the value compares equal to the ?True? constant. That implication is incorrect.

I disagree with R. David Murray; if we want to say that a value is considered true *in a boolean context*, that's very different from saying it has the ?True? value.

Georg, ?evaluates true in a boolean context? has the meaning you're seeking; it is chosen precisely because it does *not* imply equality to the True constant.

----------
nosy: +bignose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22843>
_______________________________________

From report at bugs.python.org  Wed Nov 12 18:57:46 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:57:46 +0000
Subject: [issue22857] strftime should support %f to print milliseconds
In-Reply-To: <1415813457.86.0.468998367577.issue22857@psf.upfronthosting.co.za>
Message-ID: <1415815066.71.0.31091856613.issue22857@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are talking about time.strftime, I presume.  datetime supports %f.  time.strftime does not, because it wraps the system strftime, and that does not support %f (at least not on my linux system).

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22857>
_______________________________________

From report at bugs.python.org  Wed Nov 12 19:19:15 2014
From: report at bugs.python.org (Brett Hannigan)
Date: Wed, 12 Nov 2014 18:19:15 +0000
Subject: [issue22848] Subparser help does not respect SUPPRESS argument
In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>
Message-ID: <1415816355.78.0.678359265207.issue22848@psf.upfronthosting.co.za>


Changes by Brett Hannigan <bhannigan at dnanexus.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file37187/argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22848>
_______________________________________

From report at bugs.python.org  Wed Nov 12 20:55:17 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 12 Nov 2014 19:55:17 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1415822117.07.0.758301458827.issue22853@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22853>
_______________________________________

From report at bugs.python.org  Wed Nov 12 21:52:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Nov 2014 20:52:31 +0000
Subject: [issue12499] textwrap.wrap: add control for fonts with different
 character widths
In-Reply-To: <1309835004.91.0.584156217993.issue12499@psf.upfronthosting.co.za>
Message-ID: <1415825551.98.0.346222974548.issue12499@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Both approaches can be combined. It could be a regular overridable method, and it could be overridded for an instance if corresponding argument is specified. See the default method and parameter of JSON encoder.

I slightly hesitate about the name. Is "width_func" the best of names?

----------
nosy: +serhiy.storchaka
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12499>
_______________________________________

From report at bugs.python.org  Wed Nov 12 21:53:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Nov 2014 20:53:33 +0000
Subject: [issue21090] File read silently stops after EIO I/O error
In-Reply-To: <1396045786.33.0.781369785301.issue21090@psf.upfronthosting.co.za>
Message-ID: <1415825613.73.0.608402450385.issue21090@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On IRC, buck1 asked why the following code behaves differently on Python < 3.4 and Python >= 3.4. It is related to this issue in fact.

Code:
---
from __future__ import print_function

from os import openpty
read, write = openpty()

from subprocess import Popen
proc = Popen(
    ('echo', 'ok'),
    stdout=write,
    close_fds=True,
)

from os import fdopen
fdopen(write, 'w').close()
with fdopen(read) as stdout:
    print('STDOUT', stdout.read())

print('exit code:', proc.wait())
---

Simplified example:
---
import io, os
read, write = os.openpty()
os.write(write, b'ok\n')
os.close(write)
with io.FileIO(read, closefd=False) as fp:
    print(fp.readall())
---

On Python < 3.4, it displays "ok", whereas Python 3.4 and later fail with 
OSError(5, 'Input/output error' on readall().

Another example:
---
import os
read, write = os.openpty()
os.write(write, b'ok\n')
os.close(write)
print("read: %r" % os.read(read, 4096))
print("read: %r" % os.read(read, 4096))
---

The first read syscall succeed, even if the write end is already called. But the second read syscall fails with EIO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21090>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:09:24 2014
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Nov 2014 21:09:24 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1415826564.97.0.887273336509.issue22850@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yes, I'll add Scripts into the PATH when that option is enabled too. I ignored that from the changeset I merged from, forgetting that that's where pip.exe will end up.

I'd rather not bundle the launcher with Python 2 right now (if ever). With the 3.5 installer it's going to be a much smoother ride as far as upgrades go (or having a standalone installer, which is basically what it is), and the more versions that try to fight with that one the harder people will find things.

Hopefully I have time to finish this off tonight, otherwise it may not be done until next week, as I'm very busy the next few days.

(Thanks Brian for the feedback on the review.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:18:48 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 12 Nov 2014 21:18:48 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1415827128.55.0.291723250593.issue22852@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Wed Nov 12 22:36:26 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 12 Nov 2014 21:36:26 +0000
Subject: [issue22854] Documentation/implementation out of sync for IO
In-Reply-To: <1415804787.06.0.347049835041.issue22854@psf.upfronthosting.co.za>
Message-ID: <1415828186.44.0.407198297841.issue22854@psf.upfronthosting.co.za>


Martin Panter added the comment:

Similarly for the readable(), seekable() and writable() documentation

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22854>
_______________________________________

From report at bugs.python.org  Thu Nov 13 00:19:42 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 23:19:42 +0000
Subject: [issue22848] Subparser help does not respect SUPPRESS argument
In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>
Message-ID: <1415834382.96.0.0347864312872.issue22848@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22848>
_______________________________________

From report at bugs.python.org  Thu Nov 13 02:54:01 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 13 Nov 2014 01:54:01 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1415843641.66.0.388654215875.issue22827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ned pointed out the wording regarding the Makefile changes in PEP 477 was ambiguous.

My intent was for the changes to be backported, just with ENSUREPIP defaulting to "no" rather than "upgrade".

So that part of the backport is still on the todo list (Ned's offered to handle that in addition to the Mac OS X installer changes)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 13 04:03:06 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 13 Nov 2014 03:03:06 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <20141113030255.118105.98065@psf.io>


Roundup Robot added the comment:

New changeset c248a6bdc1d7 by Steve Dower in branch '2.7':
Issue #22850: Backport ensurepip Windows installer changes to 2.7
https://hg.python.org/cpython/rev/c248a6bdc1d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Thu Nov 13 07:32:07 2014
From: report at bugs.python.org (paul j3)
Date: Thu, 13 Nov 2014 06:32:07 +0000
Subject: [issue22848] Subparser help does not respect SUPPRESS argument
In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>
Message-ID: <1415860327.78.0.806929274231.issue22848@psf.upfronthosting.co.za>


paul j3 added the comment:

A notational point - you are adding a subparser, not an argument, to the subparsers action.  

Why would a user want to use `help=argparse.SUPPRESS`, as  opposed to simply omitting the `help` parameter?  The effect would be the same as your patch.

Another possibility is to interpret this SUPPRESS as meaning, omit the subparser (and it's aliases?) from the choices list(s) as well.  In other words, make this an entirely stealth choice.

    usage: test [-h] {foo} ...
    positional arguments:
      {foo}
        foo       This is help for foo
        ...

'test bar -h' would still display a help for that subparser (unless given a `add_help=False` parameter).

I don't know how much work this stronger SUPPRESS would required, or whether such an interpretation would be intuitive to most users.  There isn't a mechanism to omit a regular argument from the usage, so why should there be a mechanism for omitting a subparsers choice from usage?

With the weaker interpretation, this patch fills in a hole in the logic, but doesn't add any functionality (that I can think of).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22848>
_______________________________________

From report at bugs.python.org  Thu Nov 13 10:46:29 2014
From: report at bugs.python.org (Stian Soiland-Reyes)
Date: Thu, 13 Nov 2014 09:46:29 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1415871989.55.0.214093610086.issue22852@psf.upfronthosting.co.za>


Stian Soiland-Reyes added the comment:

I tried to make a patch for this, but I found it quite hard as the urllib/parse.py is fairly low-level, e.g. it is constantly encoding/decoding bytes and strings within each URI component. Basically the code assumes there are tuples of strings, with support for both bytes and strings baked in later.

As you see in 

https://github.com/stain/cpython/compare/issue-2285-urllib-empty-fragment?expand=1

the patch in parse.py is small - but the effect of that in test_urlparse.py is a bit bigger, as lots of test are testing for the result of urlsplit to have '' instead of None. It is uncertain how much real-life client code also check for '' directly. ("if not p.fragment" would of course still work - but "if p.fragment == ''" would not work anymore.

I therefore suggest an alternative to my patch above - to add some boolean fields like has_fragment, thus the existing component fields can keep their backwards compatible '' and b'' values even when a component is actually missing, and yet allowing geturl() to reconstitute the URI according to the RFC.

----------
hgrepos: +279

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:21:29 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:21:29 +0000
Subject: [issue22431] Change format of test runner output
In-Reply-To: <1410961478.22.0.708066565645.issue22431@psf.upfronthosting.co.za>
Message-ID: <1415874089.54.0.154083116095.issue22431@psf.upfronthosting.co.za>


Robert Collins added the comment:

Yes, making customising the output easier is a good thing. One way is to use e.g. subunit.run (which can work with all unittest versions since 2.6) and write a custom filter. Or a custom TestResult and TextTestRunner can work too :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22431>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:23:24 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:23:24 +0000
Subject: [issue22858] unittest.__init__:main shadows unittest.main
Message-ID: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>


New submission from Robert Collins:

This is just an ugly/hygiene thing. Since we've never advertised the submodules as the API, we should be able to fix this by moving main.py to e.g. __main__.py.

----------
messages: 231101
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest.__init__:main shadows unittest.main

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22858>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:23:36 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:23:36 +0000
Subject: [issue22858] unittest.__init__:main shadows unittest.main
In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>
Message-ID: <1415874216.38.0.755798056118.issue22858@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22858>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:25:22 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:25:22 +0000
Subject: [issue22859] unittest.TestProgram.usageExit no longer invoked
Message-ID: <1415874322.06.0.308310544849.issue22859@psf.upfronthosting.co.za>


New submission from Robert Collins:

Before the argparse migration usageExit was invoked and could be extended via subclasses, but it no longer is. We could delete it (and document it being no longer accessible) or put some glue in to reinstate it. I think deleting it is fine, as long as we make the argparse parser objects part of the API (so that folk have a reliable place to poke at to change help).

----------
messages: 231102
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest.TestProgram.usageExit no longer invoked

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22859>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:25:31 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:25:31 +0000
Subject: [issue22859] unittest.TestProgram.usageExit no longer invoked
In-Reply-To: <1415874322.06.0.308310544849.issue22859@psf.upfronthosting.co.za>
Message-ID: <1415874331.65.0.982734088796.issue22859@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22859>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:29:51 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 13 Nov 2014 10:29:51 +0000
Subject: [issue22860] unittest TestProgram hard to extend
Message-ID: <1415874591.06.0.535535954312.issue22860@psf.upfronthosting.co.za>


New submission from Robert Collins:

Some users of TestProgram would like to add options (e.g. testtools.run adds --list and --load-list) but there isn't a clean point to add them without bulk copying the implementation around.

We likely need some extra extension points as well - one reasonable test would be to make sure that testtools.run's TestProgram can be made much smaller by whatever patch fixes this bug.

----------
components: Library (Lib)
messages: 231103
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest TestProgram hard to extend
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22860>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:31:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Nov 2014 10:31:44 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415874704.96.0.992496586761.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which is closer to current code but solves complexity issue and also fixes some bugs in current code.

$ ./python -c "import textwrap; print(textwrap.wrap('this-is-a-useful-feature', width=1, break_long_words=False))"
['this-', 'is-a', '-useful-', 'feature']
$ ./python -c "import textwrap; print(textwrap.wrap('what-d\x27you-call-it.', width=1, break_long_words=False))"
['what-d', "'you-", 'call-', 'it.']

----------
versions: +Python 2.7, Python 3.4
Added file: http://bugs.python.org/file37188/wordsplit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 11:50:57 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 13 Nov 2014 10:50:57 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415875857.51.0.653124894905.issue22687@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 12:00:17 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 11:00:17 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415876417.04.0.905275200865.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't understand:

+        expect = ("this-|is-a-useful-|feature-|for-|"
+                  "reformatting-|posts-|from-|tim-|peters'ly").split('|')
+        self.check_wrap(text, 1, expect, break_long_words=False)
+        self.check_split(text, expect)

Why would "is-a-useful" remain unsplit? It looks like you're making up new rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 12:00:49 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 11:00:49 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415876449.37.0.899806225825.issue22687@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions:  -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 13:49:56 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 12:49:56 +0000
Subject: [issue22860] unittest TestProgram hard to extend
In-Reply-To: <1415874591.06.0.535535954312.issue22860@psf.upfronthosting.co.za>
Message-ID: <1415882996.85.0.625744231294.issue22860@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/issue22860>
_______________________________________

From report at bugs.python.org  Thu Nov 13 13:50:56 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 12:50:56 +0000
Subject: [issue22860] unittest TestProgram hard to extend
In-Reply-To: <1415874591.06.0.535535954312.issue22860@psf.upfronthosting.co.za>
Message-ID: <1415883056.62.0.483772984205.issue22860@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For another example use case:
https://github.com/numba/numba/blob/master/numba/tests/__init__.py#L22

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22860>
_______________________________________

From report at bugs.python.org  Thu Nov 13 13:52:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2014 12:52:29 +0000
Subject: [issue22861] [2.7] ssl._dnsname_match() and unicode
Message-ID: <1415883149.43.0.395853503644.issue22861@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi,

I just modified the Trollius project ( http://trollius.readthedocs.org/ ) to support Python 2.7 with the newly backported ssl module. I ran the test suite of the Trollius and some tests are failing because of the exact exception message.

It looks like ssl._dnsname_match() calls repr() on a Unicode string:

    elif len(dnsnames) == 1:
        raise CertificateError("hostname %r "
            "doesn't match %r"
            % (hostname, dnsnames[0]))

Well, I don't know if using repr() on an unicode string is really a bug or not.

By the way, Trollius currently pass the hostname as a bytes string, whereas match_hostname() uses Unicode. No error is raised. Is it safe to compare bytes and Unicode to validate a certificate?

dnsname[0] comes from the commonName of the certificate subject.

The certificate used in Trollius test can be found at:
https://bitbucket.org/enovance/trollius/src/d456dd5103b0e2a35ef27fe0d55583b74a8196dd/tests/keycert3.pem?at=trollius

Example of error:

======================================================================
FAIL: test_create_server_ssl_match_failed (test_events.EPollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_events.py", line 951, in test_create_server_ssl_match_failed
    self.loop.run_until_complete(f_c)
  File "/home/haypo/prog/HG/trollius/trollius/test_utils.py", line 137, in __exit__
    expected_regex.pattern, str(exc_value)))
  File "/home/haypo/prog/HG/trollius/trollius/test_utils.py", line 75, in _raiseFailure
    raise self.test_case.failureException(msg)
AssertionError: "hostname '127.0.0.1' doesn't match 'localhost'" does not match "hostname '127.0.0.1' doesn't match u'localhost'"

----------
messages: 231108
nosy: alex, haypo
priority: normal
severity: normal
status: open
title: [2.7] ssl._dnsname_match() and unicode
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22861>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:05:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2014 13:05:29 +0000
Subject: [issue22861] [2.7] ssl._dnsname_match() and unicode
In-Reply-To: <1415883149.43.0.395853503644.issue22861@psf.upfronthosting.co.za>
Message-ID: <1415883929.16.0.506427402469.issue22861@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I worked around this issue by expecting a different error message on Python 2 and Python 3:
https://bitbucket.org/enovance/trollius/commits/be404685d3fd8ba008e1a577438dc6f23b01c63a?at=trollius

+        if compat.PY3:
+            err_msg = "hostname '127.0.0.1' doesn't match 'localhost'"
+        else:
+            # http://bugs.python.org/issue22861
+            err_msg = "hostname '127.0.0.1' doesn't match u'localhost'"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22861>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:16:20 2014
From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=)
Date: Thu, 13 Nov 2014 13:16:20 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
Message-ID: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>


New submission from Florian H?ch:

If 'top' is an unicode directory name, os.listdir can still return non-unicode filenames if they can't be decoded. This case is not handled in the Python 2.x standard library version of os.walk and will cause join(top, name) to fail on such filenames with an UnicodeDecodeError.

----------
components: Library (Lib)
messages: 231110
nosy: fhoech
priority: normal
severity: normal
status: open
title: os.walk fails on undecodable filenames
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:23:11 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2014 13:23:11 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415884991.41.0.751151458319.issue22862@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is your OS?

----------
components: +Unicode
nosy: +ezio.melotti, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 14:30:54 2014
From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=)
Date: Thu, 13 Nov 2014 13:30:54 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415885454.74.0.162950655527.issue22862@psf.upfronthosting.co.za>


Florian H?ch added the comment:

This problem only affects Linux as far as I know (in my case I'm using Fedora 21 Beta).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:28:38 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2014 14:28:38 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
Message-ID: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The documentation shown for Python 2.7.8 currently includes 2.7.9 parts, e.g. for the ssl modules (https://docs.python.org/2.7/library/ssl.html).

Since there were so many changes to the ssl module for 2.7.9 which are not available in 2.7.8, I think it would be good to be able to not only select "2.7.8" from the doc version drop-down, but to also really get that particular version of the documentation, and provide a separate "2.7.9" snapshop as well.

I tried https://docs.python.org/2.7.8/library/ssl.html, but that doesn't seem to exist.

PS: I'm not sure whether this is the right tracker to report this. Feel free to move it elsewhere.

----------
assignee: docs at python
components: Documentation
messages: 231113
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: https://docs.python.org/ should make a true 2.7.8 version available
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:36:00 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Nov 2014 14:36:00 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1415889360.91.0.638324297642.issue22863@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

There's https://docs.python.org/release/2.7.8/

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:40:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2014 14:40:44 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415889644.51.0.866465652984.issue22862@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Your problem has two solutions.

1) Upgrade to Python 3 which handles correctly your use case (thanks to the PEP 383, surrogateescape error handler)

2) Only process filenames as bytes, and encode/decode manually (so you can decide how to handle undecodable filenames)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:43:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Nov 2014 14:43:04 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415889784.57.0.183690198962.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is old rule. \w{2,}-(?=\w{2,} -- single letter shouldn't be separated. But there was a bug in such simple regex, it splits a word after non-word character (in particular apostrophe or hyphen) if it followed by word characters and hyphen. There were attempts to fix this bug in issue596434 and issue965425 but they missed a cases when non-word character is occurred inside a word.

Originally I had assigned this issue only to 3.5 because I supposed that the solution needs either new features in re or backward-incompatible changes to word splitting algorithm. But found solution doesn't require 3.5-only features, doesn't change interface, and fixes performance and behavior bugs. So I think it should be applied to maintained releases too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:50:07 2014
From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=)
Date: Thu, 13 Nov 2014 14:50:07 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415890207.26.0.229216785095.issue22862@psf.upfronthosting.co.za>


Florian H?ch added the comment:

1) Is not yet possible for me unfortunately, some libraries I require are not yet available for Python 3 (but in the long run, this would be my preferred solution)

2) Would necessitate too many changes in a carefully crafted, unicode-only application. I think I'll just override os.listdir and filter out filenames that are not decodable, or override os.walk and do something equivalent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 15:57:11 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Nov 2014 14:57:11 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415890631.71.0.931215980085.issue22862@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> 1) Is not yet possible for me unfortunately, some libraries I require are not yet available for Python 3 (but in the long run, this would be my preferred solution)

I'm curious, which libraries?

Oh, I forgot to say that it's not possible to fix this issue in Python 2. Backporting the PEP 383 in Python 2 requires deep changes in the Unicode machinery, starting by the UTF-8 codec. Currently, the UTF-8 encoder encodes surrogates which violates Unicode standard and makes impossible to use this codec with the surrogateescape error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:11:57 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Nov 2014 15:11:57 +0000
Subject: [issue22858] unittest.__init__:main shadows unittest.main
In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>
Message-ID: <1415891517.26.0.141546355238.issue22858@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm afraid that just because we don't advertise it doesn't mean it isn't used.  On the other hand, the split into submodules is relatively recent, so maybe we could get away with it without a deprecation cycle.  I'd like other developers opinions on that.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22858>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:15:54 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Nov 2014 15:15:54 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415891754.76.0.416273212399.issue22862@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:16:27 2014
From: report at bugs.python.org (=?utf-8?q?Florian_H=C3=B6ch?=)
Date: Thu, 13 Nov 2014 15:16:27 +0000
Subject: [issue22862] os.walk fails on undecodable filenames
In-Reply-To: <1415884580.23.0.285247729287.issue22862@psf.upfronthosting.co.za>
Message-ID: <1415891787.68.0.165748410501.issue22862@psf.upfronthosting.co.za>


Florian H?ch added the comment:

> I'm curious, which libraries?

wxPython and wexpect (wexpect I could probably port myself, so the problem is mainly with wx)

> Oh, I forgot to say that it's not possible to fix this issue in Python 2. Backporting the PEP 383 in Python 2 requires deep changes in the Unicode machinery, starting by the UTF-8 codec.

Ok, that's understandable of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22862>
_______________________________________

From report at bugs.python.org  Thu Nov 13 16:23:03 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 15:23:03 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415892183.04.0.416428933425.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> This is old rule. \w{2,}-(?=\w{2,} -- single letter shouldn't be separated.

I don't agree. This was an implementation detail. There was no test, and it wasn't specified anywhere.
If you think single letter shouldn't be separated, there should be some grammatical or typographical reference on the Internet to prove it.

> There were attempts to fix this bug in issue596434 and issue965425 

Those don't seem related to single letters between hyphens.

> But found solution doesn't require 3.5-only features, doesn't change interface, and fixes performance and behavior bugs.

It does change behaviour in ways that could break existing code. The textwrap behaviour is underspecified so it's not ok to assume that previous behaviour was obviously buggy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 17:03:21 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Nov 2014 16:03:21 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415894601.54.0.0163809597342.issue22687@psf.upfronthosting.co.za>


R. David Murray added the comment:

https://owl.english.purdue.edu/owl/resource/576/01/

Rule 8.

So, no, in the middle of the word single letters aren't a problem, only at the beginning or the end of the word.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 17:20:20 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 13 Nov 2014 16:20:20 +0000
Subject: [issue22600] In Multiprocessing Queue() doesn't work with list :
 __.put(list) != __.get()
In-Reply-To: <1412941993.11.0.215678273609.issue22600@psf.upfronthosting.co.za>
Message-ID: <1415895620.1.0.327825105625.issue22600@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

"solution.put(c)" takes a *reference* to the list c.
And then the test() function continues running!

By the time the list is serialized and sent back to the main process (in another thread), the test() function has already changed it...

As you noticed, you can use immutable objects instead (string, int), or make a copy of the list: solution.put(c.copy())

----------
nosy: +amaury.forgeotdarc
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22600>
_______________________________________

From report at bugs.python.org  Thu Nov 13 18:35:27 2014
From: report at bugs.python.org (Mike Drob)
Date: Thu, 13 Nov 2014 17:35:27 +0000
Subject: [issue22864] Add filter to multiprocessing.Pool
Message-ID: <1415900127.9.0.960876191139.issue22864@psf.upfronthosting.co.za>


New submission from Mike Drob:

Being able to use a pool to easily run 'map' over an iterable is very powerful, but it would also be nice to run 'filter' (or potentially 'ifilter' or 'filter_async', in keeping with the patterns already present).

----------
components: Library (Lib)
messages: 231124
nosy: Mike.Drob
priority: normal
severity: normal
status: open
title: Add filter to multiprocessing.Pool
type: enhancement
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22864>
_______________________________________

From report at bugs.python.org  Thu Nov 13 18:39:24 2014
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 13 Nov 2014 17:39:24 +0000
Subject: [issue22462] Modules/pyexpat.c violates PEP 384
In-Reply-To: <1411401083.5.0.108064936526.issue22462@psf.upfronthosting.co.za>
Message-ID: <1415900364.15.0.111000641747.issue22462@psf.upfronthosting.co.za>


Matthias Klose added the comment:

according to  https://jenkins.qa.ubuntu.com/job/vivid-adt-python3.4/7/

test.test_pyexpat.HandlerExceptionTest now fails, but only when running in the installed location, not when running the tests from the builddir. any idea why?

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22462>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:01:26 2014
From: report at bugs.python.org (Geoff Shannon)
Date: Thu, 13 Nov 2014 18:01:26 +0000
Subject: [issue22865] Allow pty.spawn to ignore data to copy
Message-ID: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>


New submission from Geoff Shannon:

While using the pty.py module I had cause to want to be able to silently eat characters from the input stream.  I discovered that because of the check for end of file being "if not data" that there was no way to do this.

Since the default function used by spawn and _copy is a thin wrapper on os.read, I figured that it would be useful to interpret None as a sentinel value meaning "this is not EOF, but there's nothing I actually want to copy over."

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: pty.patch
keywords: patch
messages: 231126
nosy: RadicalZephyr, docs at python
priority: normal
severity: normal
status: open
title: Allow pty.spawn to ignore data to copy
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/file37189/pty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22865>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:18:23 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Nov 2014 18:18:23 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415902703.01.0.412835663607.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you David. If splitting single letter surrounded with hyphens is desirable, here is more complicated patch which does this. It deviates from original code more, but it doesn't look break any reasonable example.

> The textwrap behaviour is underspecified so it's not ok to assume that previous behaviour was obviously buggy.

Aren't ['this-', 'is-a', '-useful-', 'feature'] and ['what-d', "'you-", 'call-', 'it.'] obvious bugs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:19:03 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Nov 2014 18:19:03 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415902743.39.0.892951497004.issue22687@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file37190/wordsplit_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:19:54 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 18:19:54 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415902794.49.0.468597824542.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To clarify, I would be fine with the previous patch if it didn't add the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:21:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 18:21:26 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415902886.34.0.79983295576.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Aren't ['this-', 'is-a', '-useful-', 'feature'] and
> ['what-d', "'you-", 'call-', 'it.'] obvious bugs?

Obvious according to which rules?

If we want to improve the behaviour of textwrap, IMHO it should be in a separate issue. And someone would have to study the word-wrapping rules of the English language :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:42:08 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Nov 2014 18:42:08 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415904128.84.0.327023929585.issue22687@psf.upfronthosting.co.za>


R. David Murray added the comment:

What I usually do in cases like this is to add the tests but mark them with comments saying that the tests test current behavior but are not testing parts of the (currently defined) API.  That way you know if a change changes behavior and then can decide if that is a problem or not, as opposed to inadvertently changing behavior and only finding out when the bug reports roll in :)

But yeah, defining the rules textwrap should follow is a different issue than the performance issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:49:07 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Nov 2014 18:49:07 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415904547.73.0.649238122477.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> To clarify, I would be fine with the previous patch if it didn't add the tests.

The absent of tests could cause introducing new non-detected bugs and reappearing old bugs.

> Obvious according to which rules?

If you think a word should be splitted before hyphen or apostrophe, there should be some grammatical or typographical reference on the Internet to prove it.

I would be fine with moving the fix of textwrap behavior to a separate issue, but what to do with this issue then? We have not a patch which only fixes performance complexity and doesn't change the behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:53:05 2014
From: report at bugs.python.org (David Wilson)
Date: Thu, 13 Nov 2014 18:53:05 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1415904785.79.0.669595612591.issue14099@psf.upfronthosting.co.za>


David Wilson added the comment:

Per my comment on issue16569, the overhead of performing one seek before each (raw file data) read is quite minimal. I have attached a new (but incomplete) patch, on which the following microbenchmarks are based. The patch is essentially identical to Stepan's 2012 patch, except I haven't yet decided how best to preserve the semantics of ZipFile.close().

"my.zip" is the same my.zip from issue22842. It contains 10,000 files each containing 10 bytes over 2 lines.

"my2.zip" contains 8,000 files each containing the same copy of 64kb of /dev/urandom output. The resulting ZIP is 500mb.

For each test, the first run is the existing zipfile module, and the second run is with the patch. In summary:

* There is a 35% perf increase in str mode when handling many small files (on OS X at least)
* There is a 6% perf decrease in file mode when handling small sequential reads.
* There is a 2.4% perf decrease in file mode when handling large sequential reads.


>From my reading of zipfile.py, it is clear there are _many_ ways to improve its performance (probably starting with readline()), and rejection of a functional fix should almost certainly be at the bottom of that list.


For each of the tests below, the functions used were:

    def a():
        """
        Test concurrent line reads to a str mode ZipFile.
        """
        zf = zipfile.ZipFile('my2.zip')
        members = [zf.open(n) for n in zf.namelist()]
        for m in members:
            m.readline()
        for m in members:
            m.readline()

    def c():
        """
        Test sequential small reads to a str mode ZipFile.
        """
        zf = zipfile.ZipFile('my2.zip')
        for name in zf.namelist():
            with zf.open(name) as zfp:
                zfp.read(1000)

    def d():
        """
        Test sequential small reads to a file mode ZipFile.
        """
        fp = open('my2.zip', 'rb')
        zf = zipfile.ZipFile(fp)
        for name in zf.namelist():
            with zf.open(name) as zfp:
                zfp.read(1000)

    def e():
        """
        Test sequential large reads to a file mode ZipFile.
        """
        fp = open('my2.zip', 'rb')
        zf = zipfile.ZipFile(fp)
        for name in zf.namelist():
            with zf.open(name) as zfp:
                zfp.read()


---- my.zip ----

$ python3.4 -m timeit -s 'import my' 'my.a()'
10 loops, best of 3: 1.47 sec per loop

$ python3.4 -m timeit -s 'import my' 'my.a()'
10 loops, best of 3: 950 msec per loop

---

$ python3.4 -m timeit -s 'import my' 'my.c()'
10 loops, best of 3: 1.3 sec per loop

$ python3.4 -m timeit -s 'import my' 'my.c()'
10 loops, best of 3: 865 msec per loop

---

$ python3.4 -m timeit -s 'import my' 'my.d()'
10 loops, best of 3: 800 msec per loop

$ python3.4 -m timeit -s 'import my' 'my.d()'
10 loops, best of 3: 851 msec per loop


---- my2.zip ----

$ python3.4 -m timeit -s 'import my' 'my.a()'
10 loops, best of 3: 1.46 sec per loop

$ python3.4 -m timeit -s 'import my' 'my.a()'
10 loops, best of 3: 1.16 sec per loop

---

$ python3.4 -m timeit -s 'import my' 'my.c()'
10 loops, best of 3: 1.13 sec per loop

$ python3.4 -m timeit -s 'import my' 'my.c()'
10 loops, best of 3: 892 msec per loop

---

$ python3.4 -m timeit -s 'import my' 'my.d()'
10 loops, best of 3: 842 msec per loop

$ python3.4 -m timeit -s 'import my' 'my.d()'
10 loops, best of 3: 882 msec per loop

---

$ python3.4 -m timeit -s 'import my' 'my.e()'
10 loops, best of 3: 1.65 sec per loop

$ python3.4 -m timeit -s 'import my' 'my.e()'
10 loops, best of 3: 1.69 sec per loop

----------
nosy: +dw
Added file: http://bugs.python.org/file37191/zipfile_concurrent_read_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Thu Nov 13 19:59:19 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2014 18:59:19 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
Message-ID: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

With the backport of the Python 3 ssl module, the default context options of the ssl module were changed.

While this provides better security in many cases, it also causes breakage with servers or clients which do not support TLSv1 and later.

The ssl module should provide a way to globally set the default context options to work around this to allow e.g. removing the OP_NO_SSLv3 option in order to get things to work again without having to change the application using the ssl module.

----------
components: Library (Lib)
messages: 231133
nosy: lemburg
priority: normal
severity: normal
status: open
title: ssl module in 2.7.9 should provide a way to configure default context options
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Thu Nov 13 20:09:25 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 13 Nov 2014 19:09:25 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>
Message-ID: <1415905765.57.0.445380546146.issue22866@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I recall it, this was discussed extensively on the python-dev mailing list.  Ideally someone should summarize that discussion here.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Thu Nov 13 21:52:37 2014
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Nov 2014 20:52:37 +0000
Subject: [issue22867] document behavior of calling atexit.register() while
 atexit._run_exitfuncs is running
Message-ID: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

A discussion on comp.lang.python about prettying up the "if __name__ == 'main__'" idiom led to a suggestion that a decorator could simple register the main function using atexit.register. That looks like it will work, but leaves open the possibility that while main() is running via atexit._run_exitfuncs, other exit functions might be registered.

As currently defined (at least in the Python version with 2.7), I think everything will work fine. Still, the behavior of adding new exit functions during exit is not defined. Would be kind of nice if this behavior was blessed, and then mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 231135
nosy: docs at python, skip.montanaro
priority: low
severity: normal
status: open
title: document behavior of calling atexit.register() while atexit._run_exitfuncs is running

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22867>
_______________________________________

From report at bugs.python.org  Thu Nov 13 21:57:55 2014
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 13 Nov 2014 20:57:55 +0000
Subject: [issue22867] document behavior of calling atexit.register() while
 atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1415912275.51.0.21906495217.issue22867@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/issue22867>
_______________________________________

From report at bugs.python.org  Thu Nov 13 22:03:35 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Nov 2014 21:03:35 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>
Message-ID: <1415912615.64.0.882579575703.issue22866@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Per http://legacy.python.org/dev/peps/pep-0476/#opting-out the only way to do these things is horrednously ugly because it's hardly (if ever) a good idea.

----------
nosy: +alex, benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Thu Nov 13 22:53:36 2014
From: report at bugs.python.org (Mateon1)
Date: Thu, 13 Nov 2014 21:53:36 +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: <1415915616.87.0.539543690225.issue2636@psf.upfronthosting.co.za>


Mateon1 added the comment:

Well, I found a bug with this module, on Python 2.7(.5), on Windows 7 64-bit when you try to compile a regex with the flags V1|DEBUG, the module crashes as if it wanted to call a builtin called "ascii".

The bug happened to me several times, but this is the regexp when the last one happened. http://paste.ubuntu.com/8993680/

I hope it's fixed, I really love the module and found it very useful to have PCRE regexes in Python.

----------
nosy: +Mateon1
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Nov 13 22:55:50 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2014 21:55:50 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
In-Reply-To: <1415912615.64.0.882579575703.issue22866@psf.upfronthosting.co.za>
Message-ID: <546528E0.3040105@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.11.2014 22:03, Benjamin Peterson wrote:
> 
> Benjamin Peterson added the comment:
> 
> Per http://legacy.python.org/dev/peps/pep-0476/#opting-out the only way to do these things is horrednously ugly because it's hardly (if ever) a good idea.

The point here is not about verification, it's about being able
to allow SSLv3 connections again, which the 2.7.9 version of the
ssl module disallows completely.

There are plenty devices and applications out there which don't
talk TLS and we're cutting these off without a good way to
re-enable Python 2.7 applications talk to these again.

The problem here is that Python 2's ssl module has never had a
way to access the SSL context directly, so the only way to work
around security risks of e.g. using SSLv2 for connections was
to either use SSLv3 (only) or TLSv1 (only).

This is due to the fact that OpenSSL doesn't allow you to specify
SSLv3 and later. You have to pin down the version or set up
a range that starts at SSLv2 and then disable protocols using
context options (which Python 2 has so far never exposed).

More conservative Python applications will have chosen SSLv3 as
a way to disable the broken SSLv2 support. I know that we did
in one of our applications.

Fortunately, the _ssl module itself doesn't have OP_NO_SSLv3
enabled per default, so custom protocol implementations are
probably not affected. Only the stdlib uses of SSL are.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Thu Nov 13 23:51:53 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 13 Nov 2014 22:51:53 +0000
Subject: [issue22858] unittest.__init__:main shadows unittest.main
In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>
Message-ID: <1415919113.85.0.575038226144.issue22858@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Numba subclasses unittest.main in order to add custom CLI options.
I agree the current unittest scheme is horrible, just we should find a way that's backwards-compatible.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22858>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:03:46 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Nov 2014 23:03:46 +0000
Subject: [issue22864] Add filter to multiprocessing.Pool
In-Reply-To: <1415900127.9.0.960876191139.issue22864@psf.upfronthosting.co.za>
Message-ID: <1415919826.34.0.136273879941.issue22864@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22864>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:20:23 2014
From: report at bugs.python.org (koobs)
Date: Thu, 13 Nov 2014 23:20:23 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1415920823.81.0.696000375518.issue22417@psf.upfronthosting.co.za>


koobs added the comment:

Builds failing on koobs-freebsd9 buildbot for:

3.x: since revision b2c17681404f80edae2ee4846db701104d942cc4
3.4: since revision 246c9570a75798a4757001620cf92cc8d2eba684 	

Attaching both initial build failure test logs.

----------
nosy: +koobs
Added file: http://bugs.python.org/file37192/koobs-freebsd9.python3x-build2357.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22417>
_______________________________________

From report at bugs.python.org  Fri Nov 14 00:51:54 2014
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 13 Nov 2014 23:51:54 +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: <1415922714.82.0.00810324138347.issue2636@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

@Mateon1: "I hope it's fixed"? Did you report it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:19:20 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Nov 2014 00:19:20 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1415924360.38.0.622625405619.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, go ahead and apply the clinic.py patch. Can you also make a separate mock patch and assign it to Michael Foord for review?

----------
assignee: larry -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:29:14 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Nov 2014 00:29:14 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>
Message-ID: <1415924954.68.0.211274859321.issue22866@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

But you can reenable SSLv3 by alerting the context and monkeypatching as described in the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:32:20 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 14 Nov 2014 00:32:20 +0000
Subject: [issue19777] Provide a home() classmethod on Path objects
In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za>
Message-ID: <1415925140.02.0.0549003343804.issue19777@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19777>
_______________________________________

From report at bugs.python.org  Fri Nov 14 01:35:07 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 14 Nov 2014 00:35:07 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1415925307.72.0.00604478343804.issue22687@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> What I usually do in cases like this is to add the tests but mark
> them with comments saying that the tests test current behavior but
> are not testing parts of the (currently defined) API.  That way
> you know if a change changes behavior and then can decide if that is
> a problem or not, as opposed to inadvertently changing behavior
> and only finding out when the bug reports roll in :)

That's a good idea!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Fri Nov 14 02:02:58 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 14 Nov 2014 01:02:58 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
In-Reply-To: <1415924954.68.0.211274859321.issue22866@psf.upfronthosting.co.za>
Message-ID: <546554B7.405@egenix.com>


Marc-Andre Lemburg added the comment:

On 14.11.2014 01:29, Benjamin Peterson wrote:
> 
> But you can reenable SSLv3 by alerting the context and monkeypatching as described in the PEP.

Well, I can monkeypatch the ssl module of course, but that's
not really the point here. I'm not talking about whether I can fix this
for myself or not.

The point here is that PEP 476 only addresses certificate validation, not
disabling of SSLv3 support.

AFAIK, there has been no discussion about this removal on python-dev or
in a PEP. The only place I found some discussion was on
http://bugs.python.org/issue22638, but that's targeting Python 3.5, not
a patch level release of Python or existing software.

Also note that all of the browsers mentioned in that ticket discussion
only disable the feature, but keep an option to reenable it. As it
stands, there's no simple option to do this for the ssl default
context short of monkeypatching ssl.OP_NO_SSLv3 = 0.

It would be better to add e.g. a global to the ssl module, so that
you can override the default context options easily and without
having to monkeypatch anything:

ssl.py:
DEFAULT_CONTEXT_OPTIONS = OP_NO_SSLv2 | OP_NO_SSLv3 | ...

myapp.py:
import ssl
# Reenable SSLv3 for myapp:
ssl.DEFAULT_CONTEXT_OPTIONS = ssl.DEFAULT_CONTEXT_OPTIONS & ~ssl.OP_NO_SSLv3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Fri Nov 14 02:19:45 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 14 Nov 2014 01:19:45 +0000
Subject: [issue22866] ssl module in 2.7.9 should provide a way to configure
 default context options
In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za>
Message-ID: <1415927985.22.0.516226451941.issue22866@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Hmm, since neither create_default_context() nor _create_stdlib_context() are used by any other stdlib modules, I guess the removal of SSLv3 doesn't really make much difference for existing Python 2.7 applications.

I was irritated by the function names implying that they are actually used in the Python 2.7 stdlib, which is not the case.

If they ever get used, having a way to change their defaults would be a good idea, though.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22866>
_______________________________________

From report at bugs.python.org  Fri Nov 14 02:55:49 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 01:55:49 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1415930149.7.0.66313833607.issue992389@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Belatedly agreeing with PJE on this one.

If concerns around circular imports continue to be raised in a post Python 3.5 world (with the issue 17636 change), then we can look at revisiting this again, but in the meantime, lets just go with the sys.modules fallback.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Fri Nov 14 02:56:17 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 01:56:17 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1415930177.1.0.00895768161089.issue992389@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
superseder:  -> Modify IMPORT_FROM to fallback on sys.modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Fri Nov 14 03:02:01 2014
From: report at bugs.python.org (koobs)
Date: Fri, 14 Nov 2014 02:02:01 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1415930521.18.0.646771832291.issue17293@psf.upfronthosting.co.za>


koobs added the comment:

koobs-freebsd10 buildbot broken on all branches since:

2.7: e80cb046e7641fb8a71dda8254d2e619cdd64480
3.4: ba4b31ed2952b65ca447f57fbd6d540ebc4b749c
3.x: 3e4f3cc4f1f9dbee8e0ed5df47f77baae2ad310c

Full (2.7) log attached.

======================================================================
ERROR: test_arp_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/test/test_uuid.py", line 312, in test_arp_getnode
    node = uuid._arp_getnode()
  File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/uuid.py", line 348, in _arp_getnode
    ip_addr = socket.gethostbyname(socket.gethostname())
gaierror: [Errno 8] hostname nor servname provided, or not known

----------
nosy: +koobs
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file37193/koobs-freebsd10-python27-build758.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Fri Nov 14 03:02:53 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 14 Nov 2014 02:02:53 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1415930573.23.0.826835261292.issue22834@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 14 03:08:12 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 14 Nov 2014 02:08:12 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1415930892.91.0.990809067583.issue22836@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Fri Nov 14 03:10:03 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 14 Nov 2014 02:10:03 +0000
Subject: [issue21724] resetwarnings doesn't reset warnings registry
In-Reply-To: <1402503104.19.0.836333157517.issue21724@psf.upfronthosting.co.za>
Message-ID: <1415931003.53.0.382797370202.issue21724@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21724>
_______________________________________

From report at bugs.python.org  Fri Nov 14 03:11:49 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 14 Nov 2014 02:11:49 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1415931109.45.0.122285963768.issue22831@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:34:23 2014
From: report at bugs.python.org (Yi Bai)
Date: Fri, 14 Nov 2014 06:34:23 +0000
Subject: [issue22868] Minor error in the example of filter()
Message-ID: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>


New submission from Yi Bai:

Hi, I suppose there is a minor error in the example of the filter() function in 5.1.3 part of the document.

------------------------------------------------------------------
filter(function, sequence) returns a sequence consisting of those items from the sequence for which function(item) is true. If sequence is a string or tuple, the result will be of the same type; otherwise, it is always a list. For example, to compute a sequence of numbers not divisible by 2 or 3:

>>>
>>> def f(x): return x % 2 != 0 and x % 3 != 0
...
>>> filter(f, range(2, 25))
[5, 7, 11, 13, 17, 19, 23]
------------------------------------------------------------------

I think what the example does is "to compute a sequence of numbers not divisible by 2 and 3", not "2 or 3".

----------
assignee: docs at python
components: Documentation
messages: 231149
nosy: docs at python, enchyisle
priority: normal
severity: normal
status: open
title: Minor error in the example of filter()
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Fri Nov 14 08:38:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2014 07:38:27 +0000
Subject: [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415950707.12.0.760010790338.issue22868@psf.upfronthosting.co.za>


Georg Brandl added the comment:

For me the text is correct.  However, it depends on parsing the English sentence in the right way, which can be confusing.  The prose means "not (divisible by 2 or 3)" which is equivalent to "not divisible by 2 and not divisible by 3", therefore the Python code has an "and" operator.

It would probably be best to remove the negation, which also removes the ambiguity: "compute a sequence of numbers divisible by 2 or 3" or such.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Fri Nov 14 11:05:40 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Nov 2014 10:05:40 +0000
Subject: [issue22300] PEP 446 What's New Updates for 2.7.9
In-Reply-To: <1409321309.08.0.340268748311.issue22300@psf.upfronthosting.co.za>
Message-ID: <20141114100525.29234.24383@psf.io>


Roundup Robot added the comment:

New changeset 0dacd614839c by Nick Coghlan in branch '2.7':
Close #22300 by tweaking 2.7.9 What's New announcements
https://hg.python.org/cpython/rev/0dacd614839c

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22300>
_______________________________________

From report at bugs.python.org  Fri Nov 14 11:07:20 2014
From: report at bugs.python.org (Yi Bai)
Date: Fri, 14 Nov 2014 10:07:20 +0000
Subject: [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415959640.9.0.523884474876.issue22868@psf.upfronthosting.co.za>


Yi Bai added the comment:

Ah yes. You are right, Georg.
And as you suggested, it might be better to remove this ambiguity, for people with poor parsing skills like me. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Fri Nov 14 11:13:50 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Nov 2014 10:13:50 +0000
Subject: [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <20141114101306.57224.59104@psf.io>


Roundup Robot added the comment:

New changeset 5dd835edde1e by Georg Brandl in branch '2.7':
Closes #22868: make example less ambiguous.
https://hg.python.org/cpython/rev/5dd835edde1e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Fri Nov 14 11:14:35 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2014 10:14:35 +0000
Subject: [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415960075.92.0.0561579170411.issue22868@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Done. Thanks for the report!

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Fri Nov 14 11:20:18 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2014 10:20:18 +0000
Subject: [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415960418.35.0.155351193142.issue22868@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:18:42 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 11:18:42 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
Message-ID: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

When working on the original reference implementation for PEP 432, I found it useful to split the startup & shutdown code out from the main entry points into the eval loop (see issue 22257 for more details).

However, that split made the draft implementation rather hard to maintain - any CPython commit that touched pythonrun.c was almost certain to cause a merge conflict.

The attached patch is a preliminary split into two separate modules, with pythonrun continuing to hold the main eval loop entry points, while the startup and shutdown code moves into pylifecycle.

This is an initial WIP patch (that nonetheless passes the test suite). I started work on it a few months ago, so I need to make sure that I've retained Victor's recent pythonrun changes.

----------
assignee: ncoghlan
files: split_pythonrun.diff
keywords: patch
messages: 231155
nosy: ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Split pylifecycle.c out from pythonrun.c
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37194/split_pythonrun.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:24:20 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 11:24:20 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1415964260.71.0.752291814213.issue22869@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Incorporated pythonrun changes from 668e0bf30042, 6aaa0aab1e93 and d6fb87972dee into pylifecycle

----------
Added file: http://bugs.python.org/file37195/split_pythonrun_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:28:15 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 11:28:15 +0000
Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence
In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za>
Message-ID: <1415964495.82.0.123997572318.issue22257@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 22869 now covers the preparatory refactoring to split pythonrun into two modules.

----------
dependencies: +Split pylifecycle.c out from pythonrun.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22257>
_______________________________________

From report at bugs.python.org  Fri Nov 14 12:47:19 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 14 Nov 2014 11:47:19 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1415965639.82.0.816987876775.issue22869@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Known issues with the current split:

* reference count printing is duplicated (lifecycle prints it at shutdown, pythonrun at the interactive prompt)

* pythonrun references PyInspect_Flag directly without an extern declaration

* This particular oddity wasn't introduced by this patch, but it turns out PyOptimize_Flag lives in compile.c, rather than with the other global flags in pythonrun.c. It's also declared as a public data API in pydebug.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 14 13:39:05 2014
From: report at bugs.python.org (Mateon1)
Date: Fri, 14 Nov 2014 12:39:05 +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: <1415968745.97.0.752424641997.issue2636@psf.upfronthosting.co.za>


Mateon1 added the comment:

Well, I am reporting it here, is this not the correct place? Sorry if it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Nov 14 14:51:49 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Nov 2014 13:51:49 +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: <1415973109.12.0.721903671885.issue2636@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/issue2636>
_______________________________________

From report at bugs.python.org  Fri Nov 14 15:04:37 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 14 Nov 2014 14:04:37 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1415973877.09.0.523604445954.issue22869@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/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 14 15:11:02 2014
From: report at bugs.python.org (Dave Tian)
Date: Fri, 14 Nov 2014 14:11:02 +0000
Subject: [issue22870] urlopen timeout failed with SSL socket
Message-ID: <1415974262.24.0.550554752923.issue22870@psf.upfronthosting.co.za>


New submission from Dave Tian:

Hi there,

Recent urlopen with timeout did not work. Below is the back trace. After digging into the Python lib, the root cause is found - within the socket.py, self._sock.recv(), under a 'while True' loop, tried to retrieve sth from the under-layer SSL socket. However, the under-layer PySSL_SSLread() neither returned anything useful nor reported an exception, such as timeout. Because of this 'while True' loop, urlopen got stuck. My temp fix is to add timeout within this issued loop of the socket.py. However, there are other similar loops ranging from urllib2, httplib to socket...and I do not think anything wrong with these loops considering the system socket programming practice. Instead, I am thinking if we could add a new timeout value into the socket object. This new timeout starts with the same value as the user-defined timeout but decrease for the same socket operation. For the case I have encountered:

while True:
    some_sock_recv() # decrease the timeout value within the function call

This should guarantee the timeout timely even within the 'while True' loop.


Thanks,
Dave

http://davejingtian.org




>>> obj=urllib2.urlopen(url, timeout=20)
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 410, in open
    response = meth(req, response)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 523, in http_response
    'http', request, response, code, msg, hdrs)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 442, in error
    result = self._call_chain(*args)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 629, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 422, in _open
    '_open', req)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1187, in do_open
    r = h.getresponse(buffering=True)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1045, in getresponse
    response.begin()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 441, in begin
    self.msg = HTTPMessage(self.fp, 0)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 25, in __init__
    rfc822.Message.__init__(self, fp, seekable)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/rfc822.py", line 108, in __init__
    self.readheaders()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 280, in readheaders
    line = self.fp.readline(_MAXLINE + 1)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 476, in readline
    data = self._sock.recv(self._rbufsize)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 241, in recv
    return self.read(buflen)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 160, in read
    return self._sslobj.read(len)
KeyboardInterrupt
>>>

----------
components: Library (Lib)
messages: 231160
nosy: daveti
priority: normal
severity: normal
status: open
title: urlopen timeout failed with SSL socket
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22870>
_______________________________________

From report at bugs.python.org  Fri Nov 14 15:38:48 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 14 Nov 2014 14:38:48 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1415975928.76.0.929070727338.issue22834@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So it isn't about importlib not handling missing directories on sys.path directly, it has to do with the fact that os.getcwd() raises FileNotFoundError when CWD is no longer valid and that is in a fundamental part of importlib that isn't worrying about non-existent directories.

We could be robust and simply have instances of os.getcwd() failing just move on, e.g. when '' is hit in sys.path and os.getcwd() raises an exception just give up. The other option is leaving this to raise FileNotFoundError but throwing a new copy with a better error message mentioning this is because the current working directory no longer exists. That would lead to easier debugging since paths on sys.path are typically obvious -- since site.py makes them absolute -- but I'm willing to bet people don't bother checking CWD is still good. So it's robustness vs. debugging when you make this mistake.

Any opinions on the matter?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 14 16:56:01 2014
From: report at bugs.python.org (=?utf-8?q?Santiago_Palacio_G=C3=B3mez?=)
Date: Fri, 14 Nov 2014 15:56:01 +0000
Subject: [issue22871] datetime documentation incomplete
Message-ID: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>


New submission from Santiago Palacio G?mez:

In the datetime documentation page https://docs.python.org/2/library/datetime.html
In the directive sections, there are a few things that are not documented there. I really don't know all the possible directives, but the few examples I'm aware of, and how they seem to work for me:
%D seems to behave as the default %x (None locale)
%h seems to behave as %b

----------
assignee: docs at python
components: Documentation
messages: 231162
nosy: docs at python, spalac24
priority: normal
severity: normal
status: open
title: datetime documentation incomplete
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22871>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:21:43 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Nov 2014 17:21:43 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1415985703.09.0.339728397044.issue22847@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for adding the instrumentation.  Otherwise, it would have been difficult to tell whether the xor hashing had a significant deleterious effect on collisions.

Also, +1 on bumping up the cache size.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:24:12 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 14 Nov 2014 17:24:12 +0000
Subject: [issue22871] datetime documentation incomplete
In-Reply-To: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>
Message-ID: <1415985852.29.0.099137992169.issue22871@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +belopolsky, ethan.furman, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22871>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:34:48 2014
From: report at bugs.python.org (Joseph Siddall)
Date: Fri, 14 Nov 2014 17:34:48 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
Message-ID: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>


New submission from Joseph Siddall:

putting something in Queue(multiprocessing.Queue) after closing it raises an AssertionError.
Getting something out of a Queue after closing it raises an OSError.
I expected both scenarios to raise the same exception.


To Reproduce:


>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.close()
>>> q.put("ok")
Traceback (most recent call last):
...
AssertionError


>>> from multiprocessing import Queue
>>> q = Queue()
>>> q.close()
>>> q.get()
Traceback (most recent call last):
...
OSError: handle is closed

----------
components: Library (Lib)
messages: 231164
nosy: Joseph.Siddall
priority: normal
severity: normal
status: open
title: multiprocessing.Queue raises AssertionError
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:35:54 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 14 Nov 2014 17:35:54 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1415986554.14.0.397918183565.issue22872@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman, jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22872>
_______________________________________

From report at bugs.python.org  Fri Nov 14 18:41:57 2014
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 14 Nov 2014 17:41:57 +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: <1415986917.04.0.978089870341.issue2636@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The page on PyPI says where the project's homepage is located:

Home Page: https://code.google.com/p/mrab-regex-hg/

The bug was fixed in the last release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:03:26 2014
From: report at bugs.python.org (John Nagle)
Date: Fri, 14 Nov 2014 18:03:26 +0000
Subject: [issue22873] Re: SSLsocket.getpeercert - return ALL the fields of the
 certificate.
Message-ID: <1415988206.94.0.332443874226.issue22873@psf.upfronthosting.co.za>


New submission from John Nagle:

In each revision of "getpeercert", a few more fields are returned. Python 3.2 added "issuer" and "notBefore".  Python 3.4 added "crlDistributionPoints", "caIssuers", and OCSP URLS. But some fields
still aren't returned.  I happen to need CertificatePolicies, which is how you distinguish DV, OV, and EV certs.

   Here's what you get now from "getpeercert()" for "bankofamerica.com":

{'OCSP': ('http://EVSecure-ocsp.verisign.com',),
 'caIssuers': ('http://EVSecure-aia.verisign.com/EVSecure2006.cer',),
 'crlDistributionPoints':
('http://EVSecure-crl.verisign.com/EVSecure2006.crl',),
 'issuer': ((('countryName', 'US'),),
            (('organizationName', 'VeriSign, Inc.'),),
            (('organizationalUnitName', 'VeriSign Trust Network'),),
            (('organizationalUnitName',
              'Terms of use at https://www.verisign.com/rpa (c)06'),),
            (('commonName', 'VeriSign Class 3 Extended Validation SSL
CA'),)),
 'notAfter': 'Mar 22 23:59:59 2015 GMT',
 'notBefore': 'Feb 20 00:00:00 2014 GMT',
 'serialNumber': '69A7BC85C106DDE1CF4FA47D5ED813DC',
 'subject': ((('1.3.6.1.4.1.311.60.2.1.3', 'US'),),
             (('1.3.6.1.4.1.311.60.2.1.2', 'Delaware'),),
             (('businessCategory', 'Private Organization'),),
             (('serialNumber', '2927442'),),
             (('countryName', 'US'),),
             (('postalCode', '60603'),),
             (('stateOrProvinceName', 'Illinois'),),
             (('localityName', 'Chicago'),),
             (('streetAddress', '135 S La Salle St'),),
             (('organizationName', 'Bank of America Corporation'),),
             (('organizationalUnitName', 'Network Infrastructure'),),
             (('commonName', 'www.bankofamerica.com'),)),
 'subjectAltName': (('DNS', 'mobile.bankofamerica.com'),
                    ('DNS', 'www.bankofamerica.com')),
 'version': 3}

Missing fields (from Firefox's view of the cert) include:

 Certificate Policies:
    2.16.840.1.113733.1.7.23.6:
    Extended Validation (EV) SSL Server Certificate
    Certification Practice Statement pointer: https://www.verisign.com/cps
    (This tells you it's a valid EV cert).

 Certificate Basic Constraints:
    Is not a Certificate Authority
    (which means they can't issue more certs below this one)

 Extended Key Usage:
    TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)
    TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
    (which means this cert is for web use, not email or code signing)

   How about just returning ALL the remaining fields and finishing the job, so this doesn't have to be fixed again?  Thanks.

----------
components: Library (Lib)
messages: 231166
nosy: nagle
priority: normal
severity: normal
status: open
title: Re: SSLsocket.getpeercert - return ALL the fields of the certificate.
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22873>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:04:15 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 14 Nov 2014 18:04:15 +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: <1415988255.23.0.651931673635.issue22873@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22873>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:19:26 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 14 Nov 2014 18:19:26 +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: <1415989166.74.0.235023167752.issue22873@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/issue22873>
_______________________________________

From report at bugs.python.org  Fri Nov 14 19:52:51 2014
From: report at bugs.python.org (Jens Bonerz)
Date: Fri, 14 Nov 2014 18:52:51 +0000
Subject: [issue22874] gzip bug in python 2.7.3?
Message-ID: <1415991171.51.0.828444620697.issue22874@psf.upfronthosting.co.za>


New submission from Jens Bonerz:

I am getting the "Not a gzipped file" exception while retrieving a gzipped sitemap xml (tested on amazon.de) using scrapy-

I am using Python 2.7.3 and Scrapy 0.24.4

Can anyone confirm gzip being broken in 2.7.3 or am I overseeing something?

----------
messages: 231167
nosy: jbonerz
priority: normal
severity: normal
status: open
title: gzip bug in python 2.7.3?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22874>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:14:38 2014
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 14 Nov 2014 19:14:38 +0000
Subject: [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1415992478.63.0.925885519925.issue16802@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

To me, there's also a valid use case on Unix; A parent process forks and execs, wanting to share a socket to the executed child process. The best way for the child to create a socket object is to use the fileno parameter of socket.socket().

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16802>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:15:17 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 19:15:17 +0000
Subject: [issue22822] IPv6Network constructor docs incorrect about valid input
In-Reply-To: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za>
Message-ID: <1415992517.66.0.238390171515.issue22822@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ncoghlan, pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22822>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:16:32 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Nov 2014 19:16:32 +0000
Subject: [issue22874] gzip bug in python 2.7.3?
In-Reply-To: <1415991171.51.0.828444620697.issue22874@psf.upfronthosting.co.za>
Message-ID: <1415992592.63.0.335173040589.issue22874@psf.upfronthosting.co.za>


Ned Deily added the comment:

It's hard to guess what is going on without an example of the failure.  Please post the code of a simple reproducible example that fails along with the exception traceback and also indicate what kind of platform you are running this on.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22874>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:18:16 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Nov 2014 19:18:16 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1415992696.6.0.999390169925.issue22834@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, once I've launched a program, regardless of whether or not I expected some stuff to come from the CWD, I generally don't think about whether or not the CWD might go away, and in a complex setup it would most likely be getting deleted by some other process.  So I think I would prefer an import that is of something that wasn't ever in the CWD to succeed if the CWD goes away.  I'm not even sure I'd want a warning.

What happens if a directory on the path disappears?  If that is treated as a non-error, then I think a missing CWD on the path should also be treated as a non-error.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:25:11 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 19:25:11 +0000
Subject: [issue22838] Convert re tests to unittest
In-Reply-To: <1415639456.54.0.317814729132.issue22838@psf.upfronthosting.co.za>
Message-ID: <1415993111.53.0.536865341011.issue22838@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This needs side-by-side review but there is no review button. Does anyone know why?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22838>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:31:29 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2014 19:31:29 +0000
Subject: [issue22871] datetime documentation incomplete
In-Reply-To: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>
Message-ID: <1415993489.3.0.679175900293.issue22871@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

If you read the paragraph preceding the table of directives [1], you will see that "The full set of format codes supported varies across platforms, because Python calls the platform C library?s strftime() function, and platform variations are common. To see the full set of format codes supported on your platform, consult the strftime(3) documentation."


[1] https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22871>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:33:42 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 19:33:42 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1415993622.01.0.313087249422.issue22834@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

How about issue a verbose warning for possible debugging and continue for robustness?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:36:23 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Nov 2014 19:36:23 +0000
Subject: [issue22870] urlopen timeout failed with SSL socket
In-Reply-To: <1415974262.24.0.550554752923.issue22870@psf.upfronthosting.co.za>
Message-ID: <1415993783.42.0.454827287462.issue22870@psf.upfronthosting.co.za>


R. David Murray added the comment:

It sounds like the bug is that PySSL_SSLread didn't raise the timeout?  Any idea if this is still a problem in python3?  (Could possibly have changed on trunk as well, as SSL is being updated in 2.7.9.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22870>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:38:57 2014
From: report at bugs.python.org (Jens Bonerz)
Date: Fri, 14 Nov 2014 19:38:57 +0000
Subject: [issue22874] gzip bug in python 2.7.3?
In-Reply-To: <1415991171.51.0.828444620697.issue22874@psf.upfronthosting.co.za>
Message-ID: <1415993937.79.0.422041109623.issue22874@psf.upfronthosting.co.za>


Jens Bonerz added the comment:

closed. Problem caused by 3rd party app

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22874>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:40:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Nov 2014 19:40:16 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1415994016.71.0.0315715175359.issue17293@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue had added new tests. Here is a patch against 2.7 (3.4+ should use OSError instead of socket.gaierror) which fixes _arp_getnode().

----------
Added file: http://bugs.python.org/file37196/uuid_arp_getnode_freebsd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:47:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Nov 2014 19:47:18 +0000
Subject: [issue22841] Avoid to use coroutine with add_signal_handler()
In-Reply-To: <1415662547.93.0.350675273647.issue22841@psf.upfronthosting.co.za>
Message-ID: <20141114194559.29218.72062@psf.io>


Roundup Robot added the comment:

New changeset d244e1770f1b by Guido van Rossum in branch '3.4':
- Issue #22841: Reject coroutines in asyncio add_signal_handler().
https://hg.python.org/cpython/rev/d244e1770f1b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22841>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:48:13 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 14 Nov 2014 19:48:13 +0000
Subject: [issue22874] gzip bug in python 2.7.3?
In-Reply-To: <1415991171.51.0.828444620697.issue22874@psf.upfronthosting.co.za>
Message-ID: <1415994493.3.0.475959840938.issue22874@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> third party
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22874>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:50:28 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Nov 2014 19:50:28 +0000
Subject: [issue22841] Avoid to use coroutine with add_signal_handler()
In-Reply-To: <1415662547.93.0.350675273647.issue22841@psf.upfronthosting.co.za>
Message-ID: <1415994628.18.0.684587411694.issue22841@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Applied to upstream tulip, 3.4, and 3.5. Thanks Ludovic!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22841>
_______________________________________

From report at bugs.python.org  Fri Nov 14 20:52:39 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Nov 2014 19:52:39 +0000
Subject: [issue22841] Avoid to use coroutine with add_signal_handler()
In-Reply-To: <1415662547.93.0.350675273647.issue22841@psf.upfronthosting.co.za>
Message-ID: <20141114194853.15621.12193@psf.io>


Roundup Robot added the comment:

New changeset 44e77709daa4 by Guido van Rossum in branch 'default':
- Issue #22841: Reject coroutines in asyncio add_signal_handler().
https://hg.python.org/cpython/rev/44e77709daa4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22841>
_______________________________________

From report at bugs.python.org  Fri Nov 14 21:01:44 2014
From: report at bugs.python.org (Corbin Simpson)
Date: Fri, 14 Nov 2014 20:01:44 +0000
Subject: [issue22875] asyncio: call_soon() documentation unclear on timing
Message-ID: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>


New submission from Corbin Simpson:

Hi there!

While assisting somebody on #python (where manners go to die), I was consulting asyncio's documentation. Given my unfamiliarity with asyncio, I was surprised to read BaseEventLoop.call_soon()'s documented behavior: "Arrange for a callback to be called as soon as possible." [1]

The question in mind is whether call_soon() waits for control to return to the event loop before calling the first callback in the queue. After all, given the documented behavior, it would not be unreasonable for call_soon() to always call callbacks immediately if no other callbacks were enqueued. I can imagine scenarios where a previous queued callback from e.g. call_soon_threadsafe() creates a callback that causes queueing behavior, but otherwise I would expect "as soon as possible" to mean "immediately".

It's true that in other event loops, this kind of callback registration waits for control to return to the event loop before running callbacks. However, many event loops that I've worked with indicate that call_later() is the correct API for adding callbacks that respect the event loop. In fact, call_later(0, callback, args) looks quite a bit like the familiar Twisted callLater(0, callback, args) pattern!

Additionally, there is no indication as to whether call_later() and call_soon() use the same queue.

I'd like clarification on these points in the Python 3 documentation, please. I'd like to know whether call_soon() can be immediate, and whether call_soon() preempts or interleaves with call_later().

(Yes, I know that Twisted's documentation is missing this too [2] [3]. I'll get to that soon enough.)

Thanks!
~ C.

[1]: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_soon
[2]: http://twistedmatrix.com/documents/current/core/howto/time.html
[3]: http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorTime.html#callLater

----------
assignee: docs at python
components: Documentation, asyncio
messages: 231180
nosy: Corbin.Simpson, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call_soon() documentation unclear on timing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22875>
_______________________________________

From report at bugs.python.org  Fri Nov 14 21:03:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Nov 2014 20:03:05 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1415995385.75.0.0181469769399.issue14099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you David for your benchmarks and patch. There are several backward compatibility issues with the reading from ZipFile opened for write and from closed ZipFile. This behavior is mostly undocumented (except the reading from closed ZipFile), but even our tests depend on it and changing it could break user code with good chance.

Here is a patch which preserves current behavior. Added new tests to check this behavior explicitly. Other advantage of the patch is that it doesn't change the signature of ZipExtFile constructor at all.

Benchmarks don't show stable significant difference between patched and unpatched versions.

----------
versions: +Python 3.5 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file37197/zipfile_share_file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Nov 14 21:03:51 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Nov 2014 20:03:51 +0000
Subject: [issue22875] asyncio: call_soon() documentation unclear on timing
In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>
Message-ID: <1415995431.2.0.11220239099.issue22875@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

"As soon as possible" is constrained by "all callbacks are called from the event loop".

Feel free to suggest a doc patch (asyncio docs are in dire need of more help!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22875>
_______________________________________

From report at bugs.python.org  Fri Nov 14 21:04:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Nov 2014 20:04:29 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1415995469.37.0.671848614607.issue14099@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file37198/bench_zip.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Nov 14 21:08:50 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Nov 2014 20:08:50 +0000
Subject: [issue22875] asyncio: call_soon() documentation unclear on timing
In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>
Message-ID: <1415995730.0.0.763523318164.issue22875@psf.upfronthosting.co.za>


R. David Murray added the comment:

Personally, when I read that I thought "arrange for" made it pretty clear it was when control returned to the event loop, but I agree that if it can be made clearer it should be.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22875>
_______________________________________

From report at bugs.python.org  Fri Nov 14 21:11:47 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Nov 2014 20:11:47 +0000
Subject: [issue22838] Convert re tests to unittest
In-Reply-To: <1415639456.54.0.317814729132.issue22838@psf.upfronthosting.co.za>
Message-ID: <1415995907.5.0.820223382912.issue22838@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Regenerated patch. Hope this will help.

----------
Added file: http://bugs.python.org/file37199/re_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22838>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:03:34 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:03:34 +0000
Subject: [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415999014.71.0.778448837562.issue22843@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

David is correct that the current phrasing is correct.  The phase 'x has a boolean value of True' means 'bool(x) is True', which is always true for match objects, as well as for non-zero numbers, non-empty collections, and many other things.  This does *not* imply equality between the object and its boolean value.  In fact, nearly all objects are not equal to their boolean value.  Clayton could just as well as have written "blah = 'a'" or "blah = 1 + 1j" and gotten the name non-surprising result.

There is nothing special about boolean values in this respect.  The string value of x is str(x) and in general, x != str(x).  (This also sometimes confuses people.)  Similarly, if x has an integral value int(x), it does not necessarily equal that value: int(3.1459) != 3.

I think the doc is fine as is.  The fact that "3 is considered to be '3' in a display context" does not mean that we do not write "the string value of 3 is '3'".  It is fundamental to Python that essentially all objects o have a string value str(o) and a boolean value bool(o) and that those mappings are sometimes used automatically for display and logic.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22843>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:10:02 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:10:02 +0000
Subject: [issue22848] Subparser help does not respect SUPPRESS argument
In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za>
Message-ID: <1415999402.56.0.271688052686.issue22848@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22848>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:16:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:16:38 +0000
Subject: [issue22851] 2.7 core crashes with generator.gi_frame.f_restricted
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1415999798.05.0.28198487981.issue22851@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This appears to be 2.7 only as 3.4.2 stops on the first print with AttributeError: 'frame' object has no attribute 'f_restricted', which is not a crash.

----------
nosy: +terry.reedy
stage:  -> needs patch
title: core crashes -> 2.7 core crashes with generator.gi_frame.f_restricted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:21:45 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:21:45 +0000
Subject: [issue22858] unittest.__init__:main shadows unittest.main
In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>
Message-ID: <1416000105.31.0.976513231692.issue22858@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22858>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:23:08 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:23:08 +0000
Subject: [issue22860] unittest TestProgram hard to extend
In-Reply-To: <1415874591.06.0.535535954312.issue22860@psf.upfronthosting.co.za>
Message-ID: <1416000188.17.0.570033718491.issue22860@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22860>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:25:15 2014
From: report at bugs.python.org (Clayton Kirkwood)
Date: Fri, 14 Nov 2014 21:25:15 +0000
Subject: [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415999014.71.0.778448837562.issue22843@psf.upfronthosting.co.za>
Message-ID: <06ea01d00051$6945afb0$3bd10f10$@us>


Clayton Kirkwood added the comment:

Cool

>-----Original Message-----
>From: Terry J. Reedy [mailto:report at bugs.python.org]
>Sent: Friday, November 14, 2014 1:04 PM
>To: crk at godblessthe.us
>Subject: [issue22843] doc error: 6.2.4. Match Objects
>
>
>Terry J. Reedy added the comment:
>
>David is correct that the current phrasing is correct.  The phase 'x has
>a boolean value of True' means 'bool(x) is True', which is always true
>for match objects, as well as for non-zero numbers, non-empty
>collections, and many other things.  This does *not* imply equality
>between the object and its boolean value.  In fact, nearly all objects
>are not equal to their boolean value.  Clayton could just as well as
>have written "blah = 'a'" or "blah = 1 + 1j" and gotten the name non-
>surprising result.
>
>There is nothing special about boolean values in this respect.  The
>string value of x is str(x) and in general, x != str(x).  (This also
>sometimes confuses people.)  Similarly, if x has an integral value
>int(x), it does not necessarily equal that value: int(3.1459) != 3.
>
>I think the doc is fine as is.  The fact that "3 is considered to be '3'
>in a display context" does not mean that we do not write "the string
>value of 3 is '3'".  It is fundamental to Python that essentially all
>objects o have a string value str(o) and a boolean value bool(o) and
>that those mappings are sometimes used automatically for display and
>logic.
>
>----------
>nosy: +terry.reedy
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue22843>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22843>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:35:29 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:35:29 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1416000929.26.0.647445882875.issue22863@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

New stuff is marked "New in version 2.7.9.", etc.  The Idle chapter (reletively new in the Library Reference itself) has the same problem if new or quasi-new features in micro-releases are added to the doc before the release.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:51:15 2014
From: report at bugs.python.org (Ryan Hartkopf)
Date: Fri, 14 Nov 2014 21:51:15 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1416001875.71.0.388075828475.issue9694@psf.upfronthosting.co.za>


Ryan Hartkopf added the comment:

Personally, 'options' is the first word that comes to mind other than 'arguments' (which is confusing for obvious reasons). But I think we can all agree that any of these candidates are less ambiguous than 'optional arguments'! It's been 4 years, let's put this one to bed!

----------
nosy: +rhartkopf
Added file: http://bugs.python.org/file37200/argparse_option.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Fri Nov 14 22:55:19 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 14 Nov 2014 21:55:19 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
In-Reply-To: <1416000929.26.0.647445882875.issue22863@psf.upfronthosting.co.za>
Message-ID: <54667A40.4040406@egenix.com>


Marc-Andre Lemburg added the comment:

On 14.11.2014 22:35, Terry J. Reedy wrote:
> New stuff is marked "New in version 2.7.9.", etc.  The Idle chapter (reletively new in the Library Reference itself) has the same problem if new or quasi-new features in micro-releases are added to the doc before the release.

I know, but there are so many additions in the ssl module that it's
very difficult to tell what actually was part of earlier Python 2.7
releases.

I think best would be to link to the release URL Bejamin mentioned
for "2.7.8" and provide the trunk version as "2.7 (trunk)".
The same should probably be done for the other releases listed
in the selector.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Fri Nov 14 23:00:57 2014
From: report at bugs.python.org (David Wilson)
Date: Fri, 14 Nov 2014 22:00:57 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1416002457.68.0.290717025967.issue14099@psf.upfronthosting.co.za>


David Wilson added the comment:

Hi Serhiy,

Thanks for the new patch, it looks better than my attempt. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Nov 14 23:13:09 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 14 Nov 2014 22:13:09 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1416003189.6.0.525039345231.issue22834@psf.upfronthosting.co.za>


Martin Panter added the comment:

The only time I see a warning would be useful is if you intended to override a standard module with a module of the same name in the current directory. In all other cases I think it would be better to either generate an ImportError if the module is not found, or import it from wherever it is found. So I think a warning would not be useful in most cases.

Having any other non-existant directory in the search path is not an error and there is no warning either:
$ python3 -btWall
Python 3.4.2 (default, Oct  8 2014, 14:33:30) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.insert(0, "/blaua")
>>> import sadface
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'sadface'
>>> import urllib
>>> # Interpreter = happy
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 14 23:18:07 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 14 Nov 2014 22:18:07 +0000
Subject: [issue22867] document behavior of calling atexit.register() while
 atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1416003487.57.0.103655083791.issue22867@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22867>
_______________________________________

From report at bugs.python.org  Fri Nov 14 23:20:32 2014
From: report at bugs.python.org (eryksun)
Date: Fri, 14 Nov 2014 22:20:32 +0000
Subject: [issue22851] 2.7 core crashes with generator.gi_frame.f_restricted
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1416003632.45.0.740220497404.issue22851@psf.upfronthosting.co.za>


eryksun added the comment:

The fix for issue 14432 was applied to 3.3, but I'm pretty sure 2.x PyFrame_IsRestricted is the only problem. Nothing else should see f_tstate when it's NULL. Also, f_tstate was dropped from PyFrameObject in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:04:39 2014
From: report at bugs.python.org (=?utf-8?b?0JLRj9GH0LXRgdC70LDQsg==?=)
Date: Fri, 14 Nov 2014 23:04:39 +0000
Subject: [issue22876] ip_interface can't be broadcast or number net
Message-ID: <1416006279.81.0.519383072112.issue22876@psf.upfronthosting.co.za>


New submission from ????????:

ip_interface can't be network or broadcast address. Probably should throw an exception in such cases

>>> ip_interface(u'192.168.1.0/25')
IPv4Interface(u'192.168.1.0/25')

>>> ip_interface(u'192.168.1.127/25')
IPv4Interface(u'192.168.1.127/25')

----------
components: Library (Lib)
messages: 231194
nosy: m01, ncoghlan, pmoody, python-dev, ????????
priority: normal
severity: normal
status: open
title: ip_interface can't be broadcast or number net
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22876>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:18:24 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 23:18:24 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1416007104.96.0.927390322372.issue22863@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that "x.y.z" should be reserved for the frozen release version of the docs and that the current ongoing version should be "x.y (trunk)" or "x.y.z+".  This was true without new features in a micro release, but did not matter so much.  Leaving Idle aside, I am not sure how we should handle the new exception in other stdlib modules.  There may or may not be more documented additions past 2.7.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:16:05 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 15 Nov 2014 00:16:05 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1416010565.36.0.135187934215.issue22847@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:16:29 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 15 Nov 2014 00:16:29 +0000
Subject: [issue22257] PEP 432: Redesign the interpreter startup sequence
In-Reply-To: <1408789351.84.0.0171822343712.issue22257@psf.upfronthosting.co.za>
Message-ID: <1416010589.57.0.125325867556.issue22257@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22257>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:17:03 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 15 Nov 2014 00:17:03 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416010623.71.0.0658877354245.issue22869@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:19:21 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 15 Nov 2014 00:19:21 +0000
Subject: [issue22863] https://docs.python.org/ should make a true 2.7.8
 version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1416010761.33.0.27996257757.issue22863@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22863>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:20:17 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 15 Nov 2014 00:20:17 +0000
Subject: [issue22851] 2.7 core crashes with generator.gi_frame.f_restricted
In-Reply-To: <1415787631.95.0.914662505329.issue22851@psf.upfronthosting.co.za>
Message-ID: <1416010817.63.0.983522719637.issue22851@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22851>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:35:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Nov 2014 00:35:12 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <20141115003501.15627.37333@psf.io>


Roundup Robot added the comment:

New changeset 97dc64adb6fe by Antoine Pitrou in branch 'default':
Issue #22847: Improve method cache efficiency.
https://hg.python.org/cpython/rev/97dc64adb6fe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:37:53 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Nov 2014 00:37:53 +0000
Subject: [issue22877] Backport ensurepip OS X installer changes to 2.7
Message-ID: <1416011873.01.0.449505301974.issue22877@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: ned.deily
components: Installation, Macintosh
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Backport ensurepip OS X installer changes to 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22877>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:55:35 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Nov 2014 00:55:35 +0000
Subject: [issue22847] Improve method cache efficiency
In-Reply-To: <1415722426.91.0.800448748536.issue22847@psf.upfronthosting.co.za>
Message-ID: <1416012935.34.0.178583010881.issue22847@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Now pushed. Thanks for the comments!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22847>
_______________________________________

From report at bugs.python.org  Sat Nov 15 01:59:57 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Nov 2014 00:59:57 +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: <1416013197.93.0.0466507771885.issue22873@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> How about just returning ALL the remaining fields and finishing the
> job, so this doesn't have to be fixed again?  Thanks.

Please learn some respect. You are not here to tell volunteers what they should work on.
And if you want to see things sped up, you can submit a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22873>
_______________________________________

From report at bugs.python.org  Sat Nov 15 04:00:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Nov 2014 03:00:18 +0000
Subject: [issue22877] Backport ensurepip OS X installer changes to 2.7
Message-ID: <20141115030000.36994.89134@psf.io>


New submission from Roundup Robot:

New changeset 6b8e107622b3 by Ned Deily in branch '2.7':
Issue #22877: PEP 477 - OS X installer for 2.7.9 now installs pip.
https://hg.python.org/cpython/rev/6b8e107622b3

New changeset e8182c6c9ef1 by Ned Deily in branch '3.4':
Issue #22877: PEP 477 - keep 2.7 and 3.x installers in sync.
https://hg.python.org/cpython/rev/e8182c6c9ef1

New changeset 6270a2181ed3 by Ned Deily in branch 'default':
Issue #22877: PEP 477 - keep 2.7 and 3.x installers in sync.
https://hg.python.org/cpython/rev/6270a2181ed3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22877>
_______________________________________

From report at bugs.python.org  Sat Nov 15 04:03:55 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Nov 2014 03:03:55 +0000
Subject: [issue22877] Backport ensurepip OS X installer changes to 2.7
In-Reply-To: <20141115030000.36994.89134@psf.io>
Message-ID: <1416020635.64.0.00875062743902.issue22877@psf.upfronthosting.co.za>


Ned Deily added the comment:

Committed for release in 2.7.9.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22877>
_______________________________________

From report at bugs.python.org  Sat Nov 15 04:05:53 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Nov 2014 03:05:53 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416020753.22.0.15995140833.issue22827@psf.upfronthosting.co.za>


Ned Deily added the comment:

The OS X installer integration backport has been committed in Issue22877.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Sat Nov 15 04:51:45 2014
From: report at bugs.python.org (John Nagle)
Date: Sat, 15 Nov 2014 03:51:45 +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: <1416023505.69.0.797326996385.issue22873@psf.upfronthosting.co.za>


John Nagle added the comment:

May be a duplicate of Issue 204679: "ssl.getpeercert() should include extensions"

http://bugs.python.org/issue20469

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22873>
_______________________________________

From report at bugs.python.org  Sat Nov 15 06:08:00 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 15 Nov 2014 05:08:00 +0000
Subject: [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1416028080.56.0.252569476964.issue22868@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22868>
_______________________________________

From report at bugs.python.org  Sat Nov 15 06:53:26 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Nov 2014 05:53:26 +0000
Subject: [issue7949] IDLE: problems with dark GTK or KDE color schemes
In-Reply-To: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za>
Message-ID: <1416030806.8.0.80253674883.issue7949@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#16984 is closed as a duplicate of this.  The screenshot helps. I was just thinking about adding a retro-black color theme to match the current old-is-new fashion.  It appears that this would solve the Text part of the problem but Mathias' patch summary shows that more is needed to get other widgets in line.

It appears that a review and written summary of colors in Idle would be helpful.  I am curious what effect switching to themed widgets would have on this issue.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7949>
_______________________________________

From report at bugs.python.org  Sat Nov 15 09:15:11 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 15 Nov 2014 08:15:11 +0000
Subject: [issue22878] PEP 477 (ensurepip backport to 2.7.9): "make install"
 and "make altinstall" integration
Message-ID: <1416039311.77.0.37210420462.issue22878@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee: ned.deily
components: Build
nosy: ned.deily
priority: normal
severity: normal
status: open
title: PEP 477 (ensurepip backport to 2.7.9): "make install" and "make altinstall" integration
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22878>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:05:37 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Nov 2014 12:05:37 +0000
Subject: [issue22193] Add _PySys_GetSizeOf()
In-Reply-To: <1408011893.72.0.474736082349.issue22193@psf.upfronthosting.co.za>
Message-ID: <20141115120527.36976.63550@psf.io>


Roundup Robot added the comment:

New changeset 3537994fa43b by Serhiy Storchaka in branch '2.7':
Issue #22193: Fixed integer overflow error in sys.getsizeof().
https://hg.python.org/cpython/rev/3537994fa43b

New changeset df5c6b05238e by Serhiy Storchaka in branch '3.4':
Issue #22193: Fixed integer overflow error in sys.getsizeof().
https://hg.python.org/cpython/rev/df5c6b05238e

New changeset b7651f9be4a1 by Serhiy Storchaka in branch 'default':
Issue #22193: Fixed integer overflow error in sys.getsizeof().
https://hg.python.org/cpython/rev/b7651f9be4a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22193>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:05:36 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Nov 2014 12:05:36 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <20141115120527.36976.50368@psf.io>


Roundup Robot added the comment:

New changeset f4e75efdc7f1 by Serhiy Storchaka in branch 'default':
Issue #22823: Use set literals instead of creating a set from a tuple.
https://hg.python.org/cpython/rev/f4e75efdc7f1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:10:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Nov 2014 12:10:39 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1416053439.13.0.772331289546.issue22823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Can you also make a separate mock patch and assign it to Michael Foord for review?

Here is a patch. It also replaces constructing sets from generators with set comprehensions.

----------
assignee: serhiy.storchaka -> michael.foord
nosy: +michael.foord
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37201/set_literal_mock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:13:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Nov 2014 12:13:53 +0000
Subject: [issue22193] Add _PySys_GetSizeOf()
In-Reply-To: <1408011893.72.0.474736082349.issue22193@psf.upfronthosting.co.za>
Message-ID: <1416053633.75.0.91032318357.issue22193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Also fixed an error in _PySys_GetSizeOf declaration (thanks yomgui1). Thanks all for reviews and found bugs.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22193>
_______________________________________

From report at bugs.python.org  Sat Nov 15 13:36:50 2014
From: report at bugs.python.org (roskakori)
Date: Sat, 15 Nov 2014 12:36:50 +0000
Subject: [issue18348] Additional code pages for EBCDIC
In-Reply-To: <1372787231.53.0.326876214252.issue18348@psf.upfronthosting.co.za>
Message-ID: <1416055010.54.0.662170356192.issue18348@psf.upfronthosting.co.za>


roskakori added the comment:

I just released a package on PyPI that adds various EBCDIC codecs for Python 2.6+ and Python 3.1+, see <https://pypi.python.org/pypi/ebcdic>.

I agree with Marc-Andre, maintaining this is easier as separate package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18348>
_______________________________________

From report at bugs.python.org  Sat Nov 15 14:14:16 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Nov 2014 13:14:16 +0000
Subject: [issue18348] Additional code pages for EBCDIC
In-Reply-To: <1372787231.53.0.326876214252.issue18348@psf.upfronthosting.co.za>
Message-ID: <1416057256.57.0.661862966155.issue18348@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There are more and more codecs on PyPI. I would be nice to have a list somewhere.

@roskakori: Could you please create a page at https://wiki.python.org/ ? Example:
https://wiki.python.org/moin/Codecs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18348>
_______________________________________

From report at bugs.python.org  Sat Nov 15 15:15:20 2014
From: report at bugs.python.org (Dave Tian)
Date: Sat, 15 Nov 2014 14:15:20 +0000
Subject: [issue22870] urlopen timeout failed with SSL socket
In-Reply-To: <1415993783.42.0.454827287462.issue22870@psf.upfronthosting.co.za>
Message-ID: <92ECAE26-7372-4305-992F-5AB7DA383EAD@gmail.com>


Dave Tian added the comment:

Hi David,

Thanks for your quick response. I have tried Python 3.4.2 using urllib.request.urlopen() - still not working. Below is the backtrace. I am not sure if this is a bug of PySSL_SSLread, which returns nothing yet without timeout. If you want me to dig into this deeper, just let me know.

Thanks,

Dave Tian
dave.jing.tian at gmail.com

>>> obj=urllib.request.urlopen(url, timeout=20)
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 153, in urlopen
    return opener.open(url, data, timeout)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 461, in open
    response = meth(req, response)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 571, in http_response
    'http', request, response, code, msg, hdrs)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 493, in error
    result = self._call_chain(*args)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 676, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 455, in open
    response = self._open(req, data)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 473, in _open
    '_open', req)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 433, in _call_chain
    result = func(*args)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 1217, in https_open
    context=self._context, check_hostname=self._check_hostname)
  File "/Users/daveti/Python-3.4.2/Lib/urllib/request.py", line 1177, in do_open
    r = h.getresponse()
  File "/Users/daveti/Python-3.4.2/Lib/http/client.py", line 1172, in getresponse
    response.begin()
  File "/Users/daveti/Python-3.4.2/Lib/http/client.py", line 375, in begin
    self.headers = self.msg = parse_headers(self.fp)
  File "/Users/daveti/Python-3.4.2/Lib/http/client.py", line 261, in parse_headers
    line = fp.readline(_MAXLINE + 1)
  File "/Users/daveti/Python-3.4.2/Lib/socket.py", line 371, in readinto
    return self._sock.recv_into(b)
  File "/Users/daveti/Python-3.4.2/Lib/ssl.py", line 746, in recv_into
    return self.read(nbytes, buffer)
  File "/Users/daveti/Python-3.4.2/Lib/ssl.py", line 618, in read
    v = self._sslobj.read(len, buffer)
KeyboardInterrupt
>>> 

> On Nov 15, 2014, at 3:36 AM, R. David Murray <report at bugs.python.org> wrote:
> 
> 
> R. David Murray added the comment:
> 
> It sounds like the bug is that PySSL_SSLread didn't raise the timeout?  Any idea if this is still a problem in python3?  (Could possibly have changed on trunk as well, as SSL is being updated in 2.7.9.)
> 
> ----------
> nosy: +r.david.murray
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22870>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22870>
_______________________________________

From report at bugs.python.org  Sat Nov 15 15:23:53 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 15 Nov 2014 14:23:53 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416061433.2.0.192574686422.issue18813@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


Removed file: http://bugs.python.org/file31421/faster_PyEval_SliceIndex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sat Nov 15 19:24:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 15 Nov 2014 18:24:11 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416075851.53.0.74265137231.issue22869@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

+1 on the principle.

> reference count printing is duplicated (lifecycle prints it at 
> shutdown, pythonrun at the interactive prompt)

You could make it an API in object.c.

> * pythonrun references PyInspect_Flag directly without an extern
> declaration
> 
> * This particular oddity wasn't introduced by this patch, but it 
> turns out PyOptimize_Flag lives in compile.c, rather than with the 
> other global flags in pythonrun.c. It's also declared as a public 
> data API in pydebug.h

Should be easy to fix as well :-)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 15 19:38:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Nov 2014 18:38:39 +0000
Subject: [issue22870] urlopen timeout failed with SSL socket
In-Reply-To: <1415974262.24.0.550554752923.issue22870@psf.upfronthosting.co.za>
Message-ID: <1416076719.36.0.739308342008.issue22870@psf.upfronthosting.co.za>


R. David Murray added the comment:

I won't be the one, as I'm not conversant with the ssl C code.  What would be helpful right now would be a recipe for reproducing the problem.

----------
nosy: +alex, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22870>
_______________________________________

From report at bugs.python.org  Sat Nov 15 19:59:09 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 15 Nov 2014 18:59:09 +0000
Subject: [issue22824] Update reprlib to use set literals
In-Reply-To: <1415503338.78.0.5855468908.issue22824@psf.upfronthosting.co.za>
Message-ID: <20141115185906.51553.82081@psf.io>


Roundup Robot added the comment:

New changeset cf5b910ac4c8 by Raymond Hettinger in branch 'default':
Issue #22824:  Simplify reprlib output format for empty arrays
https://hg.python.org/cpython/rev/cf5b910ac4c8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22824>
_______________________________________

From report at bugs.python.org  Sat Nov 15 20:02:34 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Nov 2014 19:02:34 +0000
Subject: [issue22876] ip_interface can't be broadcast or number net
In-Reply-To: <1416006279.81.0.519383072112.issue22876@psf.upfronthosting.co.za>
Message-ID: <1416078154.98.0.0149863453707.issue22876@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it can be the network, even though it isn't typically (and some devices don't support it...I'm pretty sure I remember doing it on a Cisco, though I wouldn't swear to it without testing :).  Same is true for broadcast, though that would be *really* questionable and I doubt many devices support it.  (At least, I couldn't find any RFC that says those two addresses are actually reserved in all contexts).  

I know of two situations in which it is specifically not true: the simplest (which could be special cased) is a two ip (point to point) subnet.  The other is a "routed" subnet: a subnet where the subnet is routed to a router/firewall, and the router/firewall NATs those addresses to some internal addresses.  Conceptually, every IP in the subnet can be an interface IP.

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22876>
_______________________________________

From report at bugs.python.org  Sat Nov 15 21:02:47 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Nov 2014 20:02:47 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416081767.12.0.702967923909.issue18813@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Are there any benchmarks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sat Nov 15 21:28:36 2014
From: report at bugs.python.org (Travis Thieman)
Date: Sat, 15 Nov 2014 20:28:36 +0000
Subject: [issue22864] Add filter to multiprocessing.Pool
In-Reply-To: <1415900127.9.0.960876191139.issue22864@psf.upfronthosting.co.za>
Message-ID: <1416083316.87.0.909665938728.issue22864@psf.upfronthosting.co.za>


Travis Thieman added the comment:

Why is it insufficient to run a synchronous 'filter' over the list returned by 'Pool.map'? These functional constructs are inherently composable, and we should favor composing simple implementations of each rather than implementing special cases of them throughout the stdlib.

I think there's a clear reason for 'map' to be parallelizable because the function you're applying over the iterable could be quite expensive. 'filter' would only benefit from this if the comparison you're running is expensive, which seems like an unlikely and ill-advised use case. You can also rewrite your expensive 'filter' as a 'map' if you really need to.

----------
nosy: +travis.thieman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22864>
_______________________________________

From report at bugs.python.org  Sat Nov 15 21:50:00 2014
From: report at bugs.python.org (Ben Yelsey)
Date: Sat, 15 Nov 2014 20:50:00 +0000
Subject: [issue21614] Case sensitivity problem in multiprocessing.
In-Reply-To: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za>
Message-ID: <1416084600.04.0.421697934853.issue21614@psf.upfronthosting.co.za>


Ben Yelsey added the comment:

Hi, could you please list more exact steps to reproduce, e.g. directory/file layout and import statements?

----------
nosy: +inlinestyle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21614>
_______________________________________

From report at bugs.python.org  Sat Nov 15 22:18:10 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 15 Nov 2014 21:18:10 +0000
Subject: [issue22825] Modernize TextFile
In-Reply-To: <1415544341.49.0.85924418958.issue22825@psf.upfronthosting.co.za>
Message-ID: <1416086290.42.0.357881237486.issue22825@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I would not touch any internal parts of distutils, such as TextFile.  It is not a public class meant for general usage.  The code is not ideal but not broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22825>
_______________________________________

From report at bugs.python.org  Sat Nov 15 22:32:30 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 15 Nov 2014 21:32:30 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416087150.23.0.640557060208.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

As mentioned, the fannkuch benchmark benefits quite a bit from the fast path, by 8%. It was a while ago when I tested, though, so I don't have exact numbers ATM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sat Nov 15 22:33:25 2014
From: report at bugs.python.org (=?utf-8?b?0JLRj9GH0LXRgdC70LDQsg==?=)
Date: Sat, 15 Nov 2014 21:33:25 +0000
Subject: [issue22876] ip_interface can't be broadcast or number net
In-Reply-To: <1416006279.81.0.519383072112.issue22876@psf.upfronthosting.co.za>
Message-ID: <1416087205.38.0.812521227106.issue22876@psf.upfronthosting.co.za>


???????? added the comment:

These addresses are used by each interface in the network and they can not be the address of the interface, of course have the technology ip-unnumbered. But it's more a special case.

but I was confused behavior:

>>> set(ip_network(u'192.168.1.0/29'))
set([IPv4Address(u'192.168.1.5'), IPv4Address(u'192.168.1.6'), IPv4Address(u'192.168.1.7'), IPv4Address(u'192.168.1.2'), IPv4Address(u'192.168.1.3'), IPv4Address(u'192.168.1.4'), IPv4Address(u'192.168.1.0'), IPv4Address(u'192.168.1.1')])


>>> for i in ip_network(u'192.168.1.0/29').hosts():
...     print i
...
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
192.168.1.5
192.168.1.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22876>
_______________________________________

From report at bugs.python.org  Sat Nov 15 22:42:45 2014
From: report at bugs.python.org (Travis Thieman)
Date: Sat, 15 Nov 2014 21:42:45 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1416087765.37.0.169020876506.issue22536@psf.upfronthosting.co.za>


Travis Thieman added the comment:

The attached patch includes the first element in args in _execute_child to the OSError exception subclass. This correctly populates the 'filename' field on the resulting exception. A test is also included that fails without the patch.

----------
keywords: +patch
nosy: +travis.thieman
Added file: http://bugs.python.org/file37202/22536-subprocess-exception-filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Sat Nov 15 22:52:18 2014
From: report at bugs.python.org (=?utf-8?b?0JLRj9GH0LXRgdC70LDQsg==?=)
Date: Sat, 15 Nov 2014 21:52:18 +0000
Subject: [issue22876] ip_interface can't be broadcast or number net
In-Reply-To: <1416006279.81.0.519383072112.issue22876@psf.upfronthosting.co.za>
Message-ID: <1416088338.5.0.350054961717.issue22876@psf.upfronthosting.co.za>


???????? added the comment:

Probably worth noting that network is unnumbered in ip_network and ip_interface functions. Based on this flag to decide whether there is a possibility to use the network address and broadcast address in the network
What do you think about this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22876>
_______________________________________

From report at bugs.python.org  Sat Nov 15 23:02:50 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 15 Nov 2014 22:02:50 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1416088970.63.0.431931808911.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

mock patch LGTM

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Sat Nov 15 23:32:08 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Nov 2014 22:32:08 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1416090728.72.0.76842633595.issue22823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

IMO, the _non_defaults set comprehension in mock.py ought to be replaced with a set of internable string constants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Sat Nov 15 23:33:22 2014
From: report at bugs.python.org (koobs)
Date: Sat, 15 Nov 2014 22:33:22 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1416090802.9.0.900991319723.issue17293@psf.upfronthosting.co.za>


koobs added the comment:

I only attached the 2.7 build log because the failures from 3.4 and 3.x are identical, copying them here for completeness:

>From 3.4: 

======================================================================
ERROR: test_arp_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.4.koobs-freebsd10/build/Lib/test/test_uuid.py", line 324, in test_arp_getnode
    node = uuid._arp_getnode()
  File "/usr/home/buildbot/python/3.4.koobs-freebsd10/build/Lib/uuid.py", line 364, in _arp_getnode
    ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno 8] hostname nor servname provided, or not known

----------------------------------------------------------------------
Ran 18 tests in 0.209s

>From 3.x:


======================================================================
ERROR: test_arp_getnode (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_uuid.py", line 325, in test_arp_getnode
    node = uuid._arp_getnode()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/uuid.py", line 362, in _arp_getnode
    ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno 8] hostname nor servname provided, or not known

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Sat Nov 15 23:47:49 2014
From: report at bugs.python.org (Brecht Machiels)
Date: Sat, 15 Nov 2014 22:47:49 +0000
Subject: [issue22879] Make set's add and discard methods return useful
 information
Message-ID: <1416091669.05.0.557383072226.issue22879@psf.upfronthosting.co.za>


New submission from Brecht Machiels:

set's add() method would be a little bit more useful if it would return True if the added value was already present in the set, and False if it wasn't (or the other way around). Similarly, discard() could report whether the discarded value was present in the set or not.

I suppose this could cost a couple of extra cycles and I'm not sure this is acceptable. For discard() there's always remove() that offers similar behavior. add() does not have an alternative that offers check-and-add behavior.

----------
components: Library (Lib)
messages: 231226
nosy: brechtm
priority: normal
severity: normal
status: open
title: Make set's add and discard methods return useful information
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22879>
_______________________________________

From report at bugs.python.org  Sun Nov 16 00:11:06 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 15 Nov 2014 23:11:06 +0000
Subject: [issue22879] Make set's add and discard methods return useful
 information
In-Reply-To: <1416091669.05.0.557383072226.issue22879@psf.upfronthosting.co.za>
Message-ID: <1416093066.22.0.136432624826.issue22879@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  The fact that it could be either way around makes it less attractive.  That is, if it isn't intuitively obvious what the truth value would mean, it is probably a bad idea to have this behavior.

----------
nosy: +r.david.murray, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22879>
_______________________________________

From report at bugs.python.org  Sun Nov 16 01:39:08 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 16 Nov 2014 00:39:08 +0000
Subject: [issue22878] PEP 477 (ensurepip backport to 2.7.9): "make install"
 and "make altinstall" integration
Message-ID: <1416098348.4.0.722200841811.issue22878@psf.upfronthosting.co.za>


New submission from Ned Deily:

As part of PEP 477, the attached patch backports to Python 2.7.9 the configure and Makefile integration for ensurepip from Python 3 (PEP 453 / Issue19553).  As described in PEP 477, for Python 2 ensurepip is not enabled by default by configure.  If there are no comments, I'll plan to apply it for 2.7.9 in a few days.

----------
keywords: +patch
nosy: +ncoghlan
stage:  -> patch review
Added file: http://bugs.python.org/file37203/pep477_make.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22878>
_______________________________________

From report at bugs.python.org  Sun Nov 16 01:53:37 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Nov 2014 00:53:37 +0000
Subject: [issue22879] Make set's add and discard methods return useful
 information
In-Reply-To: <1416091669.05.0.557383072226.issue22879@psf.upfronthosting.co.za>
Message-ID: <1416099217.97.0.149106761276.issue22879@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This has come up once before and it was rejected for several reasons including the one David mentioned.

In Python, code reads more clearly with the usual:

   for elem in iterable:
       if elem not in seen:
           seen.add(elem)
           do_something(elem)

Than with:

   for elem in iterable:
       if not seen.add(elem):
           do_something(elem)


That latter is less self-evident about what it does.

Also, I think there were lessons drawn from Guido's decision to not incorporate the C-language feature of both assigning and testing in a conditional:  

    while((c = fgetc(fp)) != EOF)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22879>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:00:02 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 16 Nov 2014 03:00:02 +0000
Subject: [issue22823] Use set literals instead of creating a set from a list
In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za>
Message-ID: <1416106802.77.0.502859845381.issue22823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

OK, someone can copy and paste this.

non_defaults = {
     '__get__', '__set__', '__delete__', '__reversed__', '__missing__',
     '__reduce__', '__reduce_ex'__, '__getinitargs__', '__getnewargs__',
     '__getstate__', '__setstate__', '__getformat__', '__setformat__',
     '__repr__', '__dir__', '__subclasses__', '__format__',
)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22823>
_______________________________________

From report at bugs.python.org  Sun Nov 16 04:25:58 2014
From: report at bugs.python.org (Roy Smith)
Date: Sun, 16 Nov 2014 03:25:58 +0000
Subject: [issue22880] hmac.new docs show optional args incorrectly
Message-ID: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>


New submission from Roy Smith:

At https://docs.python.org/2/library/hmac.html, hmac.new() is shown as

hmac.new(key[, msg[, digestmod]])

This implies that digestmod can only be given if msg is given.  This is incorrect.  Either can be given without the other.

----------
assignee: docs at python
components: Documentation
messages: 231231
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: hmac.new docs show optional args incorrectly
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22880>
_______________________________________

From report at bugs.python.org  Sun Nov 16 06:50:11 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 16 Nov 2014 05:50:11 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1416117011.14.0.0841316215303.issue22536@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Sun Nov 16 06:52:29 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Nov 2014 05:52:29 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416117149.96.0.527880182935.issue22869@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It turns out *all* the global config variations are in pydebug.h (and they're basically the only thing in there, aside from the environment variable access macro). That seems a little weird to me (perhaps historical due to the early global config variables being debugging related?), but for now I've just added a couple of comments cross referencing pydebug.h from pylifecycle.c and vice-versa.

The latest version of the patch:

- moves the reference count & block allocation printing to object.[ch] as Antoine suggested (Macro = _PY_DEBUG_PRINT_TOTAL_REFS(); Symbol = _PyDebug_PrintTotalRefs())

- moves Py_OptimizeFlag to pylifecycle.c together with the other global configuration flags (and tweaks the order of definitions to exactly match the order of declarations in pydebug.h)

Since the extern declaration is actually there in pydebug.h, the reference to Py_InspectFlag from pythonrun.c is actually fine for now (although removing that direct reference will likely end up being part of the PEP 432 implementation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sun Nov 16 06:55:12 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Nov 2014 05:55:12 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416117312.95.0.671068817352.issue22869@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think this is ready to go now, unless anyone spots any major flaws I missed.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file37204/split_pythonrun_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sun Nov 16 06:57:06 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Nov 2014 05:57:06 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416117426.14.0.833896671849.issue22869@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Oops, "global config variations" above should have been "global config variable declarations". I guess my brain decided that was too much typing and jammed the last two words together :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sun Nov 16 09:17:12 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 08:17:12 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416125832.69.0.293465584267.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Here's another idea. There could be two implementations of "slice", one that uses Python object indices (as currently) and one that has Py_ssize_t indices  (and properties for the start/stop/step attributes). Similar to what Unicode strings do, the slice type would decide which to use at instantiation time.

The internals of PySliceObject are not part of the stable ABI, and the normal way to figure out the indices is PySlice_GetIndicesEx(), which would be adapted accordingly.

This breaks compatibility with some C extensions that access the slice attributes directly, but that should be rare, given how complex index calculations are.

This change is certainly more invasive than adding Py_ssize_t fields to the existing object, though.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sun Nov 16 09:22:59 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 16 Nov 2014 08:22:59 +0000
Subject: [issue22880] hmac.new docs show optional args incorrectly
In-Reply-To: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>
Message-ID: <1416126179.08.0.121560201279.issue22880@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but the signature is correct.

>From https://docs.python.org/devguide/documenting.html#information-units

    "The signature should include the parameters, enclosing optional parameters in brackets."

See also http://sphinx-doc.org/domains.html#python-signatures

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22880>
_______________________________________

From report at bugs.python.org  Sun Nov 16 09:35:48 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 08:35:48 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416126948.35.0.575050370102.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Thanks for the review, Serhiy. There isn't really a reason not to 'normalise' the Python step object to None when 1 is passed from C code, so I updated the patch to do that.

Regarding on-demand creation of the Python values, the problem is that C code that accesses the struct fields directly would not be prepared to find NULL values in them, so this would be a visible change and potential source of crashes. However, my guess is that this would rarely be a problem (see my last comment on changing the slice type internally).

----------
Added file: http://bugs.python.org/file37205/cache_slice_indices.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sun Nov 16 10:47:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 09:47:57 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1416125832.69.0.293465584267.issue18813@psf.upfronthosting.co.za>
Message-ID: <3447886.ZkjLYbKJZ6@raxxla>


Serhiy Storchaka added the comment:

> There could be two implementations of "slice", one that
> uses Python object indices (as currently) and one that has Py_ssize_t
> indices  (and properties for the start/stop/step attributes).

Agree, this idea LGTM. Single boolean flag should be enough to switch between 
implementations. This shouldn't break well written code. The PySliceObject 
structure is not a part of stable API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sun Nov 16 10:50:17 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 09:50:17 +0000
Subject: [issue22881] show median in benchmark results
Message-ID: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The median tends to give a better idea about benchmark results than an average as it inherently ignores outliers.

----------
components: Benchmarks
files: show_median.patch
keywords: patch
messages: 231239
nosy: pitrou, scoder
priority: normal
severity: normal
status: open
title: show median in benchmark results
type: enhancement
Added file: http://bugs.python.org/file37206/show_median.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22881>
_______________________________________

From report at bugs.python.org  Sun Nov 16 11:06:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 10:06:58 +0000
Subject: [issue22881] show median in benchmark results
In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za>
Message-ID: <1416132418.78.0.814757345562.issue22881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In case of even number of samples the median value is calculated as arithmetic mean of two middle samples.

med_base = (base_times[len(base_times)//2] + base_times[(len(base_times)+1)//2]) / 2

----------
nosy: +serhiy.storchaka
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22881>
_______________________________________

From report at bugs.python.org  Sun Nov 16 11:14:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 10:14:21 +0000
Subject: [issue22881] show median in benchmark results
In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za>
Message-ID: <1416132861.55.0.963521811539.issue22881@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg231240

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22881>
_______________________________________

From report at bugs.python.org  Sun Nov 16 11:14:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 10:14:45 +0000
Subject: [issue22881] show median in benchmark results
In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za>
Message-ID: <1416132885.21.0.701483716055.issue22881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In case of even number of samples the median value is calculated as arithmetic mean of two middle samples.

med_base = (base_times[len(base_times)//2] + base_times[(len(base_times)-1)//2]) / 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22881>
_______________________________________

From report at bugs.python.org  Sun Nov 16 11:21:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 10:21:13 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1416133273.42.0.898730246944.issue17293@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, socket.gaierror was not made an alias of OSError, only subclass of it. Well, we can apply the same patch to all releases. Does it fix tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Sun Nov 16 11:28:15 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 10:28:15 +0000
Subject: [issue22881] show median in benchmark results
In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za>
Message-ID: <1416133695.43.0.0779024522265.issue22881@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Fair enough, patch updated.

----------
Added file: http://bugs.python.org/file37207/show_median.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22881>
_______________________________________

From report at bugs.python.org  Sun Nov 16 11:41:41 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 10:41:41 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416134501.14.0.582661027508.issue18813@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I reran the benchmarks with the fast path in _PyEval_SliceIndex() and the results are not conclusive. There is no clear indication that it improves the performance.

The problem is that most slices have no step, many slices are open ended on at least one side (i.e. usually have one or two fields set to None) and they are only used once, so integer index optimisations can only have a limited impact compared to instantiating the slice object in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sun Nov 16 14:07:50 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 13:07:50 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
Message-ID: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>


New submission from Ludovic Gasc:

Hi,

To install easily Python 3.4.2 on Linux, I use Pythonz: http://saghul.github.io/pythonz/

I've discovered that, depends on the packages already installed on Linux, I don't have the same Python each time after compilation on servers.
Some features could missing, like pip, if you don't install some packages.

I've made a pull request in Pythonz with the list of packages you need to avoid that: https://github.com/saghul/pythonz#before-installing-pythons-via-pythonz

But, for me, this packages list should be in official Python documentation directly.

I've tested this packages list on Debian (Squeeze, Wheezy, Jessie, Sid), Ubuntu (12.04, 14.04) and CentOS 6.

Thanks for the merge.

Regards.

----------
assignee: docs at python
components: Documentation
files: build_dep_python.patch
keywords: patch
messages: 231245
nosy: Ludovic.Gasc, docs at python
priority: normal
severity: normal
status: open
title: [patch] Linux packages you need to compile Python with all dependencies
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37208/build_dep_python.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:12:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 14:12:26 +0000
Subject: [issue22883] Get rid of references to PyInt in Py3 sources
Message-ID: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are several references to PyInt in outdated comments in .c and .h files:

$ find * -name '*.[ch]' -exec egrep -n --color -- 'PyInt\b' '{}' +
Include/longobject.h:34:/* It may be useful in the future. I've added it in the PyInt -> PyLong
Modules/fcntlmodule.c:157:       into either a large positive number (PyLong or PyInt on 64-bit
Modules/fcntlmodule.c:158:       platforms) or a negative number on others (32-bit PyInt)
Modules/_json.c:813:        PyInt, PyLong, or PyFloat.
Modules/itertoolsmodule.c:3869:    assert(cnt != PY_SSIZE_T_MAX && long_cnt == NULL && long_step==PyInt(1));
Python/ceval.c:4606:/* Extract a slice index from a PyInt or PyLong or an object with the

----------
components: Extension Modules, Interpreter Core
messages: 231246
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Get rid of references to PyInt in Py3 sources
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22883>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:32:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 14:32:59 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>
Message-ID: <1416148379.7.0.709724571246.issue18813@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed, PySequence_GetSlice() is used only in few performance non-critical places in the stdlib, PySequence_Set/DelSlice() are not used at all. So looks as this way doesn't speed up any code.

As for faster_PyEval_SliceIndex.patch see issue17576. May be such optimization is not always correct (only for exact PyLong). And why you pass through fast path only if -1<= Py_SIZE(v) <=1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:45:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 14:45:37 +0000
Subject: [issue22599] traceback: errors in the linecache module at exit
In-Reply-To: <1412940961.34.0.0781587147709.issue22599@psf.upfronthosting.co.za>
Message-ID: <1416149137.55.0.0210589025012.issue22599@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> haypo
dependencies: +Add a function to know about interpreter shutdown
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22599>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:50:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 14:50:08 +0000
Subject: [issue22696] Add a function to know about interpreter shutdown
In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za>
Message-ID: <1416149408.0.0.281274445714.issue22696@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm +0 for is_finalizing.

There is a typo in the docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22696>
_______________________________________

From report at bugs.python.org  Sun Nov 16 15:58:06 2014
From: report at bugs.python.org (Kevin Orr)
Date: Sun, 16 Nov 2014 14:58:06 +0000
Subject: [issue22884] argparse.FileType.__call__ returns unwrapped sys.stdin
 and stdout
Message-ID: <1416149886.65.0.378402881729.issue22884@psf.upfronthosting.co.za>


New submission from Kevin Orr:

When one uses a file object returned by `FileType.__call__` as a context manager, `sys.stdin`'s or `sys.stdout`'s `__exit__` will be triggered upon exit of the context, in turn calling their `close` method.

Perhaps the issue is that `sys.stdin` and `sys.stdout` have poor `__exit__` methods, but my proposal (and it's not a particularly clean one) is to override the file object's `__exit__` if it happens to be either `sys.stdin` or `sys.stdout` to simply return True when called.

----------
components: Library (Lib)
messages: 231249
nosy: keviv
priority: normal
severity: normal
status: open
title: argparse.FileType.__call__ returns unwrapped sys.stdin and stdout
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22884>
_______________________________________

From report at bugs.python.org  Sun Nov 16 16:06:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Nov 2014 15:06:13 +0000
Subject: [issue17611] Move unwinding of stack for "pseudo exceptions" from
 interpreter to compiler.
In-Reply-To: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>
Message-ID: <1416150373.1.0.93356100639.issue17611@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I like the idea. I have not make faultfinding review yet, but one thing is questionable to me.

Is it necessary to get rid of the END_FINALLY opcode?

Currently Python code

    try:
        stmt1
    finally:
        stmt2

is compiled to:

    SETUP_FINALLY L1
    // stmt1
    POP_BLOCK
    LOAD_CONST None
L1: // stmt2
    END_FINALLY

With the patch it is compiled to:

    SETUP_FINALLY L1
    // stmt1
    POP_BLOCK
    // stmt2
    JUMP_ABSOLUTE L2
L1: // stmt2
    RERAISE
L2:

Finally body is duplicated. In case of large finally body this increases the size of the bytecode. Line numbers are duplicated in disassembly listing, this is confused. And I afraid that due to increasing the size of the bytecode, some relative jumps can became too long.

If it is absolutely necessary to remove the END_FINALLY opcode, I suggest to generate following bytecode:

    SETUP_FINALLY L1
    // stmt1
    POP_BLOCK
    LOAD_CONST None
L1: // stmt2
    POP_JUMP_IF_FALSE L2
    RERAISE
L2:

But it looks to me that special END_FINALLY opcode which combines POP_JUMP_IF_FALSE/RERAISE would be better for performance and compiled code size.

----------
components: +Interpreter Core
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17611>
_______________________________________

From report at bugs.python.org  Sun Nov 16 16:28:17 2014
From: report at bugs.python.org (Kevin Orr)
Date: Sun, 16 Nov 2014 15:28:17 +0000
Subject: [issue22884] argparse.FileType.__call__ returns unwrapped sys.stdin
 and stdout
In-Reply-To: <1416149886.65.0.378402881729.issue22884@psf.upfronthosting.co.za>
Message-ID: <1416151697.29.0.251421391647.issue22884@psf.upfronthosting.co.za>


Kevin Orr added the comment:

Hmm, not sure why I thought I needed `inline code formatting`. It's all monospace anyway!

Anyway, I'm thinking that adding this somewhere in argparse.py:

class _WrappedIO(object):
    def __init__(self, fileobj):
        self._file = fileobj

    def __exit__(tp, val, tb):
        return True

    def __getattr__(self, name):
        return self._file.__gettattr__(name)

and then applying the attached patch *may* fix this.

----------
keywords: +patch
Added file: http://bugs.python.org/file37209/argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22884>
_______________________________________

From report at bugs.python.org  Sun Nov 16 17:54:44 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 Nov 2014 16:54:44 +0000
Subject: [issue22880] hmac.new docs show optional args incorrectly
In-Reply-To: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>
Message-ID: <1416156884.23.0.453731466503.issue22880@psf.upfronthosting.co.za>


R. David Murray added the comment:

To be clear: this was/is the python2 documentation style.  In python3 we've switched to using keyword argument notation in functions that support specifying optional arguments via keyword (which is many more of the C functions than in python2).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22880>
_______________________________________

From report at bugs.python.org  Sun Nov 16 18:00:49 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 Nov 2014 17:00:49 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416157249.51.0.373639683782.issue22882@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think it is a good idea for us to try to track which packages are needed and what they are named by the various downstreams.  We could document the optional modules by project name, though.  Note also that the devguide does point to the "umbrella" downstream packages that pull in the dependencies needed to build python, where those exist.

It is likely that that section should cross link to the devguide.  The devguide didn't exist when it was written.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Sun Nov 16 18:06:02 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 Nov 2014 17:06:02 +0000
Subject: [issue22884] argparse.FileType.__call__ returns unwrapped sys.stdin
 and stdout
In-Reply-To: <1416149886.65.0.378402881729.issue22884@psf.upfronthosting.co.za>
Message-ID: <1416157562.17.0.677511879018.issue22884@psf.upfronthosting.co.za>


R. David Murray added the comment:

Perhaps instead it could return an io object built from the file descriptor with closefd=False.

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22884>
_______________________________________

From report at bugs.python.org  Sun Nov 16 19:39:01 2014
From: report at bugs.python.org (Stephen Farris)
Date: Sun, 16 Nov 2014 18:39:01 +0000
Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked
 eval() call in dumbdbm module
Message-ID: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za>


New submission from Stephen Farris:

The dumbdbm module uses an unchecked call to eval() in the _update method, which is called in response to a call to dumbdbm.open(), and is used to load the index from the directory file.? This poses a security vulnerability because it allows an attacker to execute arbitrary code on the victim's machine by inserting python code into the DBM directory file.? This vulnerability could allow an attacker to execute arbitrary commands on the victim machine, potentially allowing them to deploy malware, gain system access, destroy files and data, expose sensitive information, etc.

----------
components: Library (Lib)
messages: 231255
nosy: Guido.van.Rossum, lemburg, stephen.farris
priority: normal
severity: normal
status: open
title: Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module
type: security
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22885>
_______________________________________

From report at bugs.python.org  Sun Nov 16 19:43:12 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 16 Nov 2014 18:43:12 +0000
Subject: [issue18813] Speed up slice object processing
In-Reply-To: <1416148379.7.0.709724571246.issue18813@psf.upfronthosting.co.za>
Message-ID: <5468F03E.6000605@behnel.de>


Stefan Behnel added the comment:

> why you pass through fast path only if -1<= Py_SIZE(v) <=1?

It's usually enough, it's the fastest fast path, and it doesn't even need
error handling.

Any slicing where the slice calculation time matters is going to be of
fairly limited size, often involving the values (!) 1 or -1 in the slice
object fields, but definitely small integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18813>
_______________________________________

From report at bugs.python.org  Sun Nov 16 21:01:31 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 20:01:31 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416168091.48.0.23281864511.issue22882@psf.upfronthosting.co.za>


Ludovic Gasc added the comment:

I'm not agree with you: I've lost a lot of time to find all packages I need for that, I've merged information from several blog posts.
I imagine that I'm not alone with this problem.

If you move this information in devguide, most persons don't find this.

Moreover, the names of packages are pretty stable across Linux versions, I don't think we will have a lot of exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Sun Nov 16 21:14:35 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 16 Nov 2014 20:14:35 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416168875.4.0.06849445229.issue22882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

For Ubuntu/debian you can just run:
$ sudo apt-get build-dep python3

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Sun Nov 16 21:46:30 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 20:46:30 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416170790.34.0.00118688608051.issue22882@psf.upfronthosting.co.za>


Ludovic Gasc added the comment:

> $ sudo apt-get build-dep python3

Good to know, I will test for my next deployment.
The only problem with that, if you use a old Debian with a Python3 that need less dependencies that actual version.
But you can add a line for that in documentation if we have the case one day.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Mon Nov 17 00:52:59 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 16 Nov 2014 23:52:59 +0000
Subject: [issue22876] ip_interface can't be broadcast or number net
In-Reply-To: <1416006279.81.0.519383072112.issue22876@psf.upfronthosting.co.za>
Message-ID: <1416181979.77.0.301060149381.issue22876@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The Interface classes are actually designed to cover any association of an IP address with a specific network, not just host interface addresses. We knew it was a slight misnomer when we chose it, but network and broadcast addresses weren't considered special enough to be worth separating out (beyond the distinction present in iterating over the whole network range vs just the host addresses).

It's relatively straightforward to write a helper function that only allows the creation of host interfaces:

    def host_interface(address):
        ifaddr = ip_interface(address)
        if ifaddr.ip == ifaddr.network.network_address:
            raise ValueError("'{}' is a network address".format(ifaddr)
        if ifaddr.ip == ifaddr.network.broadcast_address:
            raise ValueError("'{}' is a broadcast address".format(ifaddr)
        return ifaddr

I'm not sure if it's worthwhile to add such a helper function to the module itself.

One argument in favour of adding it is that it may help to emphasise that the normal ip_interface factory function and the *Interface class constructors are *not* restricted purely to host interfaces, and thus allow network and broadcast addresses to be associated with their corresponding network definition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22876>
_______________________________________

From report at bugs.python.org  Mon Nov 17 01:34:33 2014
From: report at bugs.python.org (Robert Collins)
Date: Mon, 17 Nov 2014 00:34:33 +0000
Subject: [issue22886] TestProgram leaves defaultTestLoader.errors dirty
Message-ID: <1416184473.93.0.181686669268.issue22886@psf.upfronthosting.co.za>


New submission from Robert Collins:

TestProgram leaves defaultTestLoader.errors dirty. This primarily affects tests but it would be good hygiene to clear it at the end of TestProgram.

----------
components: Library (Lib)
messages: 231261
nosy: rbcollins
priority: normal
severity: normal
status: open
title: TestProgram leaves defaultTestLoader.errors dirty
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22886>
_______________________________________

From report at bugs.python.org  Mon Nov 17 03:03:25 2014
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Alberto_Goncalves?=)
Date: Mon, 17 Nov 2014 02:03:25 +0000
Subject: [issue22887] ensurepip and distutils' build_scripts fails on Windows
 when path to Python contains accented characters
Message-ID: <1416189804.36.0.639606237849.issue22887@psf.upfronthosting.co.za>


New submission from Jos? Alberto Goncalves:

Summary:

Python 3.4's venv works fine in Windows, and pip works fine when installing both pure Python libraries and extension modules. However, when the virtual environment is under a path with non-ASCII characters, attempting to install a package that specifies console_scripts or scripts (like pip or mutagen, respectivelly), it fails with encoding errors.

I looked around the Internet for a solution but the best I could find was Issue #10419, which is over 3 years old and is marked as resolved, and couldn't find any other open issue about this.

Details of my case:

I created a Python 3.4 (32-bit) virtualenv via Python Tools for Visual Studio, on windows 8.1 (64-bit), in a folder that is under my home directory (C:\Users\Jos? Alberto\), which happens to contain an accented character, using the latest Python you can download from the homepage.

Via Powershell I activated the virtualenv and tried to execute pip install mutagen (https://pypi.python.org/pypi/mutagen, it is relevant because it specifies scripts in its setup.py). The installation failed with the following error:

Downloading/unpacking mutagen
  Running setup.py (path:C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py) egg_info for
package mutagen

Installing collected packages: mutagen
  Running setup.py install for mutagen
    Traceback (most recent call last):
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 114, in copy_scripts
        shebang.decode('utf-8')
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 14: invalid continuation byte

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py", line 277, in <module>
        """
      File "C:\Python34\lib\distutils\core.py", line 148, in setup
        dist.run_commands()
      File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
        self.run_command(cmd)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\lib\site-packages\setuptools-6.0.2-py3.4.egg\setuptools\command\install.py", line 61, in run
      File "C:\Python34\lib\distutils\command\install.py", line 539, in run
        self.run_command('build')
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build.py", line 126, in run
        self.run_command(cmd_name)
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 50, in run
        self.copy_scripts()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 118, in copy_scripts
        "from utf-8".format(shebang))
    ValueError: The shebang (b'#!C:\\Users\\Jos\xe9 Alberto\\Documents\\podtimizer\\env_podtimizer\\Scripts\\python.exe\n') is not decodable from utf-8

I looked around the Internet for a solution, but the best I could find was the Issue #10419, which is over 3 years old and is marked as closed and resolved. The last comment mentions a fix that was commited to Distribute around that time, with the caveat that entry points script creation would fail if the path contained unencodeable characters (which sounds exactly like the problem I'm having). I Couldn't find an open issue to follow up on this.

I went to the source of the error, around Lib/distutils/command/build_scripts.py:106. Since this is Windows, the result of os.fsencode() uses the encoding 'mbcs' (as reported by Python), then it tries to decode it back using utf-8, and it blows up:

>>> import os
>>> os.fsencode('C:\\Users\\Jos? Alberto\\')
b'C:\\Users\\Jos\xe9 Alberto\\'
>>> 'C:\\Users\\Jos? Alberto\\'.encode('utf-8')
b'C:\\Users\\Jos\xc3\xa9 Alberto\\'

I commented both try..except after the os.fsencode and it worked, but commenting random code whose purpose I don't fully understand doesn't seem like a good strategy.

While testing for the above, I found I couldn't finish installing pip successfully on a virtualenv using just the Python installed from python.org.

On Powershell I created several virtualenvs using C:\Python34\python.exe -m venv. The envs were created successfully, but the pip's console_scripts installation failed silently. I could still run python -m pip and install packages, but the pip.exe files were not created.

I removed pip from the environment's site-packages directory and tried to reinstall it via python -m ensurepip, but instead got the following error:

Installing collected packages: pip
Cleaning up...
  Removing temporary dir C:\Users\Jos? Alberto\test_env3\build...
Exception:
Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 124, in _get_shebang
    shebang.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 15: invalid continuation byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 283, in run
    requirement_set.install(install_options, global_options, root=options.root_path)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1435, in install
    requirement.install(install_options, global_options, *args, **kwargs)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 671, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 901, in move_wheel_files
    pycompile=self.pycompile,
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\wheel.py", line 325, in move_wheel_files
    generated.extend(maker.make(spec))
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 311, in make
    self._make_script(entry, filenames, options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 201, in _make_script
    shebang = self._get_shebang('utf-8', options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 127, in _get_shebang
    'The shebang (%r) is not decodable from utf-8' % shebang)
ValueError: The shebang (b'#!"C:\\Users\\Jos\xe9 Alberto\\test_env3\\Scripts\\python.exe"\n') is not decodable from utf-8

Which is exactly the same issue I was running into with build_scripts, but this time in a similar code within ensurepip's pip wheel. This time I tried again to comment the utf-8 encoding checks, and although ensurepip now finished successfully, the executables failed with "Couldn't create process". This is as far as I could go within my very limited understanding of encoding issues and pip, so I decided to write this issue.

Is it possible to fix this? Is there something I can do to help?

----------
components: Distutils, Library (Lib)
messages: 231262
nosy: dstufft, eric.araujo, gmljosea
priority: normal
severity: normal
status: open
title: ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22887>
_______________________________________

From report at bugs.python.org  Mon Nov 17 03:03:26 2014
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Alberto_Goncalves?=)
Date: Mon, 17 Nov 2014 02:03:26 +0000
Subject: [issue22888] ensurepip and distutils' build_scripts fails on Windows
 when path to Python contains accented characters
Message-ID: <1416189805.26.0.501870497437.issue22888@psf.upfronthosting.co.za>


New submission from Jos? Alberto Goncalves:

Summary:

Python 3.4's venv works fine in Windows, and pip works fine when installing both pure Python libraries and extension modules. However, when the virtual environment is under a path with non-ASCII characters, attempting to install a package that specifies console_scripts or scripts (like pip or mutagen, respectivelly), it fails with encoding errors.

I looked around the Internet for a solution but the best I could find was Issue #10419, which is over 3 years old and is marked as resolved, and couldn't find any other open issue about this.

Details of my case:

I created a Python 3.4 (32-bit) virtualenv via Python Tools for Visual Studio, on windows 8.1 (64-bit), in a folder that is under my home directory (C:\Users\Jos? Alberto\), which happens to contain an accented character, using the latest Python you can download from the homepage.

Via Powershell I activated the virtualenv and tried to execute pip install mutagen (https://pypi.python.org/pypi/mutagen, it is relevant because it specifies scripts in its setup.py). The installation failed with the following error:

Downloading/unpacking mutagen
  Running setup.py (path:C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py) egg_info for
package mutagen

Installing collected packages: mutagen
  Running setup.py install for mutagen
    Traceback (most recent call last):
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 114, in copy_scripts
        shebang.decode('utf-8')
    UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 14: invalid continuation byte

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\build\mutagen\setup.py", line 277, in <module>
        """
      File "C:\Python34\lib\distutils\core.py", line 148, in setup
        dist.run_commands()
      File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
        self.run_command(cmd)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Users\Jos? Alberto\Documents\podtimizer\env_podtimizer\lib\site-packages\setuptools-6.0.2-py3.4.egg\setuptools\command\install.py", line 61, in run
      File "C:\Python34\lib\distutils\command\install.py", line 539, in run
        self.run_command('build')
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build.py", line 126, in run
        self.run_command(cmd_name)
      File "C:\Python34\lib\distutils\cmd.py", line 313, in run_command
        self.distribution.run_command(command)
      File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
        cmd_obj.run()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 50, in run
        self.copy_scripts()
      File "C:\Python34\lib\distutils\command\build_scripts.py", line 118, in copy_scripts
        "from utf-8".format(shebang))
    ValueError: The shebang (b'#!C:\\Users\\Jos\xe9 Alberto\\Documents\\podtimizer\\env_podtimizer\\Scripts\\python.exe\n') is not decodable from utf-8

I looked around the Internet for a solution, but the best I could find was the Issue #10419, which is over 3 years old and is marked as closed and resolved. The last comment mentions a fix that was commited to Distribute around that time, with the caveat that entry points script creation would fail if the path contained unencodeable characters (which sounds exactly like the problem I'm having). I Couldn't find an open issue to follow up on this.

I went to the source of the error, around Lib/distutils/command/build_scripts.py:106. Since this is Windows, the result of os.fsencode() uses the encoding 'mbcs' (as reported by Python), then it tries to decode it back using utf-8, and it blows up:

>>> import os
>>> os.fsencode('C:\\Users\\Jos? Alberto\\')
b'C:\\Users\\Jos\xe9 Alberto\\'
>>> 'C:\\Users\\Jos? Alberto\\'.encode('utf-8')
b'C:\\Users\\Jos\xc3\xa9 Alberto\\'

I commented both try..except after the os.fsencode and it worked, but commenting random code whose purpose I don't fully understand doesn't seem like a good strategy.

While testing for the above, I found I couldn't finish installing pip successfully on a virtualenv using just the Python installed from python.org.

On Powershell I created several virtualenvs using C:\Python34\python.exe -m venv. The envs were created successfully, but the pip's console_scripts installation failed silently. I could still run python -m pip and install packages, but the pip.exe files were not created.

I removed pip from the environment's site-packages directory and tried to reinstall it via python -m ensurepip, but instead got the following error:

Installing collected packages: pip
Cleaning up...
  Removing temporary dir C:\Users\Jos? Alberto\test_env3\build...
Exception:
Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 124, in _get_shebang
    shebang.decode('utf-8')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 15: invalid continuation byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 283, in run
    requirement_set.install(install_options, global_options, root=options.root_path)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1435, in install
    requirement.install(install_options, global_options, *args, **kwargs)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 671, in install
    self.move_wheel_files(self.source_dir, root=root)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 901, in move_wheel_files
    pycompile=self.pycompile,
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\wheel.py", line 325, in move_wheel_files
    generated.extend(maker.make(spec))
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 311, in make
    self._make_script(entry, filenames, options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 201, in _make_script
    shebang = self._get_shebang('utf-8', options=options)
  File "C:\Users\JOSALB~1\AppData\Local\Temp\tmpax00n0z5\pip-1.5.6-py2.py3-none-any.whl\pip\_vendor\distlib\scripts.py", line 127, in _get_shebang
    'The shebang (%r) is not decodable from utf-8' % shebang)
ValueError: The shebang (b'#!"C:\\Users\\Jos\xe9 Alberto\\test_env3\\Scripts\\python.exe"\n') is not decodable from utf-8

Which is exactly the same issue I was running into with build_scripts, but this time in a similar code within ensurepip's pip wheel. This time I tried again to comment the utf-8 encoding checks, and although ensurepip now finished successfully, the executables failed with "Couldn't create process". This is as far as I could go within my very limited understanding of encoding issues and pip, so I decided to write this issue.

Is it possible to fix this? Is there something I can do to help?

----------
components: Distutils, Library (Lib)
messages: 231263
nosy: dstufft, eric.araujo, gmljosea
priority: normal
severity: normal
status: open
title: ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22888>
_______________________________________

From report at bugs.python.org  Mon Nov 17 03:19:34 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 17 Nov 2014 02:19:34 +0000
Subject: [issue22887] ensurepip and distutils' build_scripts fails on Windows
 when path to Python contains accented characters
In-Reply-To: <1416189804.36.0.639606237849.issue22887@psf.upfronthosting.co.za>
Message-ID: <1416190774.37.0.519332204817.issue22887@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ensurepip and distutils' build_scripts fails on Windows when path to Python contains accented characters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22887>
_______________________________________

From report at bugs.python.org  Mon Nov 17 03:51:25 2014
From: report at bugs.python.org (koobs)
Date: Mon, 17 Nov 2014 02:51:25 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1416192685.08.0.267412607517.issue17293@psf.upfronthosting.co.za>


koobs added the comment:

I don't have the environment to test here. Can you run a custom build on the buildbots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Mon Nov 17 04:31:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:31:43 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416195103.83.0.626052853135.issue22882@psf.upfronthosting.co.za>


R. David Murray added the comment:

The fact that it cost you a lot of time buttresses my point.  Any documentation we write is likely to get stale; it is only the downstream that knows when these things change and could maintain such a document.  And the easy answer is as Andrew indicated, which is maintained by downstream.  That said, if the various downstreams are using a unified set of names, then the equation would change.  The fact that you had separate sections for separate distributions argues that that is not (yet?) the case, though.

The build instructions in the devguide are more likely to be kept up to date, which is why I suggested we should cross link to them from the main build documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Mon Nov 17 04:31:51 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:31:51 +0000
Subject: [issue22882] [patch] Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416195111.87.0.181250038549.issue22882@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Mon Nov 17 04:41:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:41:38 +0000
Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked
 eval() call in dumbdbm module
In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za>
Message-ID: <1416195698.74.0.927654789774.issue22885@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22885>
_______________________________________

From report at bugs.python.org  Mon Nov 17 04:48:22 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:48:22 +0000
Subject: [issue22882] Document Linux packages you need to compile Python with
 all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416196102.52.0.620204822828.issue22882@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: [patch] Linux packages you need to compile Python with all dependencies -> Document Linux packages you need to compile Python with all dependencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22882>
_______________________________________

From report at bugs.python.org  Mon Nov 17 06:38:20 2014
From: report at bugs.python.org (Kevin Burke)
Date: Mon, 17 Nov 2014 05:38:20 +0000
Subject: [issue22889] set a timeout for DNS lookups
Message-ID: <1416202700.62.0.764636248133.issue22889@psf.upfronthosting.co.za>


New submission from Kevin Burke:

It would be nice to be able to set a timeout for DNS lookups in the event of a DNS server failure.

1. Set your DNS to something like 123.123.123.123 or any other host that is not listening for DNS queries on port 53.

2. Run requests.get('http://jsonip.com', timeout=3), or similar using urllib/http.client/httplib

3. Observe that the wall clock time is 2 minutes or higher.

It's known that a timeout value does not correspond to wall clock time, but this can be an unexpected cause of latency in http client requests, and is completely uncontrollable from client code (unless the user resolves DNS themselves). 

For a comparison, Go provides this functionality, see for example https://code.google.com/p/go/source/browse/src/pkg/net/lookup.go?name=release#55

----------
components: Library (Lib)
messages: 231266
nosy: kevinburke
priority: normal
severity: normal
status: open
title: set a timeout for DNS lookups
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22889>
_______________________________________

From report at bugs.python.org  Mon Nov 17 07:51:20 2014
From: report at bugs.python.org (eryksun)
Date: Mon, 17 Nov 2014 06:51:20 +0000
Subject: [issue22888] ensurepip and distutils' build_scripts fails on Windows
 when path to Python contains accented characters
In-Reply-To: <1416189805.26.0.501870497437.issue22888@psf.upfronthosting.co.za>
Message-ID: <1416207080.7.0.507608534338.issue22888@psf.upfronthosting.co.za>


eryksun added the comment:

On Windows, shouldn't copy_scripts use UTF-8 instead of os.fsencode (MBCS)? The Python launcher executes the shebang line on Windows, and it defaults to UTF-8 if a script doesn't have a BOM. See line 1105 in maybe_handle_shebang:

https://hg.python.org/cpython/file/ab2c023a9432/PC/launcher.c#l1064

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22888>
_______________________________________

From report at bugs.python.org  Mon Nov 17 08:41:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 07:41:25 +0000
Subject: [issue22890] StringIO.StringIO pickled in 2.7 is not unpickleable on
 3.x
Message-ID: <1416210085.6.0.932097721403.issue22890@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

StringIO.StringIO is pickleable and unpickleable on 2.7 but is not unpickleable on 3.x.

Python 2.7:
>>> import pickle, StringIO
>>> pickle.dumps(StringIO.StringIO('abc'), 2)
'\x80\x02(cStringIO\nStringIO\nq\x00oq\x01}q\x02(U\tsoftspaceq\x03K\x00U\x07buflistq\x04]q\x05U\x03posq\x06K\x00U\x03lenq\x07K\x03U\x06closedq\x08\x89U\x03bufq\tU\x03abcq\nub.'
>>> pickle.loads(b'\x80\x02(cStringIO\nStringIO\nq\x00oq\x01}q\x02(U\tsoftspaceq\x03K\x00U\x07buflistq\x04]q\x05U\x03posq\x06K\x00U\x03lenq\x07K\x03U\x06closedq\x08\x89U\x03bufq\tU\x03abcq\nub.')
<StringIO.StringIO instance at 0xb70c122c>

On 3.x I got an error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: _io.StringIO.__setstate__ argument should be 4-tuple, got dict

----------
components: Library (Lib)
messages: 231268
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: StringIO.StringIO pickled in 2.7 is not unpickleable on 3.x
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22890>
_______________________________________

From report at bugs.python.org  Mon Nov 17 08:47:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 07:47:20 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1416210440.32.0.975546643673.issue18473@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes multiple reversible mappings.

Mappings for StringIO and cStringIO is removed at all because cStringIO.StringIO is not pickleable on 2.7 at all and pickled StringIO.StringIO is not compatible with 3.x (issue22890).

----------
Added file: http://bugs.python.org/file37210/pickle_fix_import.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Mon Nov 17 08:47:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 07:47:49 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1416210469.8.0.381695624215.issue18473@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:12:12 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 08:12:12 +0000
Subject: [issue20434] Fix error handler of _PyString_Resize() on allocation
 failure
In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za>
Message-ID: <1416211932.03.0.735524420261.issue20434@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is there anything left for this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20434>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:12:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 08:12:55 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416211975.73.0.36764347152.issue11145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review of the patch?

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:26:11 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 08:26:11 +0000
Subject: [issue19687] Fixes for elementtree integer overflow
In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za>
Message-ID: <1416212771.82.0.124390756823.issue19687@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/issue19687>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:27:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 08:27:58 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1416212878.7.0.30609861669.issue19883@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19883>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:42:36 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 08:42:36 +0000
Subject: [issue22889] set a timeout for DNS lookups
In-Reply-To: <1416202700.62.0.764636248133.issue22889@psf.upfronthosting.co.za>
Message-ID: <1416213756.61.0.345703648379.issue22889@psf.upfronthosting.co.za>


R. David Murray added the comment:

As far as I know, the libc dns timeout is controlled by /etc/resolv.conf (or whatever the Windows equivalent is), and libc doesn't provide any way for an application to override this.  There is no mention of timeout on the resolver(3) man page.   Do you know of a way?  (One that doesn't change global state.)  (In theory one could re-implement a DNS resolver client, but that is not something CPython is going to do :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22889>
_______________________________________

From report at bugs.python.org  Mon Nov 17 09:50:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 08:50:52 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1416214252.43.0.606415203602.issue18697@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The same issue exists for other types. E.g. PyLong_* functions have Python long argument named as p, obj and pylong, PyFloat_* -- p and pyfloat, PyList_* -- p and list, PyDict_* -- p, a and mapping, PyBytes_* -- o, obj, string and bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Mon Nov 17 10:47:52 2014
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 17 Nov 2014 09:47:52 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416217672.1.0.680904764148.issue11145@psf.upfronthosting.co.za>


Armin Rigo added the comment:

It's seriously obscure to call a user-defined __oct__ method and then mangle the resulting string in ways that only make sense if the __oct__ method returned something reasonable.

The patch is probably a little more complicated than it could be.  For example, I don't understand the special cases for `llen <= 1`: I don't think `PyString_FromStringAndSize(NULL, 1)` can return an existing object.  And if you cut off the final 'L' you don't replace it with '\0' any longer, which could in theory break some callers expecting to see a null-terminated string here.  PyErr_Format() should use `%.200s` for `tp_name`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 10:51:35 2014
From: report at bugs.python.org (Dave Tian)
Date: Mon, 17 Nov 2014 09:51:35 +0000
Subject: [issue22870] urlopen timeout failed with SSL socket
In-Reply-To: <1416076719.36.0.739308342008.issue22870@psf.upfronthosting.co.za>
Message-ID: <47B4C7C1-D273-4DF0-8DCD-AA1C14DC4D4A@gmail.com>


Dave Tian added the comment:

Alright. The issued URL of my case is here: www.5giay.vn
Nor am I a ssl dev...Here is what happens after further debugging: PySSL_SSLread() returns 1/2 bytes without any error/timeout per call. readline() in socket.py keeps looping. Occasionally, it may break out because of a newline recv?d. However, readheaders() in httplib.py repeats the readline() again because of another while True loop. I have no idea why I?ve got only 1/2 bytes recv?d from SSLread(). I am using my Mac OS for testing. Hope this is clear for further investigation if anyone would like to dig in.

Dave Tian
dave.jing.tian at gmail.com

> On Nov 16, 2014, at 2:38 AM, R. David Murray <report at bugs.python.org> wrote:
> 
> 
> R. David Murray added the comment:
> 
> I won't be the one, as I'm not conversant with the ssl C code.  What would be helpful right now would be a recipe for reproducing the problem.
> 
> ----------
> nosy: +alex, pitrou
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22870>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22870>
_______________________________________

From report at bugs.python.org  Mon Nov 17 11:42:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 10:42:17 +0000
Subject: [issue22079] Ensure in PyType_Ready() that base class of static type
 is static
In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>
Message-ID: <1416220937.56.0.317846493179.issue22079@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37211/issue22079.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22079>
_______________________________________

From report at bugs.python.org  Mon Nov 17 11:42:24 2014
From: report at bugs.python.org (Alexander Todorov)
Date: Mon, 17 Nov 2014 10:42:24 +0000
Subject: [issue22891] [patch]: code removal from urllib.parse.urlsplit()
Message-ID: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za>


New submission from Alexander Todorov:

In the urllib.parse (or urlparse on Python 2.X) module there is this function:

    157 def urlsplit(url, scheme='', allow_fragments=True):
    158     """Parse a URL into 5 components:
    159     <scheme>://<netloc>/<path>?<query>#<fragment>
    160     Return a 5-tuple: (scheme, netloc, path, query, fragment).
    161     Note that we don't break the components up in smaller bits
    162     (e.g. netloc is a single string) and we don't expand % escapes."""
    163     allow_fragments = bool(allow_fragments)
    164     key = url, scheme, allow_fragments, type(url), type(scheme)
    165     cached = _parse_cache.get(key, None)
    166     if cached:
    167         return cached
    168     if len(_parse_cache) >= MAX_CACHE_SIZE: # avoid runaway growth
    169         clear_cache()
    170     netloc = query = fragment = ''
    171     i = url.find(':')
    172     if i > 0:
    173         if url[:i] == 'http': # optimize the common case
    174             scheme = url[:i].lower()
    175             url = url[i+1:]
    176             if url[:2] == '//':
    177                 netloc, url = _splitnetloc(url, 2)
    178             if allow_fragments and '#' in url:
    179                 url, fragment = url.split('#', 1)
    180             if '?' in url:
    181                 url, query = url.split('?', 1)
    182             v = SplitResult(scheme, netloc, url, query, fragment)
    183             _parse_cache[key] = v
    184             return v
    185         for c in url[:i]:
    186             if c not in scheme_chars:
    187                 break
    188         else:
    189             scheme, url = url[:i].lower(), url[i+1:]
    190 
    191     if url[:2] == '//':
    192         netloc, url = _splitnetloc(url, 2)
    193     if allow_fragments and '#' in url:
    194         url, fragment = url.split('#', 1)
    195     if '?' in url:
    196         url, query = url.split('?', 1)
    197     v = SplitResult(scheme, netloc, url, query, fragment)
    198     _parse_cache[key] = v
    199     return v



There is an issue here (or a few of them) as follows:

* if url[:1] is already lowercase (equals "http") (line 173) then .lower() on  line 174 is reduntant:
174    scheme = url[:i].lower() # <--- no need for .lower() b/c value is "http"


* OTOH line 173 could refactor the condition and match URLs where the scheme is uppercase. For example
    173         if url[:i].lower() == 'http': # optimize the common case

* The code as is returns the same results (as far as I've tested it) for both:
urlsplit("http://github.com/atodorov/repo.git?param=value#myfragment")
urlsplit("HTTP://github.com/atodorov/repo.git?param=value#myfragment")
urlsplit("HTtP://github.com/atodorov/repo.git?param=value#myfragment")

but the last 2 invocations also go through lines 185-199


* Lines 174-184 are essentially the same as lines 189-199. The only optimization I can see is avoiding the for loop around lines 185-187 which checks for valid characters in the URL scheme and executes only a few loops b/c scheme names are quite short usually.


My personal vote goes for removal of lines 173-184. 


Version-Release number of selected component (if applicable):

This is present in both Python 3 and Python 2 on all versions I have access to:

python3-libs-3.4.1-16.fc21.x86_64.rpm
python-libs-2.7.8-5.fc21.x86_64.rpm
python-libs-2.7.5-16.el7.x86_64.rpm
python-libs-2.6.6-52.el6.x86_64

Versions are from Fedora Rawhide and RHEL. Also the same code is present in the Mercurial repository.

Bug first reported as
https://bugzilla.redhat.com/show_bug.cgi?id=1160603

and now filing here for upstream consideration.

----------
components: Library (Lib)
files: urlparse_refactor.patch
keywords: patch
messages: 231278
nosy: Alexander.Todorov
priority: normal
severity: normal
status: open
title: [patch]: code removal from urllib.parse.urlsplit()
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/file37212/urlparse_refactor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22891>
_______________________________________

From report at bugs.python.org  Mon Nov 17 11:47:04 2014
From: report at bugs.python.org (Francis MB)
Date: Mon, 17 Nov 2014 10:47:04 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1416211975.73.0.36764347152.issue11145@psf.upfronthosting.co.za>
Message-ID: <5469D201.2020902@email.de>


Francis MB added the comment:

I'm not sure if it's relevant but in the patch you changed
previous 'assert(check)' with 'if (not check) goto error'.
But the new patch code adds 'assert(len == 0 || Py_REFCNT(r1) == 1);'

Just curious, is there a reason why couldn't be in the same way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 12:55:45 2014
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 17 Nov 2014 11:55:45 +0000
Subject: [issue20434] Fix error handler of _PyString_Resize() on allocation
 failure
In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za>
Message-ID: <1416225345.68.0.627119015371.issue20434@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Nope, closing as fixed :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20434>
_______________________________________

From report at bugs.python.org  Mon Nov 17 13:32:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 12:32:29 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416227549.47.0.881554060073.issue11145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Arigo.

Here is updated patch.

Note that the patch also fixes a reference leak if llen > INT_MAX.

----------
Added file: http://bugs.python.org/file37213/issue11145_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 13:36:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 12:36:14 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416227774.48.0.785145478015.issue11145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Just curious, is there a reason why couldn't be in the same way?

Old asserts depend on user code, new asserts check internal consistency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 13:41:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 12:41:35 +0000
Subject: [issue22067] time_test fails after strptime()
In-Reply-To: <1406300706.97.0.297116152609.issue22067@psf.upfronthosting.co.za>
Message-ID: <1416228095.48.0.258545849738.issue22067@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +belopolsky, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22067>
_______________________________________

From report at bugs.python.org  Mon Nov 17 14:28:24 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 17 Nov 2014 13:28:24 +0000
Subject: [issue22891] code removal from urllib.parse.urlsplit()
In-Reply-To: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za>
Message-ID: <1416230904.11.0.435006007412.issue22891@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +orsenthil
stage:  -> patch review
title: [patch]: code removal from urllib.parse.urlsplit() -> code removal from urllib.parse.urlsplit()
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22891>
_______________________________________

From report at bugs.python.org  Mon Nov 17 15:23:35 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 17 Nov 2014 14:23:35 +0000
Subject: [issue22891] code removal from urllib.parse.urlsplit()
In-Reply-To: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za>
Message-ID: <1416234215.0.0.768012461138.issue22891@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for filing this. Does test cases pass after removal of those lines? (I will be surprised) and if the tests fail, then after analyzing it, this could only be considered a new change (thus change to made in latest python) in order not to break compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22891>
_______________________________________

From report at bugs.python.org  Mon Nov 17 16:37:18 2014
From: report at bugs.python.org (Martin Gignac)
Date: Mon, 17 Nov 2014 15:37:18 +0000
Subject: [issue22892] Typo in Library's 'threading' module section
Message-ID: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>


New submission from Martin Gignac:

There is an extraenous asterisk in the constructor description for class 'threading.Thread' in section 17.1.2. "Thread Objects" of the 'threading' module in the Python Standard Library documenation.

(patch attached)

----------
assignee: docs at python
components: Documentation
files: threading.rst.patch
keywords: patch
messages: 231284
nosy: docs at python, techstone
priority: normal
severity: normal
status: open
title: Typo in Library's 'threading' module section
versions: Python 3.4
Added file: http://bugs.python.org/file37214/threading.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22892>
_______________________________________

From report at bugs.python.org  Mon Nov 17 16:48:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 15:48:39 +0000
Subject: [issue22892] Typo in Library's 'threading' module section
In-Reply-To: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>
Message-ID: <1416239319.61.0.0449546754397.issue22892@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for taking the time to make a report, but that is not a typo.  That asterisk indicates that daemon is a keyword only argument, and is standard python3 syntax.  You can see it if you follow the source link to the threading module.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22892>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:02:06 2014
From: report at bugs.python.org (Martin Gignac)
Date: Mon, 17 Nov 2014 16:02:06 +0000
Subject: [issue22892] Typo in Library's 'threading' module section
In-Reply-To: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>
Message-ID: <1416240126.45.0.208656854259.issue22892@psf.upfronthosting.co.za>


Martin Gignac added the comment:

Sorry for that. I've read up PEP 3102 and now understand what you meant.

Sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22892>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:30:13 2014
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 17 Nov 2014 16:30:13 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416241813.5.0.319754008461.issue11145@psf.upfronthosting.co.za>


Armin Rigo added the comment:

+        if (Py_REFCNT(result) == 1)
+            buf[len] = '\0';

...and if the refcount is not equal to 1, then too bad, we won't null-terminate the string and hope that nobody crashes because of this.??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 17:50:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 16:50:42 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1416241813.5.0.319754008461.issue11145@psf.upfronthosting.co.za>
Message-ID: <3108248.KrJkWLAJK8@raxxla>


Serhiy Storchaka added the comment:

If the refcount is not equal to 1, we will copy the content to new null-
terminated string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 18:33:45 2014
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 17 Nov 2014 17:33:45 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416245625.61.0.0186236689431.issue11145@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Ah, sorry.  Ok.  Now a different issue: the user-defined function can return an interned string.  If it has a refcount of 1, _PyString_FormatLong() will mutate it.  Then when we DECREF it, string_dealloc() will not find it any more in the interned dict and crash with a fatal error.

Note that I'm mostly having fun finding holes in delicate logic, like mutating strings in-place.  It would be much more simple to either (1) stop calling the user-defined functions and behave similarly to most other built-in types; or (2) stop trying to mutate that poor string in-place and always just create a new one. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 18:58:53 2014
From: report at bugs.python.org (Kevin Burke)
Date: Mon, 17 Nov 2014 17:58:53 +0000
Subject: [issue22889] set a timeout for DNS lookups
In-Reply-To: <1416202700.62.0.764636248133.issue22889@psf.upfronthosting.co.za>
Message-ID: <1416247133.35.0.209325008423.issue22889@psf.upfronthosting.co.za>


Kevin Burke added the comment:

Hi,
You are correct, there's no way to set it in the C API. Go works around this by resolving addresses in a goroutine. I was wondering if something similar would be possible in Python (for people who set a timeout in the interface).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22889>
_______________________________________

From report at bugs.python.org  Mon Nov 17 19:54:09 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 18:54:09 +0000
Subject: [issue22889] set a timeout for DNS lookups
In-Reply-To: <1416202700.62.0.764636248133.issue22889@psf.upfronthosting.co.za>
Message-ID: <1416250449.98.0.457564433482.issue22889@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, my apologies.  I totally missed your link to the go example when I first read your message.

Yes, Python supports the equivalent.  In the asyncio module, which is our closest equivalent to goroutines, the functionality exists implicitly: the base event loop has a getaddrinfo coroutine that is used for DNS lookup, and it is run in a separate thread to keep from blocking the event loop.  If you time out (wait_for with a timeout) a coroutine that ends up doing a DNS request, your wait_for call will time out whether or not the getaddrinfo DNS lookup has timed out.

Using asyncio isn't quite as simple as prefixing a function name with 'go', but it isn't all that hard, either.  Nevertheless, if you aren't using asyncio for the rest of your program, it probably makes more sense to write a function that launches a thread to do the getaddrinfo and does a wait on the thread with a timeout.  (But you might want to check out if asyncio applies to your overall problem.)

So yes, Python can do this, but I don't think it makes sense to build it in to the stdlib's socket module (say), since unlike go async and threading aren't part of the core language but are instead libraries themselves.  asyncio already has it built in.  For the thread based version, putting a recipe on one of the recipe sites might be good, if there isn't one already.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22889>
_______________________________________

From report at bugs.python.org  Mon Nov 17 20:35:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 19:35:06 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416252906.69.0.144845792492.issue11145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch! Here is a patch which fixes this issue too.

> (1) stop calling the user-defined functions and behave similarly to most other built-in types;

This is done in 3.x.

> (2) stop trying to mutate that poor string in-place and always just create a new one.

The patch can be simplified by removing 6 lines. But this will slow down integer formatting by few (about 2-7) percents in worst case. Not a big deal.

----------
Added file: http://bugs.python.org/file37215/issue11145_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 20:36:30 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 19:36:30 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416252990.88.0.0336911153209.issue11145@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file37216/issue11145_3_simpler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Mon Nov 17 21:55:23 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 17 Nov 2014 20:55:23 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1416257723.54.0.220244496818.issue22536@psf.upfronthosting.co.za>


Akira Li added the comment:

I can confirm that without the patch the filename attribute is None
despite being mentioned in strerror.

Travis, you should use `orig_executable` instead of `args[0]` to cover:

  subprocess.call("exit 0", shell=True, executable='/nonexistent bash')

case. 

And use `cwd` if `child_exec_never_called`, to be consistent with the error message (see if/else statements above the raise statement).

It seems appropriate to set filename even if errno is not ENOENT
but to be conservative, you could provide filename iff `err_msg` is also changed i.e., iff errno is ENOENT.

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:09:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 21:09:05 +0000
Subject: [issue20662] Pydoc doesn't escape parameter defaults in html
In-Reply-To: <1392656897.9.0.470928651824.issue20662@psf.upfronthosting.co.za>
Message-ID: <1416258545.87.0.995407950413.issue20662@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes this issue. Html formatting was broken by issue19674.

----------
keywords: +patch
nosy: +larry
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file37217/pydoc_escape_argspec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20662>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:13:26 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 17 Nov 2014 21:13:26 +0000
Subject: [issue20662] Pydoc doesn't escape parameter defaults in html
In-Reply-To: <1392656897.9.0.470928651824.issue20662@psf.upfronthosting.co.za>
Message-ID: <1416258806.11.0.791031413023.issue20662@psf.upfronthosting.co.za>


Larry Hastings added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20662>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:15:54 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 21:15:54 +0000
Subject: [issue20450] hg touch fails on System Z Linux buildbot
In-Reply-To: <1391113779.26.0.124342883313.issue20450@psf.upfronthosting.co.za>
Message-ID: <1416258954.14.0.798412056361.issue20450@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Seems it was misconfiguration issue and it is fixed now.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20450>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:20:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 21:20:52 +0000
Subject: [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1416259252.96.0.788150109258.issue18688@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:28:04 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 17 Nov 2014 21:28:04 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1416259684.39.0.29212294661.issue22536@psf.upfronthosting.co.za>


Akira Li added the comment:

If the_oserror.filename is not None then str(the_oserror) appends the
filename twice:

  [Errno 2] No such file or directory: 'nonexistent': 'nonexistent'

You could remove `err_msg += ':' ...` statements to avoid the
repeatition. It may break the code that uses strerror attribute. But
exception error messages are explicitly excluded from backward
compatibility considirations therefore it might be ok to break it
here. I can't find the reference so it should probably be resolved as a
new issue (independent from providing the filename attribute value).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:30:44 2014
From: report at bugs.python.org (Craig)
Date: Mon, 17 Nov 2014 21:30:44 +0000
Subject: [issue1038591] Python 2.3+ socket._fileobject handles EAGAIN with
 data loss
Message-ID: <1416259844.41.0.272397428338.issue1038591@psf.upfronthosting.co.za>


Craig added the comment:

Surely if there is data loss this *has* to be fixed in 2.x?
I'm seeing this a *lot* using Twisted which, I believe isn't fully 3.x ported yet, so we have to support 2.x for now.

----------
nosy: +craigemery

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1038591>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:42:15 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Nov 2014 21:42:15 +0000
Subject: [issue1038591] Python 2.3+ socket._fileobject handles EAGAIN with
 data loss
Message-ID: <1416260535.95.0.236409353448.issue1038591@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The simple fact of the matter is that socket.makefile() has never worked for non-blocking sockets on 2.x. I doubt Twisted would be so broken as to use it in that context, but if that's the case, you should report a bug to them. If it's your own code, just use the socket directly (and call recv() and friends).

3.x should work fine, in that read() will return a short read (or None if nothing could be read before EAGAIN). Still, more complex calls such as readline() may still give incorrect results.

----------
resolution:  -> wont fix
status: languishing -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1038591>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:42:37 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Nov 2014 21:42:37 +0000
Subject: [issue1038591] Python 2.3+ socket._fileobject handles EAGAIN with
 data loss
Message-ID: <1416260557.89.0.279678712676.issue1038591@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(closed as won't fix, sorry)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1038591>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:51:00 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Nov 2014 21:51:00 +0000
Subject: [issue20662] Pydoc doesn't escape parameter defaults in html
In-Reply-To: <1392656897.9.0.470928651824.issue20662@psf.upfronthosting.co.za>
Message-ID: <20141117215051.57230.77511@psf.io>


Roundup Robot added the comment:

New changeset cf2e424e0413 by Serhiy Storchaka in branch '3.4':
Issue #20662: Argspec now is escaped in html output of pydoc.
https://hg.python.org/cpython/rev/cf2e424e0413

New changeset 1855b5c3da61 by Serhiy Storchaka in branch 'default':
Issue #20662: Argspec now is escaped in html output of pydoc.
https://hg.python.org/cpython/rev/1855b5c3da61

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20662>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:56:31 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Nov 2014 21:56:31 +0000
Subject: [issue22888] ensurepip and distutils' build_scripts fails on Windows
 when path to Python contains accented characters
In-Reply-To: <1416189805.26.0.501870497437.issue22888@psf.upfronthosting.co.za>
Message-ID: <1416261391.25.0.53738305264.issue22888@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> On Windows, shouldn't copy_scripts use UTF-8 instead of os.fsencode
> (MBCS)? The Python launcher executes the shebang line on Windows, and 
> it defaults to UTF-8 if a script doesn't have a BOM.

Good catch! It seems you're right. Do you want to provide a patch + tests?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22888>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:56:39 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 17 Nov 2014 21:56:39 +0000
Subject: [issue22888] ensurepip and distutils' build_scripts fails on Windows
 when path to Python contains accented characters
In-Reply-To: <1416189805.26.0.501870497437.issue22888@psf.upfronthosting.co.za>
Message-ID: <1416261399.61.0.714980292841.issue22888@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22888>
_______________________________________

From report at bugs.python.org  Mon Nov 17 22:57:56 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 21:57:56 +0000
Subject: [issue20662] Pydoc doesn't escape parameter defaults in html
In-Reply-To: <1392656897.9.0.470928651824.issue20662@psf.upfronthosting.co.za>
Message-ID: <1416261476.64.0.419364668716.issue20662@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks for the review Larry.

There is related minor issue. The formatvalue method is no longer used in HTMLDoc. This can break user code which inherits HTMLDoc and overrides formatvalue.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20662>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:02:57 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 17 Nov 2014 22:02:57 +0000
Subject: [issue22893] Idle: __future__ does not work in startup code.
Message-ID: <1416261777.24.0.465929106454.issue22893@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://stackoverflow.com/questions/26977236/how-can-i-use-future-division-in-the-idle-startup-file report what seems like possibly fixable perhaps buggy behavior with respect to __future__ imports.  More investigation is needed.

Any change here might interact with #5233 IDLE: exec IDLESTARTUP/PYTHONSTARTUP on restart

----------
messages: 231304
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: __future__ does not work in startup code.
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22893>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:18:09 2014
From: report at bugs.python.org (Trey Cucco)
Date: Mon, 17 Nov 2014 22:18:09 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
Message-ID: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>


New submission from Trey Cucco:

When running a test suite with the -f flag (--failfast), unittest seems to stop running tests once it exits a with self.subTest block.

In the attached script, run it without -f and test_b will run and fail. Run it with the -f flag and only the test_a test will run. test_b will not run and no errors will be reported.

I noticed this bug in 3.4.1 on OS X

----------
components: Macintosh, Tests
files: utbug.py
messages: 231305
nosy: Trey.Cucco, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: unittest.TestCase.subTest causes all subsequent tests to be skipped in failfast mode
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37218/utbug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Mon Nov 17 23:35:48 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Nov 2014 22:35:48 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <1416263748.47.0.951413252331.issue22894@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
components:  -Macintosh
nosy: +ezio.melotti, michael.foord, rbcollins -ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Tue Nov 18 04:33:14 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Tue, 18 Nov 2014 03:33:14 +0000
Subject: [issue19895] Cryptic error when subclassing multiprocessing classes
In-Reply-To: <1386239746.14.0.69431016666.issue19895@psf.upfronthosting.co.za>
Message-ID: <1416281594.42.0.31539603526.issue19895@psf.upfronthosting.co.za>


Dan O'Reilly added the comment:

This is basically the same thing that issue21367 is reporting.

----------
nosy: +dan.oreilly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19895>
_______________________________________

From report at bugs.python.org  Tue Nov 18 08:19:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 07:19:37 +0000
Subject: [issue22140] "python-config --includes" returns a wrong path (double
 prefix)
In-Reply-To: <1407245312.64.0.904100539745.issue22140@psf.upfronthosting.co.za>
Message-ID: <1416295177.76.0.224648144356.issue22140@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you want to provide a patch?

----------
components: +Build -Demos and Tools
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22140>
_______________________________________

From report at bugs.python.org  Tue Nov 18 09:49:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 08:49:04 +0000
Subject: [issue22095] Use of set_tunnel with default port results in incorrect
 post value in host header
In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za>
Message-ID: <1416300544.78.0.850619940033.issue22095@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If call _get_hostport() in set_tunnel() then it should be removed in _tunnel().

As for tests, it would be better do not rely on implementation details. Instead you can monkey-patch the send() method of of HTTPConnection instance and check passed argument.

----------
nosy: +nikratio, orsenthil, serhiy.storchaka
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22095>
_______________________________________

From report at bugs.python.org  Tue Nov 18 09:53:29 2014
From: report at bugs.python.org (Alexander Todorov)
Date: Tue, 18 Nov 2014 08:53:29 +0000
Subject: [issue22891] code removal from urllib.parse.urlsplit()
In-Reply-To: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za>
Message-ID: <1416300809.52.0.0286943076239.issue22891@psf.upfronthosting.co.za>


Alexander Todorov added the comment:

> Does test cases pass after removal of those lines? (I will be surprised) 

Yes they do. Also see my detailed explanation above, there's no reason for test cases to fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22891>
_______________________________________

From report at bugs.python.org  Tue Nov 18 10:43:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 09:43:25 +0000
Subject: [issue22314] pydoc.py: TypeError with a $LINES defined to anything
In-Reply-To: <1409491027.45.0.991041704506.issue22314@psf.upfronthosting.co.za>
Message-ID: <1416303805.62.0.309396605825.issue22314@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
type:  -> behavior
versions: +Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37219/pydoc_ttypager_lines.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22314>
_______________________________________

From report at bugs.python.org  Tue Nov 18 10:48:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 09:48:27 +0000
Subject: [issue22367] Please add F_OFD_SETLK, etc support to fcntl.lockf
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1416304107.16.0.0364040323684.issue22367@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Tue Nov 18 10:49:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 09:49:44 +0000
Subject: [issue22370] pathlib OS detection
In-Reply-To: <1410279891.7.0.749304743952.issue22370@psf.upfronthosting.co.za>
Message-ID: <1416304184.86.0.284149441234.issue22370@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> pitrou
nosy: +pitrou, serhiy.storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22370>
_______________________________________

From report at bugs.python.org  Tue Nov 18 11:40:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 10:40:50 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <1416307250.17.0.963940039948.issue22453@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your report Chris.

PyObject_REPR() is used only in Python/compile.c just before calling Py_FatalError(). So refcount leaks doesn't matter in these cases.

PyObject_REPR() is expanded to deprecated _PyUnicode_AsString which is not defined if Py_LIMITED_API is defined. So it is unlikely that third-party code uses it. We can just remove this macro in 3.5.

There are other bugs in formatting fatal error messages where PyObject_REPR() is used. PyBytes_AS_STRING() is called for unicode objects. Definitely this branch of the code is rarely executed.

Here is a patch which expands PyObject_REPR() in Python/compile.c and replaces PyBytes_AS_STRING() with PyUnicode_AsUTF8(). In 3.5 we also should remove the PyObject_REPR macro definition.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
type: behavior -> resource usage
versions:  -Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file37220/PyObject_REPR.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 11:44:46 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 10:44:46 +0000
Subject: [issue22652] Add suggestion about keyword arguments to this error
 message: "builtins.TypeError: my_func() takes 1 positional
 argument but 2 were given"
In-Reply-To: <1413455617.21.0.000325400143663.issue22652@psf.upfronthosting.co.za>
Message-ID: <1416307486.57.0.946906440054.issue22652@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22652>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:03:32 2014
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 18 Nov 2014 12:03:32 +0000
Subject: [issue22895] regression introduced by the fix for issue #22462
Message-ID: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the fix for issue #22462 introduces a regression in the test_pyexpat test cases. I'm not yet sure why. This is only seen when running the testsuite from the installed location, which shouldn't matter.  Tried to run the tests with a stripped executable in the build tree worked too, so I'm lost why this now fails.  Confirmed that reverting the fix resolves running the testcase in the same environment.

----------
components: Library (Lib)
messages: 231312
nosy: doko, pitrou
priority: high
severity: normal
status: open
title: regression introduced by the fix for issue #22462
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:10:46 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2014 12:10:46 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <1416312646.02.0.379686925322.issue22453@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> PyObject_REPR() is expanded to deprecated _PyUnicode_AsString which is not defined if Py_LIMITED_API is defined.

PyObject_REPR() is still defined if Py_LIMITED_API is defined, I just checked.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:16:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 12:16:39 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1416312646.02.0.379686925322.issue22453@psf.upfronthosting.co.za>
Message-ID: <3382578.BN2hVLzzqh@raxxla>


Serhiy Storchaka added the comment:

> PyObject_REPR() is still defined if Py_LIMITED_API is defined, I just
> checked.

But it is expanded to undefined name. So it is not usable in any case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:19:25 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2014 12:19:25 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <1416313165.02.0.138127211085.issue22453@psf.upfronthosting.co.za>


STINNER Victor added the comment:

PyObject_REPR.patch: the first part looks good to me. For the second part, you can use PySys_FormatStderr() which is more complex but more correct: it formats the string as Unicode and then encode it to stderr encoding. PyUnicode_FromFormatV() is probably safer to handle errors.

You may use PySys_FormatStderr() in the two functions to write context, and then call Py_FatalError with a simple message. The exact formatting doesn't matter much, these cases must never occur :-) An assertion may be enough :-p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 13:22:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2014 12:22:44 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <3382578.BN2hVLzzqh@raxxla>
Message-ID: <CAMpsgwayJMjPe5SSnAWQwbiayn_gJOpkH3Lz-WTrmxgqAU7UKQ@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka wrote:
> But it is expanded to undefined name. So it is not usable in any case.

Ah correct, I didn't notice _PyUnicode_AsString in the expanded result
(I checked with gcc -E).

When Py_LIMITED_API is set, PyObject_REPR(o) is expanded to
_PyUnicode_AsString(PyObject_Repr(o)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:14:04 2014
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 18 Nov 2014 13:14:04 +0000
Subject: [issue22895] regression introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416316444.2.0.407681735916.issue22895@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:14:17 2014
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 18 Nov 2014 13:14:17 +0000
Subject: [issue22462] Modules/pyexpat.c violates PEP 384
In-Reply-To: <1411401083.5.0.108064936526.issue22462@psf.upfronthosting.co.za>
Message-ID: <1416316457.91.0.254924347299.issue22462@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22462>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:25:20 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 13:25:20 +0000
Subject: [issue22895] regression introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416317120.4.0.458545501042.issue22895@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Please post the traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:27:10 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 13:27:10 +0000
Subject: [issue22370] pathlib OS detection
In-Reply-To: <1410279891.7.0.749304743952.issue22370@psf.upfronthosting.co.za>
Message-ID: <1416317230.03.0.154980562332.issue22370@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This sounds reasonable, indeed.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22370>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:31:03 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 13:31:03 +0000
Subject: [issue22367] Please add F_OFD_SETLK, etc support to fcntl.lockf
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1416317463.32.0.13965730799.issue22367@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22367>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:35:06 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 13:35:06 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <1416317706.41.0.598071968676.issue22453@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> PyObject_REPR() is expanded to deprecated _PyUnicode_AsString which is 
> not defined if Py_LIMITED_API is defined. So it is unlikely that 
> third-party code uses it

Py_LIMITED_API is the "stable ABI". Most third-party code doesn't use it, so it may still use PyObject_REPR().

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:44:03 2014
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 18 Nov 2014 13:44:03 +0000
Subject: [issue22895] regression introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416318243.27.0.567357445508.issue22895@psf.upfronthosting.co.za>


Matthias Klose added the comment:

[258/383] test_pyexpat
test test_pyexpat failed -- Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 432, in test_exception
    parser.Parse(b"<a><b><c/></b></a>", 1)
  File "../Modules/pyexpat.c", line 405, in StartElement
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 422, in StartElementHandler
    raise RuntimeError(name)
RuntimeError: a

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 447, in test_exception
    self.assertIn('call_with_frame("StartElement"', entries[1][3])
  File "/usr/lib/python3.4/unittest/case.py", line 1053, in assertIn
    if member not in container:
TypeError: argument of type 'NoneType' is not iterable


test_exception (test.test_pyexpat.HandlerExceptionTest) ... ERROR

======================================================================
ERROR: test_exception (test.test_pyexpat.HandlerExceptionTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 432, in test_exception
    parser.Parse(b"<a><b><c/></b></a>", 1)
  File "../Modules/pyexpat.c", line 405, in StartElement
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 422, in StartElementHandler
    raise RuntimeError(name)
RuntimeError: a

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/test/test_pyexpat.py", line 447, in test_exception
    self.assertIn('call_with_frame("StartElement"', entries[1][3])
  File "/usr/lib/python3.4/unittest/case.py", line 1053, in assertIn
    if member not in container:
TypeError: argument of type 'NoneType' is not iterable

----------------------------------------------------------------------
Ran 36 tests in 0.016s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:48:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 13:48:36 +0000
Subject: [issue22113] memoryview and struct.pack_into
In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za>
Message-ID: <1416318516.19.0.292053891252.issue22113@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue is similar to issue10212. Here is a patch which makes struct.pack_into() support new buffer protocol.

Something similar should be applied to 3.x because PyObject_AsWriteBuffer() is deprecated and not safe.

----------
assignee:  -> serhiy.storchaka
nosy: +kristjan.jonsson, pitrou, serhiy.storchaka, terry.reedy
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22113>
_______________________________________

From report at bugs.python.org  Tue Nov 18 14:52:49 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 13:52:49 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416318769.39.0.0157660417593.issue22895@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks. So, this is not a regression: the failing test was introduced in #22462 and probably would have not worked before, either. The problem is that "../Modules/pyexpat.c" makes sense from the checkout directory but not necessarily from the install location. I don't know if we should try to be smarter or not.

At first we could make the test more lenient.

----------
components: +Tests
priority: high -> normal
title: regression introduced by the fix for issue #22462 -> test failure introduced by the fix for issue #22462
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Tue Nov 18 15:02:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 14:02:55 +0000
Subject: [issue22896] Don't use PyObject_As*Buffer() functions
Message-ID: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyObject_AsCharBuffer(), PyObject_AsReadBuffer() and PyObject_AsWriteBuffer() release the buffer right after acquiring and return a pointer to released buffer. This is not safe and could cause issues sooner or later. These functions shouldn't be used in the stdlib at all.

----------
assignee: serhiy.storchaka
components: Extension Modules, Interpreter Core
messages: 231323
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't use PyObject_As*Buffer() functions
type: resource usage
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22896>
_______________________________________

From report at bugs.python.org  Tue Nov 18 15:19:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 14:19:25 +0000
Subject: [issue22608] test_socket fails with sem_init: Too many open files
In-Reply-To: <1413026581.56.0.334221063135.issue22608@psf.upfronthosting.co.za>
Message-ID: <1416320365.43.0.611701468321.issue22608@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suggest to merge issue22608 and issue22610 and also clean up other long living event objects in tests.

----------
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22608>
_______________________________________

From report at bugs.python.org  Tue Nov 18 16:03:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 15:03:14 +0000
Subject: [issue10599] sgmllib.parse_endtag() is not respecting quoted text
In-Reply-To: <1291238509.2.0.989759336682.issue10599@psf.upfronthosting.co.za>
Message-ID: <1416322994.78.0.160916968115.issue10599@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Library (Lib) -None
nosy: +ezio.melotti
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10599>
_______________________________________

From report at bugs.python.org  Tue Nov 18 16:07:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 15:07:49 +0000
Subject: [issue18637] mingw: export _PyNode_SizeOf as PyAPI for parser module
In-Reply-To: <1375472309.41.0.38535995821.issue18637@psf.upfronthosting.co.za>
Message-ID: <1416323269.6.0.682634058123.issue18637@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> commit review
type: enhancement -> behavior
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18637>
_______________________________________

From report at bugs.python.org  Tue Nov 18 16:37:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Nov 2014 15:37:43 +0000
Subject: [issue18637] mingw: export _PyNode_SizeOf as PyAPI for parser module
In-Reply-To: <1375472309.41.0.38535995821.issue18637@psf.upfronthosting.co.za>
Message-ID: <20141118153730.36053.65850@psf.io>


Roundup Robot added the comment:

New changeset eb25629d2a46 by Serhiy Storchaka in branch '2.7':
Issue #18637: Fixed an error in _PyNode_SizeOf declaration.
https://hg.python.org/cpython/rev/eb25629d2a46

New changeset ab3e8aab7119 by Serhiy Storchaka in branch '3.4':
Issue #18637: Fixed an error in _PyNode_SizeOf declaration.
https://hg.python.org/cpython/rev/ab3e8aab7119

New changeset 0f663e0ce1d3 by Serhiy Storchaka in branch 'default':
Issue #18637: Fixed an error in _PyNode_SizeOf declaration.
https://hg.python.org/cpython/rev/0f663e0ce1d3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18637>
_______________________________________

From report at bugs.python.org  Tue Nov 18 17:06:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 16:06:44 +0000
Subject: [issue18637] mingw: export _PyNode_SizeOf as PyAPI for parser module
In-Reply-To: <1375472309.41.0.38535995821.issue18637@psf.upfronthosting.co.za>
Message-ID: <1416326804.8.0.537800266763.issue18637@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Definitely this was a bug. Thank you Roumen for your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18637>
_______________________________________

From report at bugs.python.org  Tue Nov 18 17:07:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 16:07:08 +0000
Subject: [issue18637] mingw: export _PyNode_SizeOf as PyAPI for parser module
In-Reply-To: <1375472309.41.0.38535995821.issue18637@psf.upfronthosting.co.za>
Message-ID: <1416326828.92.0.371287448566.issue18637@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/issue18637>
_______________________________________

From report at bugs.python.org  Tue Nov 18 17:39:07 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 16:39:07 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <1416328747.15.0.0642642874263.issue22453@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> For the second part, you can use PySys_FormatStderr() which is more complex but more correct

PySys_FormatStderr() is more heavy function, it depends on working sys.stderr and codecs. Taking into account the lack of tests we should be careful with such changes. So I prefer to keep fprintf.

> Py_LIMITED_API is the "stable ABI". Most third-party code doesn't use it, so it may still use PyObject_REPR().

So we should just add a warning? This macro is not documented anywhere.

-/* Helper for passing objects to printf and the like */
-#define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj))
+#ifndef Py_LIMITED_API
+/* Helper for passing objects to printf and the like.
+   Leaks refcounts.  Don't use it!
+*/
+#define PyObject_REPR(obj) PyUnicode_AsUTF8(PyObject_Repr(obj))
+#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 17:51:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 16:51:05 +0000
Subject: [issue19670] SimpleCookie Generates Non-RFC6265-Compliant Cookies
In-Reply-To: <1384979004.61.0.0353093814459.issue19670@psf.upfronthosting.co.za>
Message-ID: <1416329465.3.0.806053817168.issue19670@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/issue19670>
_______________________________________

From report at bugs.python.org  Tue Nov 18 17:55:36 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 16:55:36 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1416328747.15.0.0642642874263.issue22453@psf.upfronthosting.co.za>
Message-ID: <546B7A04.3040804@free.fr>


Antoine Pitrou added the comment:

Le 18/11/2014 17:39, Serhiy Storchaka a ?crit :
> 
>> Py_LIMITED_API is the "stable ABI". Most third-party code doesn't use it, so it may still use PyObject_REPR().
> 
> So we should just add a warning? This macro is not documented anywhere.

Well we can still remove it, and add a porting note in whatsnew for 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:11:10 2014
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 18 Nov 2014 17:11:10 +0000
Subject: [issue17750] allow the testsuite to run in the installed location
In-Reply-To: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za>
Message-ID: <1416330670.29.0.302755809748.issue17750@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
dependencies: +test failure introduced by the fix for issue #22462

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17750>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:18:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:18:04 +0000
Subject: [issue21266] test_zipfile fails to run in the installed location
In-Reply-To: <1397675003.86.0.260943331629.issue21266@psf.upfronthosting.co.za>
Message-ID: <1416331084.98.0.0801602130244.issue21266@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21266>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:21:19 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:21:19 +0000
Subject: [issue21032] Socket leak if HTTPConnection.getresponse() fails
In-Reply-To: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za>
Message-ID: <1416331279.1.0.845478562368.issue21032@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please submit a contributor form (https://www.python.org/psf/contrib/) Martin?

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21032>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:23:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:23:24 +0000
Subject: [issue20948] -Wformat=2 -Wformat-security findings
In-Reply-To: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za>
Message-ID: <1416331404.63.0.315145910614.issue20948@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20948>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:27:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:27:26 +0000
Subject: [issue20082] Misbehavior of BufferedRandom.write with raw file in
 append mode
In-Reply-To: <1388187192.84.0.682821163597.issue20082@psf.upfronthosting.co.za>
Message-ID: <1416331646.34.0.614211557791.issue20082@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20082>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:39:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:39:53 +0000
Subject: [issue20066] PyStructSequence_NewType() not setting proper heap
 allocation flag?
In-Reply-To: <1387978399.6.0.58819819413.issue20066@psf.upfronthosting.co.za>
Message-ID: <1416332393.94.0.782338955038.issue20066@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue15729.

----------
components: +Interpreter Core
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.4, Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20066>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:40:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:40:21 +0000
Subject: [issue15729] PyStructSequence_NewType enhancement
In-Reply-To: <1345407378.13.0.964225258094.issue15729@psf.upfronthosting.co.za>
Message-ID: <1416332421.87.0.441428496283.issue15729@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue20066.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15729>
_______________________________________

From report at bugs.python.org  Tue Nov 18 18:55:46 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 17:55:46 +0000
Subject: [issue21266] test_zipfile fails to run in the installed location
In-Reply-To: <1397675003.86.0.260943331629.issue21266@psf.upfronthosting.co.za>
Message-ID: <1416333346.48.0.480939797815.issue21266@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue17753 (test_write_filtered_python_package was added later).

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_zipfile: requires write access to test and email.test

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21266>
_______________________________________

From report at bugs.python.org  Tue Nov 18 19:01:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 18:01:27 +0000
Subject: [issue22825] Modernize TextFile
In-Reply-To: <1416086290.42.0.357881237486.issue22825@psf.upfronthosting.co.za>
Message-ID: <6651890.sYUIQEpv1F@raxxla>


Serhiy Storchaka added the comment:

So you suggest just close this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22825>
_______________________________________

From report at bugs.python.org  Tue Nov 18 19:06:46 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 18:06:46 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <546B7A04.3040804@free.fr>
Message-ID: <2106945.thU3vmnusp@raxxla>


Serhiy Storchaka added the comment:

Here is updated patch.

----------
Added file: http://bugs.python.org/file37221/PyObject_REPR_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________
-------------- next part --------------
diff -r 0f663e0ce1d3 Doc/whatsnew/3.5.rst
--- a/Doc/whatsnew/3.5.rst	Tue Nov 18 17:30:50 2014 +0200
+++ b/Doc/whatsnew/3.5.rst	Tue Nov 18 19:14:09 2014 +0200
@@ -441,3 +441,7 @@ Changes in the C API
 
 * The :c:type:`PyMemAllocator` structure was renamed to
   :c:type:`PyMemAllocatorEx` and a new ``calloc`` field was added.
+
+* Removed non-documented macro :c:macro:`PyObject_REPR` which leaked references.
+  Use format character ``%R`` in :c:func:`PyUnicode_FromFormat`-like functions
+  to format the :func:`repr` of the object.
diff -r 0f663e0ce1d3 Include/object.h
--- a/Include/object.h	Tue Nov 18 17:30:50 2014 +0200
+++ b/Include/object.h	Tue Nov 18 19:14:09 2014 +0200
@@ -575,9 +575,6 @@ PyAPI_FUNC(PyObject *) PyObject_Dir(PyOb
 PyAPI_FUNC(int) Py_ReprEnter(PyObject *);
 PyAPI_FUNC(void) Py_ReprLeave(PyObject *);
 
-/* Helper for passing objects to printf and the like */
-#define PyObject_REPR(obj) _PyUnicode_AsString(PyObject_Repr(obj))
-
 /* Flag bits for printing: */
 #define Py_PRINT_RAW    1       /* No string quotes etc. */
 
diff -r 0f663e0ce1d3 Python/compile.c
--- a/Python/compile.c	Tue Nov 18 17:30:50 2014 +0200
+++ b/Python/compile.c	Tue Nov 18 19:14:09 2014 +0200
@@ -1414,12 +1414,12 @@ get_ref_type(struct compiler *c, PyObjec
         PyOS_snprintf(buf, sizeof(buf),
                       "unknown scope for %.100s in %.100s(%s)\n"
                       "symbols: %s\nlocals: %s\nglobals: %s",
-                      PyBytes_AS_STRING(name),
-                      PyBytes_AS_STRING(c->u->u_name),
-                      PyObject_REPR(c->u->u_ste->ste_id),
-                      PyObject_REPR(c->u->u_ste->ste_symbols),
-                      PyObject_REPR(c->u->u_varnames),
-                      PyObject_REPR(c->u->u_names)
+                      PyUnicode_AsUTF8(name),
+                      PyUnicode_AsUTF8(c->u->u_name),
+                      PyUnicode_AsUTF8(PyObject_Repr(c->u->u_ste->ste_id)),
+                      PyUnicode_AsUTF8(PyObject_Repr(c->u->u_ste->ste_symbols)),
+                      PyUnicode_AsUTF8(PyObject_Repr(c->u->u_varnames)),
+                      PyUnicode_AsUTF8(PyObject_Repr(c->u->u_names))
         );
         Py_FatalError(buf);
     }
@@ -1476,11 +1476,11 @@ compiler_make_closure(struct compiler *c
             fprintf(stderr,
                 "lookup %s in %s %d %d\n"
                 "freevars of %s: %s\n",
-                PyObject_REPR(name),
-                PyBytes_AS_STRING(c->u->u_name),
+                PyUnicode_AsUTF8(PyObject_Repr(name)),
+                PyUnicode_AsUTF8(c->u->u_name),
                 reftype, arg,
-                _PyUnicode_AsString(co->co_name),
-                PyObject_REPR(co->co_freevars));
+                PyUnicode_AsUTF8(co->co_name),
+                PyUnicode_AsUTF8(PyObject_Repr(co->co_freevars)));
             Py_FatalError("compiler_make_closure()");
         }
         ADDOP_I(c, LOAD_CLOSURE, arg);

From report at bugs.python.org  Tue Nov 18 19:08:10 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 18 Nov 2014 18:08:10 +0000
Subject: [issue22113] memoryview and struct.pack_into
In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za>
Message-ID: <1416334090.93.0.845696564225.issue22113@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think you forgot to upload your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22113>
_______________________________________

From report at bugs.python.org  Tue Nov 18 19:15:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 18:15:15 +0000
Subject: [issue22113] memoryview and struct.pack_into
In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za>
Message-ID: <1416334515.17.0.791871572112.issue22113@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry. Here is it.

----------
keywords: +patch
Added file: http://bugs.python.org/file37222/struct_pack_into_memoryview.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22113>
_______________________________________

From report at bugs.python.org  Tue Nov 18 20:09:04 2014
From: report at bugs.python.org (Boris)
Date: Tue, 18 Nov 2014 19:09:04 +0000
Subject: [issue22897] IDLE - MacOS: freeze on non-ASCII save with open debugger
Message-ID: <1416337744.39.0.177828041669.issue22897@psf.upfronthosting.co.za>


New submission from Boris:

When attempting to save a file containing an &Aring; character with the debugger open, IDLE freezes with/or without partially opening the warning window. (Mac OS X 10.9.5, IDLE running python 2.7.5). Reproducible steps:

- Create and save file with one line:
1+1  # A
- Open IDLE
- Open the debugger
- Open the file
- Delete the "A", type <shift><alt>A
- type <command>s to save. This triggers the problem.

Application hangs ("not responding") and needs to force quit. Sometimes the graphics memory of other applications gets corrupted.

----------
components: IDLE
messages: 231338
nosy: steipe
priority: normal
severity: normal
status: open
title: IDLE - MacOS: freeze on non-ASCII save with open debugger
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22897>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:14:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 20:14:45 +0000
Subject: [issue21280] shutil.make_archive() with default "root_dir" parameter
 raises FileNotFoundError: [Errno 2] No such file or directory: ''
In-Reply-To: <1397722199.92.0.999945404475.issue21280@psf.upfronthosting.co.za>
Message-ID: <1416341685.8.0.618483381918.issue21280@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
nosy: +hynek, serhiy.storchaka, tarek
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5
Added file: http://bugs.python.org/file37223/shutil_make_archive_in_curdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21280>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:19:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 20:19:50 +0000
Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux:
 AttributeError: 'PermissionError' object has no attribute 'winerror'
In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za>
Message-ID: <1416341990.58.0.859206330376.issue21775@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Go ahead Greg.

----------
assignee:  -> gward
nosy: +serhiy.storchaka
stage:  -> commit review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21775>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:20:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 20:20:06 +0000
Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux:
 AttributeError: 'PermissionError' object has no attribute 'winerror'
In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za>
Message-ID: <1416342006.44.0.97295012958.issue21775@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21775>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:23:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 20:23:18 +0000
Subject: [issue20156] bz2.BZ2File.read() does not treat growing input file
 properly
In-Reply-To: <1389067483.09.0.426788772717.issue20156@psf.upfronthosting.co.za>
Message-ID: <1416342198.43.0.656841058872.issue20156@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
priority: normal -> low
versions: +Python 3.5 -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20156>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:41:04 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Nov 2014 20:41:04 +0000
Subject: [issue20948] -Wformat=2 -Wformat-security findings
In-Reply-To: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za>
Message-ID: <20141118204100.113306.29521@psf.io>


Roundup Robot added the comment:

New changeset d6d2549340cb by Victor Stinner in branch 'default':
Issue #20948: Inline makefmt() in unicode_fromformat_arg()
https://hg.python.org/cpython/rev/d6d2549340cb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20948>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:42:12 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2014 20:42:12 +0000
Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux:
 AttributeError: 'PermissionError' object has no attribute 'winerror'
In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za>
Message-ID: <1416343332.77.0.85787534622.issue21775@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Would it be possible to write a unit test, maybe using unittest.mock to mock most parts?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21775>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:48:51 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2014 20:48:51 +0000
Subject: [issue20948] -Wformat=2 -Wformat-security findings
In-Reply-To: <1394991695.88.0.958685925479.issue20948@psf.upfronthosting.co.za>
Message-ID: <1416343731.26.0.762631222889.issue20948@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The format parameter passed to sprintf() is created by makefmt() function. In Python 3.5, makefmt() has a few parameters. The code is simple and looks safe.

The makefmt() function was much more complex in Python 3.3, it had more parameters: zeropad, width and precision. I refactored PyUnicode_FromFormatV() to optimize it. During the optimization, makefmt() was simplified, and in fact it is now possible to inline it and remove it. I just removed it in Python 3.5.

Should we change something in Python 2.7 and 3.4? Ignore the warning? Or can I just close the issue?

Thanks for the report Jeffrey.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20948>
_______________________________________

From report at bugs.python.org  Tue Nov 18 21:51:01 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Nov 2014 20:51:01 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <2106945.thU3vmnusp@raxxla>
Message-ID: <CAMpsgwYPK3vkP=3SgY+2mbS-gbFsPuhpM3yzq-EoQt-HsHkzqg@mail.gmail.com>


STINNER Victor added the comment:

PyObject_REPR_2.patch looks good to me, but it should only be applied
to Python 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:26:16 2014
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 18 Nov 2014 21:26:16 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
Message-ID: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>


New submission from A. Jesse Jiryu Davis:

Running a unittest suite for Motor, my MongoDB driver which uses PyMongo, greenlet, and Tornado. The suite commonly segfaults during interpreter shutdown. I've reproduced this crash with Python 3.3.5, 3.4.1, and 3.4.2. Python 2.6 and 2.7 do *not* crash. The Python interpreters are all built like:

./configure --prefix=/mnt/jenkins/languages/python/rX.Y.Z --enable-shared && make && make install

This is Amazon Linux AMI release 2014.09.

The unittest suite's final output is:

----------------------------------------------------------------------
Ran 15 tests in 265.947s

OK
Segmentation fault (core dumped)

Backtrace from a Python 3.4.2 coredump attached.

----------
components: Interpreter Core
files: dump.txt
messages: 231345
nosy: emptysquare
priority: normal
severity: normal
status: open
title: segfault during shutdown attempting to log ResourceWarning
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file37224/dump.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:36:48 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Nov 2014 21:36:48 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <20141118213642.62758.33528@psf.io>


Roundup Robot added the comment:

New changeset e339d75a21d5 by Serhiy Storchaka in branch 'default':
Issue #22453: Removed non-documented macro PyObject_REPR().
https://hg.python.org/cpython/rev/e339d75a21d5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 22:37:30 2014
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 18 Nov 2014 21:37:30 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416346650.03.0.665035920858.issue22898@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

The crash can ignore whether or not I specify "-Wignore" on the python command line. I was hoping to avoid the crash by short-circuiting the ResourceWarning code path, since the following line appears in the backtrace:

#5  PyErr_WarnFormat (category=<optimized out>, stack_level=stack_level at entry=1, format=format at entry=0x7f5f1ca8b377 "unclosed file %R") at Python/_warnings.c:813

But "-Wignore" has no effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:17:27 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Nov 2014 22:17:27 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <20141118221719.36065.69755@psf.io>


Roundup Robot added the comment:

New changeset 342a619cdafb by Serhiy Storchaka in branch '3.4':
Issue #22453: Warn against the use of leaking macro PyObject_REPR().
https://hg.python.org/cpython/rev/342a619cdafb

New changeset 6e26b5291c41 by Serhiy Storchaka in branch '2.7':
Issue #22453: Fexed reference leaks when format error messages in ceval.c.
https://hg.python.org/cpython/rev/6e26b5291c41

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:18:44 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 18 Nov 2014 22:18:44 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <1416349124.05.0.0885627606258.issue22894@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/issue22894>
_______________________________________

From report at bugs.python.org  Tue Nov 18 23:19:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Nov 2014 22:19:38 +0000
Subject: [issue22453] PyObject_REPR macro causes refcount leak
In-Reply-To: <1411316768.43.0.141557856004.issue22453@psf.upfronthosting.co.za>
Message-ID: <1416349178.84.0.878575798969.issue22453@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your reviews Victor and Antoine.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22453>
_______________________________________

From report at bugs.python.org  Wed Nov 19 00:16:37 2014
From: report at bugs.python.org (Ryan Chartier)
Date: Tue, 18 Nov 2014 23:16:37 +0000
Subject: [issue22899] http.server.BaseHTTPRequestHandler.parse_request
 (TypeError: decoding str is not supported)
Message-ID: <1416352597.9.0.2072492328.issue22899@psf.upfronthosting.co.za>


New submission from Ryan Chartier:

While the parse_request is handling the requestline, it tries to force the string into iso-8859-1 using an unsupported syntax.

Line #274 in server.py

requestline = str(self.raw_requestline, 'iso-8859-1')

Obviously, python complains.

TypeError: decoding str is not supported

I'm running python 3.4.2 and the line is present in the 3.4.2 source I downloaded from the python.org today.

That is all.

----------
messages: 231350
nosy: recharti
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler.parse_request (TypeError: decoding str is not supported)
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22899>
_______________________________________

From report at bugs.python.org  Wed Nov 19 00:23:19 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 18 Nov 2014 23:23:19 +0000
Subject: [issue22899] http.server.BaseHTTPRequestHandler.parse_request
 (TypeError: decoding str is not supported)
In-Reply-To: <1416352597.9.0.2072492328.issue22899@psf.upfronthosting.co.za>
Message-ID: <1416352999.54.0.700873757365.issue22899@psf.upfronthosting.co.za>


Georg Brandl added the comment:

With the vanilla BaseHTTPRequestHandler, this shouldn't happen. self.raw_requestline is read from a socket file, which returns bytes, so they can be decoded using str(bytes, encoding).

Can you please check if there are any third-party packages involved that call/subclass the classes from http.server and introduce a bytes/str confusion?  They might not be correctly/completely ported to Python 3 in that case.

In any case, a full traceback will be helpful to help debug this.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22899>
_______________________________________

From report at bugs.python.org  Wed Nov 19 00:33:26 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 18 Nov 2014 23:33:26 +0000
Subject: [issue22370] pathlib OS detection
In-Reply-To: <1410279891.7.0.749304743952.issue22370@psf.upfronthosting.co.za>
Message-ID: <20141118233314.13373.37460@psf.io>


Roundup Robot added the comment:

New changeset cb1d7eac601d by Antoine Pitrou in branch '3.4':
Close #22370: Windows detection in pathlib is now more robust.
https://hg.python.org/cpython/rev/cb1d7eac601d

New changeset 712f246da49b by Antoine Pitrou in branch 'default':
Close #22370: Windows detection in pathlib is now more robust.
https://hg.python.org/cpython/rev/712f246da49b

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22370>
_______________________________________

From report at bugs.python.org  Wed Nov 19 01:31:57 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Nov 2014 00:31:57 +0000
Subject: [issue22897] IDLE hangs on OS X with Cocoa Tk if encoding dialog is
 required during save
In-Reply-To: <1416337744.39.0.177828041669.issue22897@psf.upfronthosting.co.za>
Message-ID: <1416357117.65.0.119724719715.issue22897@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  It appears that all that is needed to trigger the hang is any operation that invokes the IDLE EncodingMessage dialog ("Non-ASCII found, yet no encoding declared. Add a line like [...]") in IOBinding.py during a Save when IDLE is linked with the OS X Cocoa Tk 8.5 (or likely 8.6) as used with the python.org 64-bin/32-bit 10.6+ installers, for example, just opening a new edit window, inserting a non-ASCII character, and then trying to Save.  EncodingMessage subclasses the Tkinter SimpleDialog module and creates a new Toplevel root; I seem to recall other problems like this in the past.  The problem is not seen with the older Carbon Tk 8.4 or with an X11 Tk on OS X.

----------
nosy: +ned.deily
stage:  -> needs patch
title: IDLE - MacOS: freeze on non-ASCII save with open debugger -> IDLE hangs on OS X with Cocoa Tk if encoding dialog is required during save

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22897>
_______________________________________

From report at bugs.python.org  Wed Nov 19 06:08:20 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 19 Nov 2014 05:08:20 +0000
Subject: [issue22867] document behavior of calling atexit.register() while
 atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1416373700.52.0.791964052479.issue22867@psf.upfronthosting.co.za>


Ethan Furman added the comment:

>From a post by Ian Kelly (https://mail.python.org/pipermail/python-list/2014-November/681073.html)
--------------------------------------------------------------
In fact it seems the behavior does differ between Python 2.7 and Python 3.4:

$ cat testatexit.py
import atexit

@atexit.register
def main():
  atexit.register(goodbye)

@atexit.register
def goodbye():
  print("Goodbye")
$ python2 testatexit.py
Goodbye
Goodbye
$ python3 testatexit.py
Goodbye

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22867>
_______________________________________

From report at bugs.python.org  Wed Nov 19 07:23:51 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Nov 2014 06:23:51 +0000
Subject: [issue22825] Modernize TextFile
In-Reply-To: <1415544341.49.0.85924418958.issue22825@psf.upfronthosting.co.za>
Message-ID: <1416378231.13.0.647396024493.issue22825@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22825>
_______________________________________

From report at bugs.python.org  Wed Nov 19 08:29:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 07:29:01 +0000
Subject: [issue18905] pydoc -p 0 says the server is available at localhost:0
In-Reply-To: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>
Message-ID: <1416382141.25.0.114655895691.issue18905@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With the patch resolved address 127.0.0.1 is printed instead of localhost. self.address[0] can be used to match current behavior of 2.7 and 3.x.

And why not just initialize the url attribute in server_activate()?

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file37225/pydoc_port_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18905>
_______________________________________

From report at bugs.python.org  Wed Nov 19 08:42:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 07:42:26 +0000
Subject: [issue18731] Increased test coverage for uu and telnet
In-Reply-To: <1377643461.79.0.131386576227.issue18731@psf.upfronthosting.co.za>
Message-ID: <1416382946.74.0.238779639676.issue18731@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

test_encode_defaults is failed now. Don't use hardcoded filename length.

And I don't understand the purpose of changes in uu.py.

----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18731>
_______________________________________

From report at bugs.python.org  Wed Nov 19 08:49:30 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 07:49:30 +0000
Subject: [issue22825] Modernize TextFile
In-Reply-To: <1415544341.49.0.85924418958.issue22825@psf.upfronthosting.co.za>
Message-ID: <1416383370.9.0.780101620025.issue22825@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your response. This was a part of large patch about migration to use of "with" (issue22826 and issue22831 are other parts).

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22825>
_______________________________________

From report at bugs.python.org  Wed Nov 19 09:04:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 08:04:43 +0000
Subject: [issue22899] http.server.BaseHTTPRequestHandler.parse_request
 (TypeError: decoding str is not supported)
In-Reply-To: <1416352597.9.0.2072492328.issue22899@psf.upfronthosting.co.za>
Message-ID: <1416384283.6.0.248162685657.issue22899@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

self.raw_requestline is read from self.rfile:

    self.raw_requestline = self.rfile.readline(65537)

self.rfile is either socket stream

    self.rfile = self.connection.makefile('rb', self.rbufsize)

or in-memory bytes stream

    self.rfile = BytesIO(self.packet)

In both cases it is binary stream and produces bytes. I don't see a bug in the stdlib, it can be a bug in user code which sets self.rfile or self.raw_requestline to invalid value.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22899>
_______________________________________

From report at bugs.python.org  Wed Nov 19 09:11:22 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 19 Nov 2014 08:11:22 +0000
Subject: [issue22899] http.server.BaseHTTPRequestHandler.parse_request
 (TypeError: decoding str is not supported)
In-Reply-To: <1416352597.9.0.2072492328.issue22899@psf.upfronthosting.co.za>
Message-ID: <1416384682.31.0.455449010715.issue22899@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22899>
_______________________________________

From report at bugs.python.org  Wed Nov 19 09:20:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 08:20:17 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416385217.28.0.473152936491.issue22898@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as globals in setup_context() is NULL. I suppose it is PyThreadState_Get()->interp->sysdict. interp->sysdict is cleared in PyInterpreterState_Clear(). Other code is executed after setting interp->sysdict to NULL (clearing interp->sysdict content, interp->builtins, interp->builtins_copy and interp->importlib) and this potentially can emit warnings.

----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 19 09:54:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 08:54:40 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <1416387280.06.0.000253537389104.issue19720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, suppressing context was introduced for such cases.

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37226/importlib_suppress_context.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19720>
_______________________________________

From report at bugs.python.org  Wed Nov 19 09:59:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 08:59:40 +0000
Subject: [issue19867] pickletools.OpcodeInfo.code is a string
In-Reply-To: <1386024237.29.0.240373861832.issue19867@psf.upfronthosting.co.za>
Message-ID: <1416387580.38.0.0511242793743.issue19867@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But isn't it is backward incompatible change?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19867>
_______________________________________

From report at bugs.python.org  Wed Nov 19 10:04:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 09:04:28 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1416387868.13.0.898492177465.issue20059@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20059>
_______________________________________

From report at bugs.python.org  Wed Nov 19 10:05:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 09:05:40 +0000
Subject: [issue20106] warn_dir is always true for install_data,
 even if an install_dir is specified
In-Reply-To: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za>
Message-ID: <1416387940.67.0.867252357395.issue20106@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +dstufft, eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20106>
_______________________________________

From report at bugs.python.org  Wed Nov 19 10:15:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 09:15:37 +0000
Subject: [issue20296] PyArg_ParseTuple 2.X docs mention int for "t#",
 but "Py_ssize_t" for "w#", etc.
In-Reply-To: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za>
Message-ID: <1416388537.61.0.766431239049.issue20296@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20296>
_______________________________________

From report at bugs.python.org  Wed Nov 19 10:47:54 2014
From: report at bugs.python.org (Carlos Ralli)
Date: Wed, 19 Nov 2014 09:47:54 +0000
Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address
In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>
Message-ID: <1416390474.17.0.570879923118.issue20215@psf.upfronthosting.co.za>


Carlos Ralli added the comment:

Is it possible to use this patch for python2.7 ?

----------
nosy: +Carlos.Ralli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20215>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:08:10 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Nov 2014 10:08:10 +0000
Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address
In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>
Message-ID: <1416391690.14.0.874048971511.issue20215@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20215>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:12:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 10:12:17 +0000
Subject: [issue22696] Add a function to know about interpreter shutdown
In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za>
Message-ID: <1416391937.68.0.133463870011.issue22696@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

An indirect way how to know about interpreter shutdown -- test existing of the path attribute in sys (issue20603).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22696>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:27:17 2014
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 19 Nov 2014 10:27:17 +0000
Subject: [issue22515] Implement partial order on Counter
In-Reply-To: <1412019201.2.0.639073460867.issue22515@psf.upfronthosting.co.za>
Message-ID: <1416392837.41.0.0646463260968.issue22515@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Hi everyone,

Just wanted to follow up here that I've created my own dedicated bag class.

Documentation: https://combi.readthedocs.org/en/stable/bags.html

Install using `pip install combi`

It's packed with features. There are a ton of arithmetic operations defined and the comparisons methods we talked about in this issue. There are also frozen and ordered variants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22515>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:29:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 10:29:02 +0000
Subject: [issue20604] Missing invalid mode in error message of socket.makefile.
In-Reply-To: <1392154835.15.0.731068129173.issue20604@psf.upfronthosting.co.za>
Message-ID: <1416392942.73.0.247783120346.issue20604@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your patch Franck. But it would be more useful to output all mode argument, not only wrong character. And it should be wrapped in a tuple to prevent subtle formatting error.

----------
nosy: +serhiy.storchaka
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20604>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:29:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 10:29:24 +0000
Subject: [issue20604] Missing invalid mode in error message of socket.makefile.
In-Reply-To: <1392154835.15.0.731068129173.issue20604@psf.upfronthosting.co.za>
Message-ID: <1416392964.92.0.51255720293.issue20604@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20604>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:36:33 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Nov 2014 10:36:33 +0000
Subject: [issue20604] Missing invalid mode in error message of socket.makefile.
In-Reply-To: <1392154835.15.0.731068129173.issue20604@psf.upfronthosting.co.za>
Message-ID: <20141119103628.62750.13370@psf.io>


Roundup Robot added the comment:

New changeset 34c7be03259b by Serhiy Storchaka in branch '3.4':
Issue #20604: Added missed invalid mode in error message of socket.makefile().
https://hg.python.org/cpython/rev/34c7be03259b

New changeset d5b36edeecdb by Serhiy Storchaka in branch 'default':
Issue #20604: Added missed invalid mode in error message of socket.makefile().
https://hg.python.org/cpython/rev/d5b36edeecdb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20604>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:37:14 2014
From: report at bugs.python.org (Peter)
Date: Wed, 19 Nov 2014 10:37:14 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1416393434.08.0.722629408659.issue21872@psf.upfronthosting.co.za>


Changes by Peter <p.j.a.cock at googlemail.com>:


----------
nosy: +maubp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21872>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:47:25 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 10:47:25 +0000
Subject: [issue20604] Missing invalid mode in error message of socket.makefile.
In-Reply-To: <1392154835.15.0.731068129173.issue20604@psf.upfronthosting.co.za>
Message-ID: <1416394045.12.0.693404637622.issue20604@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20604>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:50:04 2014
From: report at bugs.python.org (Piotr Dobrogost)
Date: Wed, 19 Nov 2014 10:50:04 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1416394204.86.0.0238020094309.issue1294959@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/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Nov 19 11:52:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 10:52:27 +0000
Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in
 test_xpickle
In-Reply-To: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za>
Message-ID: <1416394347.85.0.30410212285.issue19949@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping. I had added comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19949>
_______________________________________

From report at bugs.python.org  Wed Nov 19 12:21:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 11:21:14 +0000
Subject: [issue20736] test_socket: testSendmsgDontWait needlessly skipped on
 Linux
In-Reply-To: <1393107368.02.0.430895744792.issue20736@psf.upfronthosting.co.za>
Message-ID: <1416396074.57.0.86914104427.issue20736@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> commit review
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20736>
_______________________________________

From report at bugs.python.org  Wed Nov 19 12:24:21 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 19 Nov 2014 11:24:21 +0000
Subject: [issue20736] test_socket: testSendmsgDontWait needlessly skipped on
 Linux
In-Reply-To: <1393107368.02.0.430895744792.issue20736@psf.upfronthosting.co.za>
Message-ID: <20141119112400.62750.85912@psf.io>


Roundup Robot added the comment:

New changeset fb06c8ccfd41 by Serhiy Storchaka in branch '3.4':
Issue #20736: testSendmsgDontWait in test_socket no longer skipped on Linux.
https://hg.python.org/cpython/rev/fb06c8ccfd41

New changeset 23ab1197df0b by Serhiy Storchaka in branch 'default':
Issue #20736: testSendmsgDontWait in test_socket no longer skipped on Linux.
https://hg.python.org/cpython/rev/23ab1197df0b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20736>
_______________________________________

From report at bugs.python.org  Wed Nov 19 12:27:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 11:27:22 +0000
Subject: [issue20736] test_socket: testSendmsgDontWait needlessly skipped on
 Linux
In-Reply-To: <1393107368.02.0.430895744792.issue20736@psf.upfronthosting.co.za>
Message-ID: <1416396442.66.0.627458782205.issue20736@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your report and patch David.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20736>
_______________________________________

From report at bugs.python.org  Wed Nov 19 12:42:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 11:42:29 +0000
Subject: [issue20885] Little Endian PowerPC64 Linux
In-Reply-To: <1394476555.87.0.433973059487.issue20885@psf.upfronthosting.co.za>
Message-ID: <1416397349.45.0.786899089511.issue20885@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

libffi was updated to v3.1 in issue22176. This release adds support for the Linux AArch64 and POWERPC ELF ABIv2 little endian architectures.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20885>
_______________________________________

From report at bugs.python.org  Wed Nov 19 12:47:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 11:47:28 +0000
Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers
 correctly
In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za>
Message-ID: <1416397648.02.0.408130391406.issue21114@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide tests?

----------
assignee:  -> serhiy.storchaka
nosy: +pje, serhiy.storchaka
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21114>
_______________________________________

From report at bugs.python.org  Wed Nov 19 12:51:40 2014
From: report at bugs.python.org (=?utf-8?q?Jure_Erzno=C5=BEnik?=)
Date: Wed, 19 Nov 2014 11:51:40 +0000
Subject: [issue22900] decimal.Context Emin,
 Emax limits restrict functionality without adding benefits
Message-ID: <1416397899.98.0.98334629396.issue22900@psf.upfronthosting.co.za>


New submission from Jure Erzno?nik:

At some point since Python 2.7, the EMin, Emax members got more restrictive bounds. Emin cannot go above 0 and Emax cannot go below 0.

I would argue against this logic:
.prec specifies total precision
.Emin and .Emax effectively limit possible locations of decimal point within the given precision. Since they don't specify / enforce EXACT position of the decimal point, what's the point of limiting them?

Without restrictions, setting Emin = Emax = some positive number effectively restricts number of decimal places to exactly that positive number without a need for separate (and expensive) .quantize() calls.

Removing this restriction provides an option to use decimal as true fixed-point arithmetic.

----------
components: Extension Modules
messages: 231374
nosy: Jure.Erzno?nik
priority: normal
severity: normal
status: open
title: decimal.Context Emin, Emax limits restrict functionality without adding benefits
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22900>
_______________________________________

From report at bugs.python.org  Wed Nov 19 13:09:58 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 19 Nov 2014 12:09:58 +0000
Subject: [issue22900] decimal.Context Emin,
 Emax limits restrict functionality without adding benefits
In-Reply-To: <1416397899.98.0.98334629396.issue22900@psf.upfronthosting.co.za>
Message-ID: <1416398998.19.0.758389637318.issue22900@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I would expect this to be a difference between the original pure Python implementation and the current C accelerated implementation.

The constraint is in alignment with the General Decimal Arithmetic Specification that the decimal module aims to implement, which requires that Emin and Emax define a balanced range about zero. (That is, Emin = -Emax +/- 1)

The fact the pure Python implementation didn't enforce that constraint was an implementation detail - other implementations (including the cdecimal module, which was incorporated into the standard library to provide CPython's C accelerated version in Python 3.3) are free to enforce it.

----------
nosy: +ncoghlan, skrah
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22900>
_______________________________________

From report at bugs.python.org  Wed Nov 19 13:10:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 12:10:27 +0000
Subject: [issue17852] Built-in module _io can loose data from buffered files
 at exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1416399027.03.0.377244758121.issue17852@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In 3.4+ the example script always writes string "bar" to file "foo". Tested by running it in a loop hundreds times. Cleaning up at shutdown was enhanced in 3.4.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Wed Nov 19 13:45:38 2014
From: report at bugs.python.org (Carlos Ralli)
Date: Wed, 19 Nov 2014 12:45:38 +0000
Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address
In-Reply-To: <1416391690.2.0.844660923791.issue20215@psf.upfronthosting.co.za>
Message-ID: <CAK0Ds+tHhz3-8Mvww4Uwow=1OjvFVeicbEBBbfE_Z8XgeGOZ9w@mail.gmail.com>


Carlos Ralli added the comment:

Sorry, I've got nothing. Did you forget the attachment or mail body ?

2014-11-19 11:08 GMT+01:00 Berker Peksag <report at bugs.python.org>:

>
> Changes by Berker Peksag <berker.peksag at gmail.com>:
>
>
> ----------
> nosy: +berker.peksag
> stage:  -> patch review
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20215>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20215>
_______________________________________

From report at bugs.python.org  Wed Nov 19 14:10:40 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Nov 2014 13:10:40 +0000
Subject: [issue20885] Little Endian PowerPC64 Linux
In-Reply-To: <1394476555.87.0.433973059487.issue20885@psf.upfronthosting.co.za>
Message-ID: <1416402640.23.0.806145756737.issue20885@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Can we close this and issue22176 then?

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20885>
_______________________________________

From report at bugs.python.org  Wed Nov 19 15:29:19 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Nov 2014 14:29:19 +0000
Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address
In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>
Message-ID: <1416407359.94.0.879659369198.issue20215@psf.upfronthosting.co.za>


R. David Murray added the comment:

Andreas: I would prefer to avoid a dependency on the ipaddress module.  I would suggest adding an address_family constructor argument that defaults to None, where a value of None would mean "just pass the server_address to bind (or getaddrinfo?) and find out what the resulting family is".  I'm not exactly a socket programming expert, though, so there may be a reason I'm not aware of that that won't work well.

Carlos: no, this is a new feature, so it can go into 3.5 only at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20215>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:00:25 2014
From: report at bugs.python.org (bru)
Date: Wed, 19 Nov 2014 15:00:25 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
Message-ID: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>


New submission from bru:

`test.test_uuid.test_find_mac` relies on `ifconfig` binary presence, which is on its way out. This makes the test fail on more and more Linux installations.
Using `env` (for example) is more reliable. `ip` could also be used since it's the replacement to `ifconfig`, but an always-present binary such as `env` makes it work in all cases.
This is what the (trivial) patch does.

The same reasoning applies to `uuid.getnode`: if 'Unix dll' source is not available it will try to get a MAC address 'ifconfig' which will fail, and the fallback will be `_random_getnode` (but that's another issue).

----------
components: Tests
files: fix_uuid_find_mac_test.patch
keywords: patch
messages: 231380
nosy: bru
priority: normal
severity: normal
status: open
title: test.test_uuid.test_find_mac fails because of `ifconfig` deprecation
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/file37227/fix_uuid_find_mac_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:08:09 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:08:09 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1416409689.95.0.515580798211.issue22901@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:09:06 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:09:06 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1416409746.24.0.520160546285.issue22901@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It would be nice to switch to "ip link". The ip command became the new standard on Linux. I don't know if the ip command is available on other operating systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:16:34 2014
From: report at bugs.python.org (bru)
Date: Wed, 19 Nov 2014 15:16:34 +0000
Subject: [issue22902] Use 'ip' for uuid.getnode()
Message-ID: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>


New submission from bru:

Only linux, `uuid.getnode()` will use the Unix ddl, then ifconfig, then random. `ifconfig` is disappearing in favour of `ip` (from iproute2), which should be used.
This patch ads `_ip_getnode` getter to `uuid.getnode()`

----------
components: Library (Lib)
files: uuid_find_mac_with_ip.patch
keywords: patch
messages: 231382
nosy: bru
priority: normal
severity: normal
status: open
title: Use 'ip' for uuid.getnode()
versions: Python 3.4
Added file: http://bugs.python.org/file37228/uuid_find_mac_with_ip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22902>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:18:29 2014
From: report at bugs.python.org (bru)
Date: Wed, 19 Nov 2014 15:18:29 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1416410309.4.0.396284747842.issue22901@psf.upfronthosting.co.za>


bru added the comment:

According to http://en.wikipedia.org/wiki/Iproute2 "ip" is Linux-only.
I opened an issue with a patch that brings "ip link list" to "uuid.getnode()": http://bugs.python.org/issue22902

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:22:31 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:22:31 +0000
Subject: [issue22902] Use 'ip' for uuid.getnode()
In-Reply-To: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>
Message-ID: <1416410551.26.0.973429696762.issue22902@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMO such change can wait for Python 3.5.

----------
nosy: +haypo, serhiy.storchaka
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22902>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:23:11 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:23:11 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1416410591.42.0.18983284265.issue22901@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Only Python 2.7, 3.4 and 3.5 accepted bug fixes; other versions only accept security fixes.)

----------
versions:  -Python 3.2, Python 3.3, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:28:36 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:28:36 +0000
Subject: [issue20885] Little Endian PowerPC64 Linux
In-Reply-To: <1394476555.87.0.433973059487.issue20885@psf.upfronthosting.co.za>
Message-ID: <1416410916.57.0.951475943092.issue20885@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/issue20885>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:29:33 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 19 Nov 2014 15:29:33 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <1416410973.58.0.0994915334982.issue19720@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/issue19720>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:36:19 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:36:19 +0000
Subject: [issue17852] Built-in module _io can loose data from buffered files
 at exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1416411379.96.0.493313177459.issue17852@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Is anyone interested to work on the "maintain a list of open file objects" idea?

I consider that Python 3 does its best to flush data at exit, but it's not a good practice to rely on the destructors to flush data. I mean, there is no warranty that files will be written in the correct order and that files will stay consistent. It's much safer to explicitly call the clode() method.

By the way, Python 3 now emits ResourceWarning warnings when files are destroyed without being explicitly closed. I enhanced the code handling warnings during Python shutdown to show these warnings in more use cases, but it is still not perfect. I opened the issue #21788 as a reminder that the code can still be enhanced.

For the "maintain a list of objects" idea, I expect race conditions with threads, signals and processes (fork). We already have known issues with locks + fork. I expect even more issues if we maintain a list of open files.

I propose to close the issue as "wontfix". Python 3 does its best, but please call explicitly the close() method!

Maybe the undefined behaviour should be documented (with a warning?) in the buffered writer of the io module, and maybe also in the open() function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:38:16 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:38:16 +0000
Subject: [issue20296] PyArg_ParseTuple 2.X docs mention int for "t#",
 but "Py_ssize_t" for "w#", etc.
In-Reply-To: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za>
Message-ID: <1416411496.35.0.68505733091.issue20296@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20296>
_______________________________________

From report at bugs.python.org  Wed Nov 19 16:38:37 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:38:37 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416411517.92.0.666575087737.issue22898@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/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:11:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 16:11:16 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1416413476.7.0.966102058766.issue22901@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How the test fail? Could you provide test output?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:26:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 16:26:40 +0000
Subject: [issue22902] Use 'ip' for uuid.getnode()
In-Reply-To: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>
Message-ID: <1416414400.47.0.268208756154.issue22902@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22902>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:32:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 16:32:13 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416414733.3.0.158266152874.issue22898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like the problem is that raising the PyExc_RecursionErrorInst singleton creates a traceback object which contains frames. The singleton keeps the frames alive longer than expected.

I tried to write a script to raise this singleton, but it looks like the local variables of the frames are not deleted, even if frames are deleted (by _PyExc_Fini).

You may try to finish my attached runtimerror_singleton.py script.

----------
Added file: http://bugs.python.org/file37229/runtimerror_singleton.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:32:51 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 16:32:51 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416414771.51.0.980906498534.issue22898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I also wrote a draft of patch fixing the issue, but I was unable to reproduce the issue. See attached warn.patch (not tested).

----------
keywords: +patch
Added file: http://bugs.python.org/file37230/warn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:38:00 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 16:38:00 +0000
Subject: [issue17852] Built-in module _io can loose data from buffered files
 at exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1416415080.01.0.358594409602.issue17852@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm +1 on closing this. Agree with Charles-Fran?ois that it's never been guaranteed by the Python specification. Pythonic way to work with files is to use the "with" statement, or, if you need long living file stream, careful close files in the "finally" block or in __exit__ method of some class which is used as context manager. Non-observance of this rule can be considered as a bug (see issue22831).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:39:25 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 16:39:25 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1416415165.56.0.542448036284.issue22536@psf.upfronthosting.co.za>


STINNER Victor added the comment:

You should only add the filename if the error if a FileNotFound exception, not for any OSError, and only if exec() was called. It looks like the variable child_exec_never_called indicates if exec() was called.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Wed Nov 19 17:41:08 2014
From: report at bugs.python.org (bru)
Date: Wed, 19 Nov 2014 16:41:08 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1416415268.29.0.416713498498.issue22901@psf.upfronthosting.co.za>


bru added the comment:

I realize that I was not working against the tip... The patch I offered does not apply since revision 88068, which fixes the test by skipping it when "ifconfig" isn't available. Therefore this issue is invalid.

However I think that "test_find_mac" should always should not be skipped but use any other binary instead.


(Context: I'm trying to start contributing by fixing tests/'easy' bugs; I should have updated by cpython repo beforehand...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:24:59 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Nov 2014 17:24:59 +0000
Subject: [issue22825] Modernize TextFile
In-Reply-To: <1415544341.49.0.85924418958.issue22825@psf.upfronthosting.co.za>
Message-ID: <1416417899.9.0.868577808479.issue22825@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thank you for your effort!  Note that distutils uses try:... finally: fp.close(), so it tries to avoid the FD leak issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22825>
_______________________________________

From report at bugs.python.org  Wed Nov 19 18:28:04 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Nov 2014 17:28:04 +0000
Subject: [issue20106] warn_dir is always true for install_data,
 even if an install_dir is specified
In-Reply-To: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za>
Message-ID: <1416418084.12.0.156980916489.issue20106@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Does this cause a warning to be printed out when it should not?  Or did you find this by reading the code?

[I think I remember this code being changed in the (now defunct) distutils2 project.]

----------
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20106>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:09:42 2014
From: report at bugs.python.org (Tabrez Mohammed)
Date: Wed, 19 Nov 2014 18:09:42 +0000
Subject: [issue20106] warn_dir is always true for install_data,
 even if an install_dir is specified
In-Reply-To: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za>
Message-ID: <1416420582.17.0.531545663279.issue20106@psf.upfronthosting.co.za>


Tabrez Mohammed added the comment:

The former. I copy/pasted the code block to show from where the warning message was being printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20106>
_______________________________________

From report at bugs.python.org  Wed Nov 19 19:41:52 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 19 Nov 2014 18:41:52 +0000
Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in
 test_xpickle
In-Reply-To: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za>
Message-ID: <1416422512.81.0.685535438004.issue19949@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Sorry, I haven't had a chance to get back to this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19949>
_______________________________________

From report at bugs.python.org  Wed Nov 19 20:49:12 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Nov 2014 19:49:12 +0000
Subject: [issue22903] unittest creates non-picklable errors
Message-ID: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Just got this:

_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleImportFailure'>: attribute lookup ModuleImportFailure on unittest.loader failed

unittest should use regular exception classes instead.

----------
messages: 231398
nosy: ezio.melotti, michael.foord, pitrou, rbcollins
priority: normal
severity: normal
status: open
title: unittest creates non-picklable errors
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Wed Nov 19 20:51:26 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 19 Nov 2014 19:51:26 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1416426686.31.0.60742886581.issue22903@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/issue22903>
_______________________________________

From report at bugs.python.org  Wed Nov 19 21:27:24 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Nov 2014 20:27:24 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1416428844.82.0.734384583674.issue22903@psf.upfronthosting.co.za>


R. David Murray added the comment:

They aren't "real" exceptions, though, if I understand correctly.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Wed Nov 19 23:38:01 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 19 Nov 2014 22:38:01 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1416436681.92.0.835942451086.issue22536@psf.upfronthosting.co.za>


Akira Li added the comment:

It would be inconsitent to provide filename only if exec is called e.g.:

   >>> import subprocess
   subprocess.call("not used", cwd="nonexistent")
   FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent'

The error message shows the filename (cwd) despite exec not being 
called therefore it would be logical to provide non-None `filename` 
attribute here too.

If we ignore the backward compatibility issue I've mentioned in msg231297 
then the current code:

                        if errno_num == errno.ENOENT:
                            if child_exec_never_called:
                                # The error must be from chdir(cwd).
                                err_msg += ': ' + repr(cwd)
                            else:
                                err_msg += ': ' + repr(orig_executable)
                    raise child_exception_type(errno_num, err_msg)

could be replaced with:
                        
                        if errno_num == errno.ENOENT:
                            if child_exec_never_called:
                                # The error must be from chdir(cwd).
                                filename = cwd
                            else:
                                filename = orig_executable
                            raise child_exception_type(errno_num, err_msg, filename)
                    raise child_exception_type(errno_num, err_msg)


[1] https://hg.python.org/cpython/file/23ab1197df0b/Lib/subprocess.py#l1443

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Wed Nov 19 23:55:34 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Nov 2014 22:55:34 +0000
Subject: [issue22904] make profile-opt fails to update _sysconfigdata.py
 during the rebuild
Message-ID: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

1) Checkout a 3.4 tree.  Mine was at revision d244e1770f1b.
2) ./configure
3) make -j14 profile-opt
4) ./python -m test.regrtest -v test_distutils

FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/.../oss/cpython/3.4/Lib/distutils/tests/test_sysconfig.py", line 131, in test_sysconfig_module
    sysconfig.get_config_var('CFLAGS'))
AssertionError: '-Wno[38 chars] -Wall -Wstrict-prototypes  -fprofile-use -fprofile-correction' != '-Wno[38 chars] -Wall -Wstrict-prototypes'

This can be traced to the built _sysconfigdata.py file which contains the command line passed CFLAGS from the build_all_use_profile target's sub-make vs the distutils.sysconfig module's Makefile parsing which finds the PY_CFLAGS value from the Makefile itself.

One of either stripping the profile-opt related flags out when generating _sysconfigdata.py or explicitly generating a good _sysconfigdata.py file outside of the sub-make's with the profiling generate or use flags seems like a good idea.  The latter is likely easier; just regenerate _sysconfigdata.py after the sub-make.

----------
assignee: gregory.p.smith
messages: 231401
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: make profile-opt fails to update _sysconfigdata.py during the rebuild
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22904>
_______________________________________

From report at bugs.python.org  Wed Nov 19 23:58:19 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Nov 2014 22:58:19 +0000
Subject: [issue22904] make profile-opt fails to update _sysconfigdata.py
 during the rebuild
In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>
Message-ID: <1416437899.98.0.202831905606.issue22904@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Should _sysconfigdata.py contain these flags for reference, implying that it is this test or distutils.sysconfig implementation which is really wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22904>
_______________________________________

From report at bugs.python.org  Wed Nov 19 23:59:00 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Nov 2014 22:59:00 +0000
Subject: [issue22904] make profile-opt includes -fprofile* flags in
 _sysconfigdata CFLAGS
In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>
Message-ID: <1416437940.97.0.313657263617.issue22904@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
title: make profile-opt fails to update _sysconfigdata.py during the rebuild -> make profile-opt includes -fprofile* flags in _sysconfigdata CFLAGS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22904>
_______________________________________

From report at bugs.python.org  Thu Nov 20 00:25:44 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 19 Nov 2014 23:25:44 +0000
Subject: [issue22904] make profile-opt includes -fprofile* flags in
 _sysconfigdata CFLAGS
In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>
Message-ID: <1416439544.99.0.0738170902405.issue22904@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

attaching a proposed workaround in the unittest.

----------
keywords: +patch
Added file: http://bugs.python.org/file37231/issue22904-test-workaround-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22904>
_______________________________________

From report at bugs.python.org  Thu Nov 20 02:52:58 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 20 Nov 2014 01:52:58 +0000
Subject: [issue20106] warn_dir is always true for install_data,
 even if an install_dir is specified
In-Reply-To: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za>
Message-ID: <1416448378.46.0.990347655154.issue20106@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Can you give us steps to reproduce the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20106>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:22:23 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 20 Nov 2014 02:22:23 +0000
Subject: [issue7427] BadStatusLine is hell to debug
In-Reply-To: <1259855564.36.0.140869506599.issue7427@psf.upfronthosting.co.za>
Message-ID: <1416450143.86.0.0880563895112.issue7427@psf.upfronthosting.co.za>


Martin Panter added the comment:

As far as I can tell, the ?line? attribute isn?t documented anyway. But Issue 8450 is opened about improving the exception when the connection is closed.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7427>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:34:25 2014
From: report at bugs.python.org (Joe Julian)
Date: Thu, 20 Nov 2014 02:34:25 +0000
Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread
 problems at shutdown) breaks ceph
In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>
Message-ID: <1416450865.94.0.848080383343.issue21963@psf.upfronthosting.co.za>


Changes by Joe Julian <jjulian at io.com>:


----------
nosy: +Joe.Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21963>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:37:37 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 20 Nov 2014 02:37:37 +0000
Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request --
 fine with urllib, wget, or curl
In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za>
Message-ID: <1416451057.36.0.731436721217.issue14044@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suggest this is the same situation as Issue 6785, and is not a bug in Python. However it might be reasonable to allow forcing a HTTP client connection to version 1.0, which could be used as a workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14044>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:42:10 2014
From: report at bugs.python.org (Tabrez Mohammed)
Date: Thu, 20 Nov 2014 02:42:10 +0000
Subject: [issue20106] warn_dir is always true for install_data,
 even if an install_dir is specified
In-Reply-To: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za>
Message-ID: <1416451330.98.0.349582823726.issue20106@psf.upfronthosting.co.za>


Tabrez Mohammed added the comment:

I don't have access to the code anymore that repro'ed this issue. I just remember writing a setup script for a module I was working on, and when 'install' was run, it would print this error message.

It's pretty easy to see in code what the problem is though. In install_data.py, warn_dir is set to '1' in initialize_options(), but it's value is never altered. So regardless of what is or isn't passed in, the warning will always be printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20106>
_______________________________________

From report at bugs.python.org  Thu Nov 20 03:56:03 2014
From: report at bugs.python.org (Dan Mick)
Date: Thu, 20 Nov 2014 02:56:03 +0000
Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread
 problems at shutdown) breaks ceph
In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>
Message-ID: <1416452163.3.0.245970726012.issue21963@psf.upfronthosting.co.za>


Dan Mick added the comment:

Hi; I'm the original author of the code in the Ceph CLI.  

The reason it does what it does is that the Python CLI calls into librados (Ceph, through ctypes) to connect to the cluster; that connection can block for various reasons, so it's spawned in a thread; after a timeout or ^C, we desire to exit, but if we've got a non-daemon thread stuck in Ceph, and no way to cancel it from the threading module, sys.exit() will also block waiting for the Ceph thread to finally give up.  If, however, we set that thread as a daemon thread, it doesn't block the sys.exit() (that being, I thought, the whole point of daemon threads).

I confess I don't fully understand the change in 7741d0dd66ca, but it does seem to have the side effect of not actually allowing exit while there are outstanding daemon threads not hitting Python.

----------
nosy: +dmick

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21963>
_______________________________________

From report at bugs.python.org  Thu Nov 20 04:02:26 2014
From: report at bugs.python.org (Joe Julian)
Date: Thu, 20 Nov 2014 03:02:26 +0000
Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread
 problems at shutdown) breaks ceph
In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>
Message-ID: <1416452546.18.0.557187852151.issue21963@psf.upfronthosting.co.za>


Joe Julian added the comment:

I suspect the underlying problem is that the fix expects the daemon threads to hit a point where they try to acquire the GIL and that's not going to happen with these librados threads; they stay in librados.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21963>
_______________________________________

From report at bugs.python.org  Thu Nov 20 04:30:20 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 20 Nov 2014 03:30:20 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1416454220.5.0.608588317054.issue8450@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 3566, which also brings up the false BadStatusLine exception, and suggests some kind of retry logic.

Whatever exception it is, it could be documented better. In Issue 66621, the poster thought it should be an IncompleteRead exception.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8450>
_______________________________________

From report at bugs.python.org  Thu Nov 20 04:33:33 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 20 Nov 2014 03:33:33 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1416454413.19.0.401727604998.issue8450@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry the IncompleteRead reference was meant to be Issue 666219

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8450>
_______________________________________

From report at bugs.python.org  Thu Nov 20 05:37:42 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 20 Nov 2014 04:37:42 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
 sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1416458262.71.0.493231171011.issue3566@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think the peek hack needs to go into to the standard library. It is just a workaround for code using the current library, to differentiate an empty status line due to EOF from any other kind of ?bad? status line. This is what Issue 8450, ?False BadStatusLine? is about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Thu Nov 20 06:20:42 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Nov 2014 05:20:42 +0000
Subject: [issue22905] Returned mail: see transcript for details
In-Reply-To: <1416458143.45.0.164573357619.issueNone@psf.upfronthosting.co.za>
Message-ID: <1416460842.63.0.284544878829.issue22905@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file37232/readme.exe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22905>
_______________________________________

From report at bugs.python.org  Thu Nov 20 06:21:58 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Nov 2014 05:21:58 +0000
Subject: [issue22905] Returned mail: see transcript for details
Message-ID: <1416460918.25.0.275338845211.issue22905@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg231412

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22905>
_______________________________________

From report at bugs.python.org  Thu Nov 20 06:22:44 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Nov 2014 05:22:44 +0000
Subject: [issue22905] spam
Message-ID: <1416460964.77.0.157694064444.issue22905@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -glynnc
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
title: Returned mail: see transcript for details -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22905>
_______________________________________

From report at bugs.python.org  Thu Nov 20 07:38:52 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Nov 2014 06:38:52 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1416436681.92.0.835942451086.issue22536@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa3Qqq7fe_0x5nv-AN4eJDG3Dp=_F36ohBFOBRqmOd+Dw@mail.gmail.com>


STINNER Victor added the comment:

I wnated to say that args[0] is not the right filename if exec() was not
called. Yes, there is also cwd for example. The logic to choose the
filename should be done in the child.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Thu Nov 20 10:19:47 2014
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 20 Nov 2014 09:19:47 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416475187.27.0.726002320509.issue11145@psf.upfronthosting.co.za>


Armin Rigo added the comment:

If buf contains "-00" and the type is 'o', then it will be modified in-place even if the string is shared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Thu Nov 20 10:49:52 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Nov 2014 09:49:52 +0000
Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread
 problems at shutdown) breaks ceph
In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>
Message-ID: <1416476992.97.0.274099052546.issue21963@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the explanation.

> I confess I don't fully understand the change in 7741d0dd66ca, but it 
> does seem to have the side effect of not actually allowing exit while 
> there are outstanding daemon threads not hitting Python.

That's a bit weird, as that change doesn't introduce any wait. Are you sure there isn't something else happening, e.g. a lock is owned by the daemon thread and a non-daemon thread tries to acquire it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21963>
_______________________________________

From report at bugs.python.org  Thu Nov 20 10:58:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Nov 2014 09:58:42 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416477522.94.0.286856566455.issue11145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Heh, it's getting really funny.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:12:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Nov 2014 10:12:16 +0000
Subject: [issue22878] PEP 477 (ensurepip backport to 2.7.9): "make install"
 and "make altinstall" integration
In-Reply-To: <1416098348.4.0.722200841811.issue22878@psf.upfronthosting.co.za>
Message-ID: <20141120101211.68806.63004@psf.io>


Roundup Robot added the comment:

New changeset 07f4b6ecd04a by Ned Deily in branch '2.7':
Issue 22878: PEP 477 - "make install" and "make altinstall" integration
https://hg.python.org/cpython/rev/07f4b6ecd04a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22878>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:20:44 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Nov 2014 10:20:44 +0000
Subject: [issue22878] PEP 477 (ensurepip backport to 2.7.9): "make install"
 and "make altinstall" integration
In-Reply-To: <1416098348.4.0.722200841811.issue22878@psf.upfronthosting.co.za>
Message-ID: <1416478844.63.0.521335583212.issue22878@psf.upfronthosting.co.za>


Ned Deily added the comment:

Committed for release in 2.7.9.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22878>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:26:19 2014
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 20 Nov 2014 10:26:19 +0000
Subject: [issue17852] Built-in module _io can loose data from buffered files
 at exit
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1416479179.12.0.756453497788.issue17852@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Victor: there is the GIL, you don't need any locking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17852>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:32:13 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 20 Nov 2014 10:32:13 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416479533.92.0.0514235940076.issue22827@psf.upfronthosting.co.za>


Ned Deily added the comment:

The configure and Makefile integration backport has been committed in Issue22878.  Unlike with Python 3, the default is to not install pip unless specifically enabled at configure time or on the "make altinstall" or "make install" targets.

I think that about wraps up the code changes for PEP 477.

But it looks like the documentation changes are not complete.  I noticed the following warnings while building the docs:

./Doc/library/ensurepip.rst:31: WARNING: undefined label: installing-index (if the link has no caption the label must precede a section header)
./Doc/whatsnew/2.7.rst:2631: WARNING: undefined label: installing-index (if the link has no caption the label must precede a section header)
./Doc/whatsnew/2.7.rst:2631: WARNING: undefined label: distributing-index (if the link has no caption the label must precede a section header)

It appears that part of the changes that reference the restructured "Installing Python Modules" and "Distributing Python Modules" docs (that replaced the original Distutils docs) got backported but not the docs themselves.  Nick, were you planning to do that?  If not, the references above should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:43:23 2014
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 20 Nov 2014 10:43:23 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
Message-ID: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>


New submission from Chris Angelico:

See PEP for full details. Attached is POC patch: behaviour is altered globally (rather than respecting a __future__ directive), and minimal changes are made elsewhere to make the test suite mostly pass (test_generators does not - it'll need more comprehensive edits). Note that PEP 8 is deliberately not followed here; some of the edits ought to involve indenting slabs of code, but instead, "half-level" indentation is used, to keep the patch visibly minimal.

----------
components: Interpreter Core, Library (Lib)
files: pep0479.patch
keywords: patch
messages: 231422
nosy: Rosuav
priority: normal
severity: normal
status: open
title: PEP 479: Change StopIteration handling inside generators
versions: Python 3.5
Added file: http://bugs.python.org/file37233/pep0479.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Thu Nov 20 11:58:46 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Nov 2014 10:58:46 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416481126.38.0.179084457093.issue22827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yes, the missing link targets are part of the pending docs changes Donald mentioned above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:29:31 2014
From: report at bugs.python.org (Tom Tanner)
Date: Thu, 20 Nov 2014 11:29:31 +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: <1416482971.65.0.31106353276.issue21718@psf.upfronthosting.co.za>


Tom Tanner added the comment:

ping
I'd appreciate a review of my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21718>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:37:51 2014
From: report at bugs.python.org (Michael Foord)
Date: Thu, 20 Nov 2014 11:37:51 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <1416483471.57.0.201211611362.issue22894@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:40:38 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Nov 2014 11:40:38 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <20141120114020.68820.66795@psf.io>


Roundup Robot added the comment:

New changeset b9775a92c1d0 by Nick Coghlan in branch 'default':
Issue #22869: Split pythonrun into two modules
https://hg.python.org/cpython/rev/b9775a92c1d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:46:14 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Nov 2014 11:46:14 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416483974.69.0.909648173186.issue22869@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Thu Nov 20 12:56:51 2014
From: report at bugs.python.org (koobs)
Date: Thu, 20 Nov 2014 11:56:51 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1416484611.2.0.506864056944.issue21356@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 13:15:27 2014
From: report at bugs.python.org (Bernard Spil)
Date: Thu, 20 Nov 2014 12:15:27 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1416485727.82.0.22960657101.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

EGD was only necessary for some commercial UNIX systems, versions that needed it all reached end of life. It no longer makes sense to have any code referring to it.

        EGD needed until        OS release date
IRIX	6.5.19			feb 2003
Solaris 2.6                     jul 1997
AIX     5.2                     oct 2002
Tru64   5.1B                    sep 2002
HP-UX   11i v2                  sep 2003

Please check OpenBSD's patches to remove EGD support from Python for many versions.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Lib_ssl_py
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/python/3.4/patches/patch-Lib_ssl_py
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/python/3.4/patches/patch-Lib_ssl_py

Alternatively see Gentoo's LibreSSL changes https://github.com/Sp1l/libressl/tree/master/dev-lang/python

----------
nosy: +spil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:00:53 2014
From: report at bugs.python.org (Peter Korsgaard)
Date: Thu, 20 Nov 2014 13:00:53 +0000
Subject: [issue22907] Misc/python-config.sh.in: ensure sed invocations only
 match beginning of strings
Message-ID: <1416488452.97.0.575494016591.issue22907@psf.upfronthosting.co.za>


New submission from Peter Korsgaard:

The build/real prefix handling using sed breaks if build != real and the
standard include / lib directories are used ($prefix/include and $prefix/lib).

E.G.

prefix_build="/usr", libdir="$prefix/lib", includedir="$prefix/include".

If this gets installed with make DESTDIR="/foo" install, then we end up with prefix_real = prefix = "/foo/usr" as expected, but
includedir="/foo/foo/usr/include" and libdir="/foo/foo/usr/lib" because of the double sed invocation (prefix is already expanded).  Work around it by ensuring we only match the beginning of the string.

----------
components: Cross-Build
files: 0001-Misc-python-config.sh.in-ensure-sed-invocations-only.patch
keywords: patch
messages: 231427
nosy: peko
priority: normal
severity: normal
status: open
title: Misc/python-config.sh.in: ensure sed invocations only match beginning of strings
versions: Python 3.4
Added file: http://bugs.python.org/file37234/0001-Misc-python-config.sh.in-ensure-sed-invocations-only.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22907>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:23:53 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Nov 2014 13:23:53 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1416489833.33.0.338169843364.issue21356@psf.upfronthosting.co.za>


STINNER Victor added the comment:

We don't drop feature in minor releases, we are working hard to maintain the backward compatibility.

We may only disable RAND_egd if Python is compiled/linked to LibreSSL. So the check should probably be dynamic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:33:22 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 13:33:22 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416490402.37.0.807058506255.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I've attached a patch which I believe updates the 2.x docs with what 3.x has. I ran ``make html`` and the only errors I got were in relation to pyporting which I don't believe has anything to do with this ticket. 

If someone can sanity check this for me I can go ahead and merge this and close out this ticket.

----------
Added file: http://bugs.python.org/file37235/pep-477-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:33:57 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 13:33:57 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1416490437.24.0.37780290814.issue22850@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Is this ticket able to be closed now or is there more to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:34:48 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 13:34:48 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416490488.16.0.545697996858.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Note: I removed the references to pyvenv in these docs because 2.7 doesn't have that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:45:27 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Nov 2014 13:45:27 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416491127.27.0.771603811493.issue22827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The "prior to version 3.4" question should be updated to talk about "prior to version 2.7.9" instead.

For Python 2, we may want to explicitly mention installing virtualenv (either with pip or the system package manager), as there's no pyvenv provided by default, and the instructions do still assume the use of a virtual environment (just for permissions reasons, rather than the name of the Python executable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 14:55:28 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 13:55:28 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416491728.95.0.149809048731.issue22827@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Updated the docs patch to address Nick's comments.

----------
Added file: http://bugs.python.org/file37236/pep-477-docs-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:00:28 2014
From: report at bugs.python.org (Laurento Frittella)
Date: Thu, 20 Nov 2014 14:00:28 +0000
Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request --
 fine with urllib, wget, or curl
In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za>
Message-ID: <1416492028.82.0.225712464779.issue14044@psf.upfronthosting.co.za>


Laurento Frittella added the comment:

Even if forcing the HTTP/1.0 workaround works it can end up in weird issues, especially if used in something more than a small script, like the one I tried to describe in this issue report[1] for the "requests" python library.

[1] https://github.com/kennethreitz/requests/issues/2341

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14044>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:14:42 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 20 Nov 2014 14:14:42 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416492882.52.0.146158347076.issue22827@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Looks good to me! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:31:10 2014
From: report at bugs.python.org (Michael Foord)
Date: Thu, 20 Nov 2014 14:31:10 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416493870.23.0.0623823761716.issue22827@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:32:46 2014
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 20 Nov 2014 14:32:46 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416493966.89.0.167779091502.issue22895@psf.upfronthosting.co.za>


Matthias Klose added the comment:

do we have something like skipIfInstalled?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Thu Nov 20 15:40:21 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Nov 2014 14:40:21 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <20141120143837.7132.45311@psf.io>


Roundup Robot added the comment:

New changeset 8bc29f5ebeff by Donald Stufft in branch '2.7':
Issue #22827: Backport the new Distributing and Instaling Docs from 3.4
https://hg.python.org/cpython/rev/8bc29f5ebeff

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 16:20:43 2014
From: report at bugs.python.org (Iridium Yang)
Date: Thu, 20 Nov 2014 15:20:43 +0000
Subject: [issue22908] ZipExtFile in zipfile can be seekable
Message-ID: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>


New submission from Iridium Yang:

The ZipExtFile class in zipfile module does not provide a seek method like GzipFile. As a result, it is hard to manipulate files without extract all the content.
For example, a very large tar file compressed with zip. The TarFile module can operate on file object, but need seek method. So the ZipExtFile instance return from ZipFile can not passed into TarFile.
This may seem strange but I encounter this on Samsung firmware.

In fact, the seek method in GzipFile or someother compressed format can be implemented in zipfile very easily. Here is my naive modification (nearly same as in GzipFile)

----------
components: Library (Lib)
files: zipfile.diff
keywords: patch
messages: 231438
nosy: Iridium.Yang
priority: normal
severity: normal
status: open
title: ZipExtFile in zipfile can be seekable
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37237/zipfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22908>
_______________________________________

From report at bugs.python.org  Thu Nov 20 17:42:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 20 Nov 2014 16:42:05 +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: <1416501724.99.0.261423112283.issue21718@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's more a matter of my finding time to fully research the problem and solution than an issue of reviewing the patch itself.  There is also potential cross-talk with other patches involving sqllite statement parsing.  Since the sqlite wrapper doesn't currently have an active maintainer, I'm afraid it may be a bit before any review of these issues happen.  If you can get other community members (doesn't have to be committers) to do reviews (of the concepts as well as the patch itself) that would be helpful.  (python-list might be a place to recruit some interest.)

(Personally I find the fact the the wrapper has to do statement parsing at all to be problematic, but there may be no good solution to that problem when you consider backward compatibility issues.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21718>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:00:56 2014
From: report at bugs.python.org (Michael Foord)
Date: Thu, 20 Nov 2014 17:00:56 +0000
Subject: [issue22858] unittest.__init__:main shadows unittest.main
In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za>
Message-ID: <1416502856.91.0.442693710885.issue22858@psf.upfronthosting.co.za>


Michael Foord added the comment:

One way would be to have an _main.py and have main.py "import *" (or equivalent) from it. We can't get rid of unittest.main being an alias for TestProgram - that's been around forever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22858>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:00:57 2014
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Nov 2014 17:00:57 +0000
Subject: [issue22850] Backport ensurepip Windows installer changes to 2.7
In-Reply-To: <1415766633.74.0.761173067002.issue22850@psf.upfronthosting.co.za>
Message-ID: <1416502857.2.0.084324268531.issue22850@psf.upfronthosting.co.za>


Steve Dower added the comment:

It's done.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22850>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:01:40 2014
From: report at bugs.python.org (Michael Foord)
Date: Thu, 20 Nov 2014 17:01:40 +0000
Subject: [issue22860] unittest TestProgram hard to extend
In-Reply-To: <1415874591.06.0.535535954312.issue22860@psf.upfronthosting.co.za>
Message-ID: <1416502900.29.0.964688216557.issue22860@psf.upfronthosting.co.za>


Michael Foord added the comment:

TestProgram is an abomination.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22860>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:26:34 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 17:26:34 +0000
Subject: [issue22827] Backport ensurepip to 2.7 (PEP 477)
In-Reply-To: <1415552336.2.0.341439932145.issue22827@psf.upfronthosting.co.za>
Message-ID: <1416504394.55.0.166090555592.issue22827@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22827>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:29:32 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 17:29:32 +0000
Subject: [issue22669] Test_venv fails when _ctypes is not available.
In-Reply-To: <1413679068.77.0.788594007735.issue22669@psf.upfronthosting.co.za>
Message-ID: <1416504572.22.0.470029727695.issue22669@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Assigning this to myself, it'll get fixed when pip 6.0 is released and I upgrade ensurepip to it.

----------
assignee: vinay.sajip -> dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22669>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:36:02 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 20 Nov 2014 17:36:02 +0000
Subject: [issue19693] "make altinstall && make install" behaviour differs from
 "make install"
In-Reply-To: <1385131154.65.0.84746252058.issue19693@psf.upfronthosting.co.za>
Message-ID: <1416504962.28.0.126533591078.issue19693@psf.upfronthosting.co.za>


Donald Stufft added the comment:

So here's a thought:

pip does have a CLI flag --force-reinstall which will uninstall and then reinstall whatever is being installed. If we modified things so that ensurepip supported this flag (or always used it with --upgrade) then it would fix this issue. The downside here is that only works with --upgrade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19693>
_______________________________________

From report at bugs.python.org  Thu Nov 20 18:44:00 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 20 Nov 2014 17:44:00 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416505440.65.0.311581742208.issue22895@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> do we have something like skipIfInstalled?

No. There's no exact way of checking for an installed Python, but one possibility is to test whether a given directory exists (e.g. "Modules").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Thu Nov 20 19:20:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Nov 2014 18:20:45 +0000
Subject: [issue22908] ZipExtFile in zipfile can be seekable
In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>
Message-ID: <1416507645.02.0.47298087347.issue22908@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm -1 on adding the seek method with linear complexity. This looks as attractive nonsense to me. It would be better just make TarFile working with non-seekable streams.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22908>
_______________________________________

From report at bugs.python.org  Thu Nov 20 20:10:34 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 20 Nov 2014 19:10:34 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416510634.05.0.832424936091.issue22906@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/issue22906>
_______________________________________

From report at bugs.python.org  Thu Nov 20 20:30:53 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Nov 2014 19:30:53 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <20141120193043.119860.99935@psf.io>


Roundup Robot added the comment:

New changeset dd19add74b21 by Guido van Rossum in branch 'default':
PEP 479: Add link to issue 22906.
https://hg.python.org/peps/rev/dd19add74b21

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Thu Nov 20 22:28:58 2014
From: report at bugs.python.org (Tab Atkins Jr.)
Date: Thu, 20 Nov 2014 21:28:58 +0000
Subject: [issue22909] [argparse] Using parse_known_args,
 unknown arg with space in value is interpreted as first positional arg
Message-ID: <1416518938.92.0.605418746252.issue22909@psf.upfronthosting.co.za>


New submission from Tab Atkins Jr.:

If using parse_known_args() to get argument pass-through, and one of the "unknown" arguments has a value with a space in it (even if quoted!), the entire unknown argument (key=value) will be interpreted as the value of the first positional argument instead.

Example:

```
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("pos", nargs="?", default=None)

parser.parse_known_args(["--foo='bar'"])
# (Namespace(pos=None), ['--foo=bar'])
# As expected.

parse.parse_known_args(["--foo='bar baz'"])
# (Namespace(pos="--foo='bar baz'"), [])
# What?!?
```

Since *known* arguments with spaces in them are parsed fine, this looks to be regression in a lesser-used feature.

----------
components: Library (Lib)
messages: 231448
nosy: TabAtkins
priority: normal
severity: normal
status: open
title: [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22909>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:14:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Nov 2014 00:14:11 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <1416528851.51.0.477151077086.issue22894@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file37238/subtests_failfast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:16:37 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 21 Nov 2014 00:16:37 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416528997.35.0.520849118377.issue22869@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm not absolutely sure but I think this has broken the Windows builds with the following being typical of numerous errors.

2>main.obj : error LNK2019: unresolved external symbol _Py_Finalize referenced in function _Py_Main
2>main.obj : error LNK2019: unresolved external symbol _Py_Initialize referenced in function _Py_Main
2>main.obj : error LNK2019: unresolved external symbol _Py_SetProgramName referenced in function _Py_Main
2>main.obj : error LNK2019: unresolved external symbol _Py_FdIsInteractive referenced in function _Py_Main

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:23:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 00:23:57 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <20141121002353.68832.28745@psf.io>


Roundup Robot added the comment:

New changeset a065ab1c67a8 by Antoine Pitrou in branch 'default':
Issue #22796: HTTP cookie parsing is now stricter, in order to protect against potential injection attacks.
https://hg.python.org/cpython/rev/a065ab1c67a8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22796>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:24:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Nov 2014 00:24:26 +0000
Subject: [issue22796] Support for httponly/secure cookies reintroduced lax
 parsing behavior
In-Reply-To: <1415119663.73.0.242959896593.issue22796@psf.upfronthosting.co.za>
Message-ID: <1416529466.35.0.401708659801.issue22796@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you, I've committed the patch to 3.5 now.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22796>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:30:03 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Nov 2014 00:30:03 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416529803.45.0.611910755234.issue22869@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks. The Windows build files (Visual Studio project files) typically have to be updated when a new C file is added to the source tree. Probably one of our Windows experts can help with that :-)

----------
nosy: +steve.dower, tim.golden, zach.ware
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:46:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 00:46:44 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <20141121004641.68830.92321@psf.io>


Roundup Robot added the comment:

New changeset 31fd106bb68a by Steve Dower in branch 'default':
Issue #22869: Add pylifecycle.c/.h files to pythoncore project.
https://hg.python.org/cpython/rev/31fd106bb68a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:47:36 2014
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Nov 2014 00:47:36 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416530856.6.0.716419005184.issue22869@psf.upfronthosting.co.za>


Steve Dower added the comment:

Fixed. (I was conveniently sitting waiting for other things to build...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 01:59:01 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 21 Nov 2014 00:59:01 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416531541.5.0.614778912249.issue22869@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

2>  getbuildinfo.c
2>pythonrun.obj : error LNK2005: _PyOS_CheckStack already defined in pylifecycle.obj
2>     Creating library C:\cpython\PCbuild\python35.lib and object C:\cpython\PCbuild\python35.exp
2>C:\cpython\PCbuild\python35.dll : fatal error LNK1169: one or more multiply defined symbols found

Still with you or have I got finger trouble? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:01:56 2014
From: report at bugs.python.org (Steve Dower)
Date: Fri, 21 Nov 2014 01:01:56 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416531716.28.0.984333390425.issue22869@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like a few Windows only things were missed. Can you track them down and get them into a patch? I'm out of time to do more right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:05:05 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 21 Nov 2014 01:05:05 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416531905.64.0.233963051865.issue22869@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Out of my depth I'm afraid, sorry :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:05:23 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 01:05:23 +0000
Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread
 problems at shutdown) breaks ceph
In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>
Message-ID: <20141121010513.43952.76105@psf.io>


Roundup Robot added the comment:

New changeset 4ceca79d1c63 by Antoine Pitrou in branch '2.7':
Issue #21963: backout issue #1856 patch (avoid crashes and lockups when
https://hg.python.org/cpython/rev/4ceca79d1c63

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21963>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:05:23 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 01:05:23 +0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
 running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <20141121010514.43952.44749@psf.io>


Roundup Robot added the comment:

New changeset 4ceca79d1c63 by Antoine Pitrou in branch '2.7':
Issue #21963: backout issue #1856 patch (avoid crashes and lockups when
https://hg.python.org/cpython/rev/4ceca79d1c63

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:06:32 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Nov 2014 01:06:32 +0000
Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread
 problems at shutdown) breaks ceph
In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za>
Message-ID: <1416531992.08.0.926212309558.issue21963@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've reverted the original changeset. I still believe it is likely to be an issue on the ceph side, though, and the changes remain in 3.x.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21963>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:08:18 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Nov 2014 01:08:18 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1416532098.96.0.489050370777.issue21356@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

We're still willing to fix this if someone tells us how to test for LibreSSL in C code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:37:31 2014
From: report at bugs.python.org (Greg Ward)
Date: Fri, 21 Nov 2014 01:37:31 +0000
Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux:
 AttributeError: 'PermissionError' object has no attribute 'winerror'
In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za>
Message-ID: <1416533851.02.0.242709851165.issue21775@psf.upfronthosting.co.za>


Greg Ward added the comment:

> Would it be possible to write a unit test, maybe using unittest.mock to 
> mock most parts?

Good idea! Turns out this was quite straightforward. The test patch is:

--- a/Lib/test/test_shutil.py
+++ b/Lib/test/test_shutil.py
@@ -1,6 +1,7 @@
 # Copyright (C) 2003 Python Software Foundation
 
 import unittest
+import unittest.mock
 import shutil
 import tempfile
 import sys
@@ -758,6 +759,20 @@
         self.assertEqual(os.stat(restrictive_subdir).st_mode,
                           os.stat(restrictive_subdir_dst).st_mode)
 
+    @unittest.mock.patch('os.chmod')
+    def test_copytree_winerror(self, mock_patch):
+        # When copying to VFAT, copystat() raises OSError. On Windows, the
+        # exception object has a meaningful 'winerror' attribute, but not
+        # on other operating systems. Do not assume 'winerror' is set.
+        src_dir = tempfile.mkdtemp()
+        dst_dir = os.path.join(tempfile.mkdtemp(), 'destination')
+        self.addCleanup(shutil.rmtree, src_dir)
+        self.addCleanup(shutil.rmtree, os.path.dirname(dst_dir))
+
+        mock_patch.side_effect = PermissionError('ka-boom')
+        with self.assertRaises(shutil.Error):
+            shutil.copytree(src_dir, dst_dir)
+
     @unittest.skipIf(os.name == 'nt', 'temporarily disabled on Windows')
     @unittest.skipUnless(hasattr(os, 'link'), 'requires os.link')
     def test_dont_copy_file_onto_link_to_itself(self):


When run without the bug fix, this reproduces my original failure nicely:

$ ./python Lib/test/test_shutil.py
................s........................s.s........E..s..............................s..
======================================================================
ERROR: test_copytree_winerror (__main__.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/src/cpython/3.4/Lib/shutil.py", line 337, in copytree
    copystat(src, dst)
  File "/data/src/cpython/3.4/Lib/shutil.py", line 191, in copystat
    lookup("chmod")(dst, mode, follow_symlinks=follow)
  File "/data/src/cpython/3.4/Lib/unittest/mock.py", line 896, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/data/src/cpython/3.4/Lib/unittest/mock.py", line 952, in _mock_call
    raise effect
PermissionError: ka-boom

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/src/cpython/3.4/Lib/unittest/mock.py", line 1136, in patched
    return func(*args, **keywargs)
  File "Lib/test/test_shutil.py", line 774, in test_copytree_winerror
    shutil.copytree(src_dir, dst_dir)
  File "/data/src/cpython/3.4/Lib/shutil.py", line 340, in copytree
    if why.winerror is None:
AttributeError: 'PermissionError' object has no attribute 'winerror'

----------------------------------------------------------------------
Ran 89 tests in 0.095s

FAILED (errors=1, skipped=5)

Excellent! No need for root privs, and the bug is quite obvious.

Apply my getattr() fix, and the test passes.

I'll commit on branch 3.4 and merge to default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21775>
_______________________________________

From report at bugs.python.org  Fri Nov 21 02:55:48 2014
From: report at bugs.python.org (Greg Ward)
Date: Fri, 21 Nov 2014 01:55:48 +0000
Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux:
 AttributeError: 'PermissionError' object has no attribute 'winerror'
In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za>
Message-ID: <1416534948.45.0.334101881312.issue21775@psf.upfronthosting.co.za>


Greg Ward added the comment:

> I'll commit on branch 3.4 and merge to default.

Whoops, never mind. Looks like I don't have push permission to hg.python.org after all. It's been 8 years since my last commit, so I shouldn't complain.

So... can someone with commit privs please 

  hg pull -r 3a1fc6452340 http://hg.gerg.ca/cpython

then merge to trunk and push?

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21775>
_______________________________________

From report at bugs.python.org  Fri Nov 21 08:03:41 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 21 Nov 2014 07:03:41 +0000
Subject: [issue22910] test_pydoc test_synopsis_sourceless is a flaky test
Message-ID: <1416553421.91.0.74824945431.issue22910@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

When running a parallel make -j12 test, test_pydoc fails reasonably often with:

test test_pydoc failed -- Traceback (most recent call last):
  File "/.../Lib/test/test_pydoc.py", line 556, in test_synopsis_sourceless   
    synopsis = pydoc.synopsis(filename)
  File "/.../Lib/pydoc.py", line 240, in synopsis
    mtime = os.stat(filename).st_mtime
FileNotFoundError: [Errno 2] No such file or directory: '/.../Lib/__pycache__/os.cpython-34.pyc'

Two other issues mention this failure as being introduced recently in comments:
  http://bugs.python.org/issue20123 & http://bugs.python.org/issue20128

----------
assignee: gregory.p.smith
components: Tests
messages: 231465
nosy: eric.snow, gregory.p.smith, koobs
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pydoc test_synopsis_sourceless is a flaky test
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22910>
_______________________________________

From report at bugs.python.org  Fri Nov 21 08:13:51 2014
From: report at bugs.python.org (Akira Li)
Date: Fri, 21 Nov 2014 07:13:51 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1416554031.71.0.797262262797.issue21872@psf.upfronthosting.co.za>


Akira Li added the comment:

@Esa changing the buffer size helps with some "bad" files
but lzma module still fails on some files.

I've uploaded decompress-example-files.py script that demonstrates it.

----------
nosy: +akira
Added file: http://bugs.python.org/file37239/decompress-example-files.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21872>
_______________________________________

From report at bugs.python.org  Fri Nov 21 08:26:29 2014
From: report at bugs.python.org (Akira Li)
Date: Fri, 21 Nov 2014 07:26:29 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1416554789.52.0.557266873183.issue21872@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Added file: http://bugs.python.org/file37240/decompress-example-files.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21872>
_______________________________________

From report at bugs.python.org  Fri Nov 21 08:26:34 2014
From: report at bugs.python.org (Akira Li)
Date: Fri, 21 Nov 2014 07:26:34 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1416554794.25.0.0802408495388.issue21872@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Removed file: http://bugs.python.org/file37239/decompress-example-files.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21872>
_______________________________________

From report at bugs.python.org  Fri Nov 21 09:15:19 2014
From: report at bugs.python.org (Akira Li)
Date: Fri, 21 Nov 2014 08:15:19 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1416557719.27.0.28282644987.issue21872@psf.upfronthosting.co.za>


Akira Li added the comment:

If lzma._BUFFER_SIZE is less than 2048 then all example files are
decompressed successfully (at least lzma module produces the same
results as xz utility)

----------
Added file: http://bugs.python.org/file37241/decompress-example-files.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21872>
_______________________________________

From report at bugs.python.org  Fri Nov 21 09:15:30 2014
From: report at bugs.python.org (Akira Li)
Date: Fri, 21 Nov 2014 08:15:30 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1416557730.11.0.822016030167.issue21872@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Removed file: http://bugs.python.org/file37240/decompress-example-files.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21872>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:20:40 2014
From: report at bugs.python.org (Michael Foord)
Date: Fri, 21 Nov 2014 09:20:40 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <1416561640.66.0.312734270627.issue22894@psf.upfronthosting.co.za>


Michael Foord added the comment:

Looks good, thanks for the quick response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:31:03 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 21 Nov 2014 09:31:03 +0000
Subject: [issue22910] test_pydoc test_synopsis_sourceless is a flaky test
In-Reply-To: <1416553421.91.0.74824945431.issue22910@psf.upfronthosting.co.za>
Message-ID: <1416562263.9.0.906832364184.issue22910@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee: gregory.p.smith -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22910>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:33:49 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 21 Nov 2014 09:33:49 +0000
Subject: [issue22910] test_pydoc test_synopsis_sourceless is a flaky test
In-Reply-To: <1416553421.91.0.74824945431.issue22910@psf.upfronthosting.co.za>
Message-ID: <1416562429.62.0.543770883624.issue22910@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I suspect flakiness is due to parallel test execution.  Is some other test possibly executing at the same time removing __pycache__ directories or .pyc files to recreate them (test_compileall?)?  If the test were adjusted to point to a .py file of its own that it generates in a temporary directory that would avoid that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22910>
_______________________________________

From report at bugs.python.org  Fri Nov 21 10:34:48 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 21 Nov 2014 09:34:48 +0000
Subject: [issue20123] pydoc.synopsis fails to load binary modules
In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za>
Message-ID: <1416562488.77.0.858600303948.issue20123@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

fyi - tracking the new issue koobs reported in http://bugs.python.org/issue22910

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20123>
_______________________________________

From report at bugs.python.org  Fri Nov 21 11:47:29 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 21 Nov 2014 10:47:29 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1416566849.67.0.924938473723.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

Hi, 

I think this can be found in LibreSSL's opensslv.h 
An ifdef LIBRESSL_VERSION_NUMBER should work

See https://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src/crypto/opensslv.h

_ssl.c includes crypto.h which in turn includes opensslv.h so checking for LIBRESSL_VERSION_NUMBER should provide the correct check.

Attached patch does this in C whereas it should be checked for in configure and disabled with a HAS_RAND_egd
Have not figured out how to do this conditionally in Lib/ssl.py yet

----------
Added file: http://bugs.python.org/file37242/patch-Modules__ssl.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:08:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 14:08:37 +0000
Subject: [issue22908] ZipExtFile in zipfile can be seekable
In-Reply-To: <1416496843.38.0.905339069508.issue22908@psf.upfronthosting.co.za>
Message-ID: <1416578917.57.0.385582487568.issue22908@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually TarFile already works with non-seekable streams. Use TarFile.open() with mode='r|*' or like.

On other hand I'm not against the make non-compressed ZipExtFile seekable. It can be helpful in case when ZIP file is used just as a container for other files.

----------
assignee:  -> serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22908>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:27:41 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 14:27:41 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1416580061.44.0.360478667808.issue14099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I hesitate about applying the patch to maintained releases. On one hand, besides interface (even non-documented details) left the same, the patch changes interiors too much for ordinal bug. I don't see how it can break something, but this doesn't guarantee that changes don't have unexpected effect.

On other hand, this bug can be considered as security-related issue. Malicious local attacker could replace ZIP file between its open and read from it or between two reads, if he has write access to the directory containing ZIP file or there are symplinks under his control in ZIP file path. The danger of this may exceed hypothetical negative consequences of the applying of the patch.

I appeal the matter to release managers. Should we apply this patch (the risk is pretty small) to 2.7 and 3.4?

----------
nosy: +benjamin.peterson, larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:31:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 14:31:35 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1416580295.34.0.645481093465.issue22687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

So what the patch (with mitigated tests) is more preferable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Fri Nov 21 15:39:20 2014
From: report at bugs.python.org (David Wilson)
Date: Fri, 21 Nov 2014 14:39:20 +0000
Subject: [issue14099] ZipFile.open() should not reopen the underlying file
In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za>
Message-ID: <1416580760.06.0.532582931252.issue14099@psf.upfronthosting.co.za>


David Wilson added the comment:

While in spirit this is a bug fix, it's reasonably complex and affects a popular module -- I'm not sure it should be applied to 2.x, and probably not in a minor release of 3.x either. Would it make sense to include as part of 3.5?

(That said, I'd love to see this fixed in 2.x ;))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14099>
_______________________________________

From report at bugs.python.org  Fri Nov 21 16:53:22 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 15:53:22 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <1416585202.92.0.683503010885.issue19720@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM

----------
assignee: brett.cannon -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19720>
_______________________________________

From report at bugs.python.org  Fri Nov 21 17:12:24 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 16:12:24 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1416586344.47.0.996609102706.issue22834@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I have a patch to silence the exception and I'm running the test suite now.

I'm planning to keep this to a 3.5 fix and not changing the semantics in Python 3.4 as the fix is a little different from the standard "directory in sys.path is invalid" since '' is dynamic and I can see someone relying on the current exception bubbling out somehow and not caching the dead directory in sys.path_importer_cache.

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:17:44 2014
From: report at bugs.python.org (Marc Schlaich)
Date: Fri, 21 Nov 2014 17:17:44 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416590264.97.0.193204771216.issue22906@psf.upfronthosting.co.za>


Marc Schlaich added the comment:

AFAIS this would break all existing code for yield-based coroutine schedulers (Tornado, Twisted, Trollius, monocle, ...) when a coroutine is exited with `raise StopIteration` in client code. 

And this seems like a lot, a quick GitHub code search gives various examples, e.g.

- https://github.com/circus-tent/circus-web/blob/3b76c83d1eb984a78ed69a9abcb13054cde78f89/circusweb/circushttpd.py#L170
- https://github.com/kzahel/falcon-api/blob/5c62454db971bc99c52694cf2ce0613fb1504d80/python/falcon_api/session.py#L159
- https://github.com/peterhajas/Genesis/blob/2f1a03c38934b892ee6bb04e07e867bf463b7ae5/servers/genesis/clients.py#L24

----------
nosy: +schlamar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:19:41 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 17:19:41 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <20141121171937.43934.94857@psf.io>


Roundup Robot added the comment:

New changeset 8558fff73032 by Brett Cannon in branch 'default':
Issue #22834: Have import suppress FileNotFoundError when the current
https://hg.python.org/cpython/rev/8558fff73032

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:20:30 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 17:20:30 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <1416590430.16.0.956123253145.issue22834@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Along with fixing this I also updated the import reference to mention how the current working directory is handled.

Thanks to Martin for the report and everyone for their input!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:24:16 2014
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 21 Nov 2014 17:24:16 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416590656.75.0.949948318081.issue22906@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Marc, are those all cases where the "raise StopIteration" is actually inside a generator? If so, it can be trivially replaced with "return". Yes, it'll break that way of spelling it, but it's a completely mechanical transformation, and making the change won't break your code for previous versions of Python. Personally, I would recommend using "return" there anyway, regardless of this proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:35:57 2014
From: report at bugs.python.org (Marc Schlaich)
Date: Fri, 21 Nov 2014 17:35:57 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416591357.8.0.692001153499.issue22906@psf.upfronthosting.co.za>


Marc Schlaich added the comment:

Yes, all yield-based coroutines are generators. I know that there is a backward compatible upgrade path, but this might have a huge impact on existing code.

Interestingly, I didn't know before researching this PEP that you can actually use `return` without arguments in generators before Python 3.3 (even in 2.3) and I have worked a lot with coroutines/generators.

So I'm not even against this proposal and using `return` instead of `raise StopIteration` seems the right way to exit a generator/coroutine, but there could be lots of affected users...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:44:46 2014
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 21 Nov 2014 17:44:46 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416591886.03.0.79898423852.issue22906@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Yep, the question is whether any of the "raise StopIteration" lines are actually non-local flow control. If they're local, then it's easy: mechanical replacement with "return" and it becomes compatible with all versions (unless it has a value attached to it, as "return x" doesn't work in Py2). But if they're non-local, some refactoring will need to be done.

In any case, my line of argument is: A generator function is not an iterator's __next__ method, ergo iterator protocol does not apply. Use of StopIteration is a hack that happens to work because of how generator functions are implemented (a thin wrapper around an iterator), but it's not part of the *concept* of a generator function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 18:46:47 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 17:46:47 +0000
Subject: [issue22394] Update documentation building to use venv and pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1416592007.36.0.250950848773.issue22394@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm going to at least update the Makefile to have a ``make venv`` that will do the steps necessary to create a venv and then check out the necessary tools. It should also be set up so that running the command with a pre-existing venv will update it. This should all lead to commands like ``make html PYTHON=venv/bin/python3`` to work.

----------
assignee: docs at python -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22394>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:11:13 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Nov 2014 18:11:13 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416591886.03.0.79898423852.issue22906@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKzcSrN5ibKZyV95n+nDH39y1JUJ3RqA2a4XZ0UK3_SJg@mail.gmail.com>


Guido van Rossum added the comment:

If all examples were just using "raise StopIteration" instead of "return"
in a generator I would be very happy. Such code can be trivially fixed by
using "return" and the __future__ import will help the eventual transition.

It's sad that apparently this use of return hasn't been better advertised
-- it has existed since generators were first introduced.

On Fri, Nov 21, 2014 at 9:44 AM, Chris Angelico <report at bugs.python.org>
wrote:

>
> Chris Angelico added the comment:
>
> Yep, the question is whether any of the "raise StopIteration" lines are
> actually non-local flow control. If they're local, then it's easy:
> mechanical replacement with "return" and it becomes compatible with all
> versions (unless it has a value attached to it, as "return x" doesn't work
> in Py2). But if they're non-local, some refactoring will need to be done.
>
> In any case, my line of argument is: A generator function is not an
> iterator's __next__ method, ergo iterator protocol does not apply. Use of
> StopIteration is a hack that happens to work because of how generator
> functions are implemented (a thin wrapper around an iterator), but it's not
> part of the *concept* of a generator function.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22906>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:13:34 2014
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 21 Nov 2014 18:13:34 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416593614.89.0.652221257841.issue22906@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Sadly, I don't know of a way to check if that's the case, other than by manually going through and eyeballing the code - if there's "raise StopIteration", see if there's also "yield" in the same function. The three cited examples are (I checked those straight away), but frankly, I am not volunteering to go manually through all of github in search of examples :|

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:17:52 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 21 Nov 2014 18:17:52 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416593872.61.0.537984101225.issue22906@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:26:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 18:26:15 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416594375.38.0.525330218147.issue22906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suggest to apply right now those changes which are compatible with current behavior and don't make code more cumbersome. E.g.

-        while True:
-            yield next(line_pair_iterator)
+        yield from line_pair_iterator

and

-        raise StopIteration
+        return

To me these changes make code even better and are worth to be applied even if PEP 479 will be rejected.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:36:26 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 18:36:26 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <20141121183618.7134.61164@psf.io>


Roundup Robot added the comment:

New changeset 2de3c659a979 by Serhiy Storchaka in branch 'default':
Issue #19720: Suppressed context for some exceptions in importlib.
https://hg.python.org/cpython/rev/2de3c659a979

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19720>
_______________________________________

From report at bugs.python.org  Fri Nov 21 19:42:52 2014
From: report at bugs.python.org (Ian Kelly)
Date: Fri, 21 Nov 2014 18:42:52 +0000
Subject: [issue22911] Segfault on recursive itertools.chain.from_iterable
Message-ID: <1416595372.6.0.247378552877.issue22911@psf.upfronthosting.co.za>


New submission from Ian Kelly:

I expect this should result in a recursion depth exceeded error, not a segmentation fault.

$ cat test.py
import itertools

l = []
it = itertools.chain.from_iterable(l)
l.append(it)
next(it)
$ python3 test.py
Segmentation fault (core dumped)

----------
components: Library (Lib)
messages: 231489
nosy: ikelly
priority: normal
severity: normal
status: open
title: Segfault on recursive itertools.chain.from_iterable
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22911>
_______________________________________

From report at bugs.python.org  Fri Nov 21 20:07:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 19:07:42 +0000
Subject: [issue14010] deeply nested filter segfaults
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1416596862.19.0.807423287461.issue14010@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue22911 for another instance of this in chain.from_iterable().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Fri Nov 21 20:08:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 19:08:29 +0000
Subject: [issue22911] Segfault on recursive itertools.chain.from_iterable
In-Reply-To: <1416595372.6.0.247378552877.issue22911@psf.upfronthosting.co.za>
Message-ID: <1416596909.81.0.632858961272.issue22911@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue14010.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> deeply nested filter segfaults

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22911>
_______________________________________

From report at bugs.python.org  Fri Nov 21 20:55:58 2014
From: report at bugs.python.org (Taylor Marks)
Date: Fri, 21 Nov 2014 19:55:58 +0000
Subject: [issue22912] urlretreive locks up in 2.7.8
Message-ID: <1416599758.35.0.866747041142.issue22912@psf.upfronthosting.co.za>


New submission from Taylor Marks:

The following code causes Python 2.7.8 to lockup for ten minutes, then crash, in both Windows 7 and OS X:

from urllib import urlretrieve
urlretrieve('http://chromedriver.storage.googleapis.com/2.12/chromedriver_win32.zip', 'chromedriver_win32.zip')

Here's a thread on StackOverflow where I originally posted about this bug, assuming it was an issue in my code, before other people let me know that the problem wasn't my code, but with Python 2.7.8, on both Windows 7 and OS X, and that in older versions of Python, such as 2.7.6, the code works fine.

http://stackoverflow.com/questions/27025998/urllib-urlretreive-completely-locks-up-python

----------
components: Library (Lib)
messages: 231492
nosy: TaylorSMarks
priority: normal
severity: normal
status: open
title: urlretreive locks up in 2.7.8
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22912>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:00:03 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 20:00:03 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <1416600003.94.0.539515192735.issue19720@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/issue19720>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:00:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 20:00:16 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <20141121200005.119858.14558@psf.io>


Roundup Robot added the comment:

New changeset 8f77f7bb46c7 by Serhiy Storchaka in branch 'default':
Issue #19720: Suppressed context for some exceptions in importlib.
https://hg.python.org/cpython/rev/8f77f7bb46c7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19720>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:00:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 21 Nov 2014 20:00:16 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <20141121200005.119858.2155@psf.io>


Roundup Robot added the comment:

New changeset 301d62ef5c0b by Serhiy Storchaka in branch '2.7':
Issue #17293: socket.gethostbyname() can raise an exception of FreeBSD.
https://hg.python.org/cpython/rev/301d62ef5c0b

New changeset 97ceab0bd6f8 by Serhiy Storchaka in branch '3.4':
Issue #17293: socket.gethostbyname() can raise an exception of FreeBSD.
https://hg.python.org/cpython/rev/97ceab0bd6f8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:03:13 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 20:03:13 +0000
Subject: [issue22913] Rewrite of Python 2/3 porting HOWTO
Message-ID: <1416600192.1.0.141771846079.issue22913@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This is a rewrite of the Python 2/3 porting HOWTO to describe how to make code be compatible with both Python 2 & 3. To see it rendered for easier reading, see https://gist.github.com/brettcannon/91ff264ae549315706f6

----------
assignee: brett.cannon
components: Documentation
files: pyporting.diff
keywords: patch
messages: 231495
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rewrite of Python 2/3 porting HOWTO
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37243/pyporting.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22913>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:03:22 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 20:03:22 +0000
Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO
Message-ID: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This is a rewrite of the Python 2/3 porting HOWTO to describe how to make code be compatible with both Python 2 & 3. To see it rendered for easier reading, see https://gist.github.com/brettcannon/91ff264ae549315706f6

----------
assignee: brett.cannon
components: Documentation
files: pyporting.diff
keywords: patch
messages: 231496
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rewrite of Python 2/3 porting HOWTO
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37244/pyporting.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22914>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:03:53 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 20:03:53 +0000
Subject: [issue22913] Rewrite of Python 2/3 porting HOWTO
In-Reply-To: <1416600192.1.0.141771846079.issue22913@psf.upfronthosting.co.za>
Message-ID: <1416600233.53.0.138301742214.issue22913@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Rewrite of Python 2/3 porting HOWTO

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22913>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:04:12 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 20:04:12 +0000
Subject: [issue19720] suppress context for some exceptions in importlib?
In-Reply-To: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>
Message-ID: <1416600252.29.0.51264156411.issue19720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, 8f77f7bb46c7 is related to issue17293, not this issue. I have copied wrong commit message from clipboard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19720>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:15:03 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 21 Nov 2014 20:15:03 +0000
Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO
In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>
Message-ID: <1416600903.09.0.891889130472.issue22914@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22914>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:18:06 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 21 Nov 2014 20:18:06 +0000
Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO
In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>
Message-ID: <1416601085.99.0.770483744203.issue22914@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/issue22914>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:37:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 20:37:20 +0000
Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO
In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>
Message-ID: <1416602240.93.0.882617436536.issue22914@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why you have removed many sections: about subclassing from object, using io classes, comparison of bytes with unicode objects, the use of warnings and -b and -3 options and other subtle details?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22914>
_______________________________________

From report at bugs.python.org  Fri Nov 21 21:42:28 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Nov 2014 20:42:28 +0000
Subject: [issue22912] urlretreive locks up in 2.7.8
In-Reply-To: <1416599758.35.0.866747041142.issue22912@psf.upfronthosting.co.za>
Message-ID: <1416602548.4.0.444169604793.issue22912@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry, I'm unable to reproduce the problem using various systems and various version of Python 2.7.  And, as I read the StackOverflow comments, it appears that no one else was able to reproduce the problem, either.  To investigate further, we would need more information, including a copy of the exception traceback or other info when the failure occurs.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22912>
_______________________________________

From report at bugs.python.org  Fri Nov 21 22:17:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Nov 2014 21:17:59 +0000
Subject: [issue19361] Specialize exceptions thrown by JSON parser
In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za>
Message-ID: <1416604679.25.0.248893331862.issue19361@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

While we here may be change error messages?

The only error which contains end position is "Extra data". And it doesn't look clean to me why end position should be mentioned at all (it is always len(data) here). I suggest to drop it, this will make error message cleaner and JSONDecodeError simpler.

May be mention line and column in error message only if JSON data is multiline? Most machine generated data has one line only. Instead of "Expecting ',' delimiter: line 1 column 123 (char 124)" I suggest "Expecting ',' delimiter at position 124". Same as in re.error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19361>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:35:14 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Nov 2014 23:35:14 +0000
Subject: [issue10510] distutils upload/register should use CRLF in HTTP
 requests
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1416612914.22.0.623061640475.issue10510@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks bitdancer for applying this.

FTR I just stumbled on code extracted from chishop that shows Django had issues with the non-CRLF requests sent by distutils: https://github.com/disqus/djangopypi/blob/master/djangopypi/http.py#L19

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:36:25 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 21 Nov 2014 23:36:25 +0000
Subject: [issue17311] use distutils terminology in "PyPI package display"
 section
In-Reply-To: <1361988977.92.0.980923457558.issue17311@psf.upfronthosting.co.za>
Message-ID: <1416612984.99.0.342160923344.issue17311@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Nick being the current shepherd for packaging discussions and the instigator of the new version-independent documentation, I?d like to let him take a decision on this.

----------
assignee: eric.araujo -> ncoghlan
nosy: +ncoghlan
versions: +Python 3.5 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17311>
_______________________________________

From report at bugs.python.org  Sat Nov 22 00:54:11 2014
From: report at bugs.python.org (Jocelyn)
Date: Fri, 21 Nov 2014 23:54:11 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
Message-ID: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>


New submission from Jocelyn:

With the attached code, and an xml file, I got the following error with python 3.4.2:

$ cat toto.xml
<?xml version='1.0' encoding='UTF-8'?>
<test></test>


$ python3.4 toto.py 
Traceback (most recent call last):
  File "toto.py", line 10, in <module>
    parse(proc.stdout, ContentHandler())
  File "/usr/lib/python3.4/xml/sax/__init__.py", line 33, in parse
    parser.parse(source)
  File "/usr/lib/python3.4/xml/sax/expatreader.py", line 107, in parse
    xmlreader.IncrementalParser.parse(self, source)
  File "/usr/lib/python3.4/xml/sax/xmlreader.py", line 119, in parse
    self.prepareParser(source)
  File "/usr/lib/python3.4/xml/sax/expatreader.py", line 111, in prepareParser
    self._parser.SetBase(source.getSystemId())
TypeError: must be str, not int


The same test works with python2, and I would expect the code to work with python 3 too.


Thanks,
Jocelyn

----------
components: XML
messages: 231504
nosy: JocelynJ
priority: normal
severity: normal
status: open
title: sax.parser cannot get xml data from a subprocess pipe
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 01:10:02 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Nov 2014 00:10:02 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416615002.77.0.103777350955.issue22915@psf.upfronthosting.co.za>


R. David Murray added the comment:

My guess is that this is similar to issue 21044.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 01:11:13 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Nov 2014 00:11:13 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416615073.2.0.114658431301.issue22915@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 01:21:32 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Nov 2014 00:21:32 +0000
Subject: [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1416615692.71.0.0295565415553.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Anybody?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Nov 22 03:22:43 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Nov 2014 02:22:43 +0000
Subject: [issue19980] Improve help('non-topic') response
In-Reply-To: <1416615692.71.0.0295565415553.issue19980@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-OUobYbJqVkGkdE4zAVtoUOfY3_d5FOrCbQAMxZuDGgeA@mail.gmail.com>


Zachary Ware added the comment:

Mark, did you test your latest patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Nov 22 03:29:52 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Nov 2014 02:29:52 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416623392.39.0.512324051356.issue22915@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've looked at the sax code, and this does indeed have the same root cause: in python2 a dummy string was used for the 'name' attribute of io objects that are based on file descriptors, whereas in python3 the name is the integer value of the file descriptor.  In test_sax we can see getSystemId being tested that it returns a filename (see test_expat_locator_withinfo).

The fix should be analogous to the issue 21044 fix: check that 'name' is a string and if not don't use it.  I'm marking this as easy; hopefully someone will want to tackle figuring out exactly where in the code it needs to be fixed and adding tests for it.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 05:34:07 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 22 Nov 2014 04:34:07 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <20141122043405.69783.8946@psf.io>


Roundup Robot added the comment:

New changeset e7df0a47af16 by Steve Dower in branch 'default':
Issue #22869: Remove duplicate stack check from pythonrun.c
https://hg.python.org/cpython/rev/e7df0a47af16

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 22 05:35:25 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 04:35:25 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416630925.78.0.037070350618.issue22869@psf.upfronthosting.co.za>


Steve Dower added the comment:

That should be the last fix for Windows - a bit of code that was copied into the new file but not removed from the old one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 22 05:43:51 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Nov 2014 04:43:51 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416631431.52.0.0853558119336.issue22869@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Steve, I was actually just minutes away from committing the same fix in the opposite direction when I got the notification of your commit.  Nick will correct me if I'm wrong but I think PyOS_CheckStack was supposed to stay in pythonrun.c, especially since it's still declared in pythonrun.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 22 06:07:03 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 05:07:03 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416632823.47.0.344462182751.issue22869@psf.upfronthosting.co.za>


Steve Dower added the comment:

You may be right, I didn't think of looking in the include files. I assumed that it was copied without being removed, rather than the copy itself being accidental. Feel free to move it back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 22 06:37:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 22 Nov 2014 05:37:46 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <20141122053742.116332.58496@psf.io>


Roundup Robot added the comment:

New changeset 406965684327 by Zachary Ware in branch 'default':
Closes #22869: Move PyOS_CheckStack back to pythonrun.c
https://hg.python.org/cpython/rev/406965684327

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:02:54 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Nov 2014 08:02:54 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416643374.22.0.967543855696.issue22915@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:05:14 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Nov 2014 08:05:14 +0000
Subject: [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1416643514.72.0.965994018504.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Did I test the last patch?  I would hope so but I simply can't remember as it's nearly four months ago, sorry :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Nov 22 09:28:30 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 22 Nov 2014 08:28:30 +0000
Subject: [issue22869] Split pylifecycle.c out from pythonrun.c
In-Reply-To: <1415963921.95.0.551930895546.issue22869@psf.upfronthosting.co.za>
Message-ID: <1416644910.98.0.391037889283.issue22869@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks folks - Zach's right, that wasn't supposed to move.

I missed the second copy in pylifecycle.c because it's all #ifdef'ed out on Linux, so the linker didn't complain about the duplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22869>
_______________________________________

From report at bugs.python.org  Sat Nov 22 10:33:53 2014
From: report at bugs.python.org (Avneesh Chadha)
Date: Sat, 22 Nov 2014 09:33:53 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416648833.7.0.41185397963.issue22915@psf.upfronthosting.co.za>


Changes by Avneesh Chadha <avneesh.chadha at gmail.com>:


----------
nosy: +Avneesh.Chadha

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 11:34:12 2014
From: report at bugs.python.org (Lita Cho)
Date: Sat, 22 Nov 2014 10:34:12 +0000
Subject: [issue21815] imaplib truncates some untagged responses
In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za>
Message-ID: <1416652452.75.0.496999543097.issue21815@psf.upfronthosting.co.za>


Lita Cho added the comment:

Here is the patch merged together. I apologize for not getting it to you sooner.

----------
Added file: http://bugs.python.org/file37245/imaplib_bracket_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21815>
_______________________________________

From report at bugs.python.org  Sat Nov 22 12:39:46 2014
From: report at bugs.python.org (Federico Ceratto)
Date: Sat, 22 Nov 2014 11:39:46 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416656386.49.0.752138757177.issue22638@psf.upfronthosting.co.za>


Federico Ceratto added the comment:

FYI Debian dropped ssl.PROTOCOL_SSLv3 from Python 2.7 in the upcoming Jessie release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611

----------
nosy: +federico3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sat Nov 22 13:50:43 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Nov 2014 12:50:43 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416660643.58.0.745102805195.issue22638@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> FYI Debian dropped ssl.PROTOCOL_SSLv3 from Python 2.7 in the upcoming 
> Jessie release:

This is not really what the Debian patch does. What it does is allow the ssl module to compile if SSLv3 is disabled in the OpenSSL build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sat Nov 22 14:57:36 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Nov 2014 13:57:36 +0000
Subject: [issue19980] Improve help('non-topic') response
In-Reply-To: <1416643514.72.0.965994018504.issue19980@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-NZ4oxP00s9--ddp6MZzStUAvvt5KY2S5OBQ=AcSTW1BQ@mail.gmail.com>


Zachary Ware added the comment:

In that case, it would be good to make sure it still applies and passes the
tests. Last time I tried it didn't, and I was called away before I could
leave a note to that effect (for which I am sorry).  However, I don't have
a strong enough opinion on this issue for me to have fixed your patch or
even to have kept it in mind to come back to later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Nov 22 17:11:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Nov 2014 16:11:09 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1416672669.85.0.817765003339.issue1610654@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/issue1610654>
_______________________________________

From report at bugs.python.org  Sat Nov 22 17:11:46 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 22 Nov 2014 16:11:46 +0000
Subject: [issue21815] imaplib truncates some untagged responses
In-Reply-To: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za>
Message-ID: <1416672706.52.0.36088973132.issue21815@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21815>
_______________________________________

From report at bugs.python.org  Sat Nov 22 17:36:18 2014
From: report at bugs.python.org (Kevin Smith)
Date: Sat, 22 Nov 2014 16:36:18 +0000
Subject: [issue22916] Interpreter segfault on attempted tab complete
Message-ID: <1416674178.09.0.829992164977.issue22916@psf.upfronthosting.co.za>


New submission from Kevin Smith:

I am getting a segmentation fault in the interpreter when trying to tab complete options for a module.  I am running python 3.4.2 on Arch Linux.

Python 3.4.2 (default, Oct  8 2014, 13:44:52) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sfml as sf
>>> t = sf.Texture.from_file ("sprites.png")
>>> s = sf.Sprite (t)
>>> s.Segmentation fault

When I type "s." then push tab to complete available options the interpreter segfaults.  This is with python-sfml-1.3-4 from the Arch repositories.  Tab completion for built-in types seems to work fine.

----------
messages: 231520
nosy: FazJaxton
priority: normal
severity: normal
status: open
title: Interpreter segfault on attempted tab complete
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22916>
_______________________________________

From report at bugs.python.org  Sat Nov 22 18:04:36 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 22 Nov 2014 17:04:36 +0000
Subject: [issue22834] Unexpected FileNotFoundError when current directory is
 removed
In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za>
Message-ID: <20141122170432.69775.42640@psf.io>


Roundup Robot added the comment:

New changeset d065e6474b67 by Zachary Ware in branch 'default':
Issue #22834: cwd can't not exist on Windows, skip the test
https://hg.python.org/cpython/rev/d065e6474b67

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22834>
_______________________________________

From report at bugs.python.org  Sat Nov 22 19:30:53 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 22 Nov 2014 18:30:53 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416681053.97.0.487825112658.issue22638@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Right, they did that because Debian has disabled SSLv3 in OpenSSL in Jessie.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sat Nov 22 19:47:10 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 22 Nov 2014 18:47:10 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416682030.4.0.701835385885.issue22638@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If that's the case, then I agree we can backport e971f3c57502 to the bugfix branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sat Nov 22 19:50:58 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 22 Nov 2014 18:50:58 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416682258.63.0.139291543742.issue22638@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Yea see: http://sources.debian.net/src/openssl/1.0.2~beta3-1/debian/rules/#L29

The configure options they are running with are: no-idea no-mdc2 no-rc5 no-zlib  enable-tlsext no-ssl2 no-ssl3 no-ssl3-method enable-unit-test

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sat Nov 22 20:18:45 2014
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 22 Nov 2014 19:18:45 +0000
Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO
In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>
Message-ID: <1416683925.42.0.469002298218.issue22914@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I removed a bunch of sections for two reasons. One is they are redundant. If you follow the HOWTO and actually read What's New then you will get a bunch of those same details anyway. The tools will also handle the details for you and so you really don't have to worry about them (and they document them already). And Pylint will warn you when you have not taken care of them. So having a fourth place listing the fact you need to subclass object is simply a waste.

Second is accidental FUD. If you have a huge list of things to watch out for then you are going to end up scaring people off by making them feel intimidated at the work ahead of them. But if you reframe the whole thing as "just follow this TODO list and you will be fine" you can make people realize that most things are simply not a big deal.

But the point about telling people to run with -bb and -3 and a couple of minor comments are valid and I will toss some of them back in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22914>
_______________________________________

From report at bugs.python.org  Sat Nov 22 20:51:19 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 19:51:19 +0000
Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments
 properly
In-Reply-To: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za>
Message-ID: <1416685879.26.0.865964308559.issue22733@psf.upfronthosting.co.za>


Steve Dower added the comment:

Nosying the other Windows guys - seems like the ctypes nosy list is inactive, and this only affects MSVC.

----------
nosy: +tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22733>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:19:30 2014
From: report at bugs.python.org (heme)
Date: Sat, 22 Nov 2014 20:19:30 +0000
Subject: [issue22917] Calculating problem
In-Reply-To: <20141122200049.5CFDB56363@psf.upfronthosting.co.za>
Message-ID: <a028839fc31febb219cd72f70ef4967a@jubii.dk>


New submission from heme:

Hi guys 

I am very new to this, (just started my first lines today) so I am using
a book to learn Python. BUT there is something wrong: 

This is my program (from the book): 

# This is not quite true outside of USA
# and is based on my dim memories of my younger years
print("Firstish Grade")
print("1 + 1 =", 1 + 1)
print("2 + 4 =", 2 + 4)
print("5 - 2 =", 5 - 2)
print()
print("Thirdish Grade")
print("243 - 23 =", 243 - 23)
print("12 * 4 =", 12 * 4)
print("12 / 3 =", 12 / 3)
print("13 / 3 =", 13 // 3, "R", 13 % 3)
print()
print("Junior High")
print("123.56 - 62.12 =", 123.56 - 62.12)
print("(4 + 3) * 2 =", (4 + 3) * 2)
print("4 + 3 * 2 =", 4 + 3 * 2)
print("3 ** 2 =", 3 ** 2) 

and this is the programs answer: 

Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32
bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 
Firstish Grade
1 + 1 = 2
2 + 4 = 6
5 - 2 = 3

Thirdish Grade
243 - 23 = 220
12 * 4 = 48
12 / 3 = 4.0
13 / 3 = 4 R 1

Junior High
123.56 - 62.12 = 61.440000000000005
(4 + 3) * 2 = 14
4 + 3 * 2 = 10
3 ** 2 = 9
>>> 

As you can see, 

print("123.56 - 62.12 =", 123.56 - 62.12) is not = 61.440000000000005 

so my guess is that the interpreter has a malfunction. 

My pc is a compaq mini 110 running (walking;-)) windows xp srv pack 3 

in a std. config. 

brg 

Henning Mentz - Denmark

----------
messages: 231527
nosy: heme
priority: normal
severity: normal
status: open
title: Calculating problem

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22917>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:33:45 2014
From: report at bugs.python.org (SilentGhost)
Date: Sat, 22 Nov 2014 20:33:45 +0000
Subject: [issue22917] Calculating problem
In-Reply-To: <a028839fc31febb219cd72f70ef4967a@jubii.dk>
Message-ID: <1416688425.91.0.356398770952.issue22917@psf.upfronthosting.co.za>


SilentGhost added the comment:

Hi Henning,

this is not a bug. This is to do with how floating point numbers represented in computers. I'd suggest https://en.wikipedia.org/wiki/IEEE_floating_point as a starting point. Briefly, due to binary base that the computers operate on, not every number can be stored/represented precisely. In any case there are plenty of other information online that you can find useful, the easiest solution is to output correctly formatted strings corresponding to your answers.

Good luck.

----------
nosy: +SilentGhost
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22917>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:49:39 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Nov 2014 20:49:39 +0000
Subject: [issue22918] Doc for __iter__ makes inexact comment about
 dict.__iter__
Message-ID: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

https://docs.python.org/3/reference/datamodel#object.__iter__

> This method should return a new iterator object that can iterate over all the objects
> in the container. For mappings, it should iterate over the keys of the container, and
> should also be made available as the method keys().

In 3.x, d.__iter__() is not equivalent to d.keys() but to iter(d.keys()).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 231529
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc for __iter__ makes inexact comment about dict.__iter__
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22918>
_______________________________________

From report at bugs.python.org  Sat Nov 22 21:52:25 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 22 Nov 2014 20:52:25 +0000
Subject: [issue22916] Interpreter segfault on attempted tab complete
In-Reply-To: <1416674178.09.0.829992164977.issue22916@psf.upfronthosting.co.za>
Message-ID: <1416689545.64.0.043536248603.issue22916@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is very unlikely to be a problem in Python itself, rather a problem with the third-party python-sfml package or a build interaction issue.  Have you asked on either an Arch or a python-sfml list about this?  What happens if you you try "dir(s)" instead?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22916>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:40:09 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 21:40:09 +0000
Subject: [issue22919] Update PCBuild for VS 2015
Message-ID: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>


New submission from Steve Dower:

I've basically finished the core of the work to refresh the PCBuild project files and support building with VS 2015, and I believe it's ready to merge in.

Though the title says VS 2015, builds will work fine with VS 2010 and VS 2013 (and probably VS 2012, but I didn't try it). Even so, I've copied the old project files into PC/VS10.0, though I'd be happy to just forget them.

I suspect Tools/msi/msi.py will stop working with this change. My replacement installer is not ready yet. If anyone's particularly concerned about msi.py then I can try and restore it before checking this in, but I'm 99.9% certain it won't be used for 3.5, so I don't see the point.


I've attached two patches, one with all the changes and the other with the "highlights" - the diff between the diffs are most of the project files and the added/deleted files. I imagine practically everyone will have a better time viewing the changes in their own hg tools, so the changes can be pulled from my sandbox with "hg pull https://hg.python.org/sandbox/steve.dower -b Projects" or viewed at https://hg.python.org/sandbox/steve.dower/shortlog/d08b456124e5. (I'll rebase these as a single commit in default when it goes in.)

A few changes that may deserve some more discussion:

* Builds for 32-bit now go to PCBuild\win32 instead of PCBuild (the batch file updates should make this transparent)

* The project that used to trigger the OpenSSL build is now two projects (libeay, ssleay) that do the build directly, so they may need updating whenever we update the OpenSSL version or change _ssl/_hashlib. I'm obviously happy to track these. (The advantages are proper incremental builds, better debugging, better optimisation - definitely PGO if we turn that back on.)

* The posixmodule.c update for Py_Verify_fd may become redundant - the VC14 CRT will include a per-thread function to change the invalid parameter handling, so when that's available we should be able to switch away from this trickery completely.

* I changed some GetVersion calls (which no longer behave properly as of Windows 8.1) to use functions from VersionHelpers.h in VS 2013 and later.

* build.bat now builds in parallel by default, with '-M' to disable.

* PCBuild/readme.txt has been updated as if VS 2015 has already been released. This is not yet true, but I doubt anyone who notices will be particularly confused or upset.

----------
assignee: steve.dower
components: Build, Windows
files: projects_highlights.diff
keywords: needs review, patch
messages: 231531
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Update PCBuild for VS 2015
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37246/projects_highlights.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:41:25 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 21:41:25 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416692485.33.0.405047184047.issue22919@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


Added file: http://bugs.python.org/file37247/projects_full.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:42:32 2014
From: report at bugs.python.org (eryksun)
Date: Sat, 22 Nov 2014 21:42:32 +0000
Subject: [issue22916] Interpreter segfault on attempted tab complete
In-Reply-To: <1416674178.09.0.829992164977.issue22916@psf.upfronthosting.co.za>
Message-ID: <1416692552.41.0.902772460244.issue22916@psf.upfronthosting.co.za>


eryksun added the comment:

This isn't a bug in Python or tab completion. You can reproduce the fault by referencing s.transformable twice and then deleting both references. 

The getter for TransformableDrawable.transformable calls wrap_transformable to create a wrapper for the underlying C++ object (self.p_transformable). 

TransformDrawable
https://github.com/Sonkun/python-sfml/blob/v1.3/src/sfml/graphics.pyx#L1175

wrap_transformable
https://github.com/Sonkun/python-sfml/blob/v1.3/src/sfml/graphics.pyx#L381

Thus each Transformable wrapper references the same C++ object. 

Transformable.__dealloc__ in graphics.pyx

https://github.com/Sonkun/python-sfml/blob/v1.3/src/sfml/graphics.pyx#L1117

gets Cythonized as __pyx_pf_4sfml_8graphics_13Transformable_2__dealloc__ in graphics.cpp. This executes the C++ delete that segfaults:

    delete __pyx_v_self->p_this;

For example:

    >>> x = s.transformable
    >>> y = s.transformable
    >>> del y

    Breakpoint 1, __pyx_pf_4sfml_8graphics_13Transformable_2__dealloc__
    (__pyx_v_self=0xb774d8c0) at src/sfml/graphics.cpp:21354
    21354	  delete __pyx_v_self->p_this;
    (gdb) p __pyx_v_self->p_this
    $1 = (sf::Transformable *) 0x8695b24
    (gdb) c
    Continuing.
    >>> del x

    Breakpoint 1, __pyx_pf_4sfml_8graphics_13Transformable_2__dealloc__
    (__pyx_v_self=0xb774d910) at src/sfml/graphics.cpp:21354
    21354	  delete __pyx_v_self->p_this;
    (gdb) p __pyx_v_self->p_this
    $2 = (sf::Transformable *) 0x8695b24
    (gdb) c
    Continuing.

    Program received signal SIGSEGV, Segmentation fault.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22916>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:56:21 2014
From: report at bugs.python.org (Steve Dower)
Date: Sat, 22 Nov 2014 21:56:21 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416693381.81.0.447771047582.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

Oh, one other thing I just thought of: the current release of nmake (in VS 2015) has a regression that will make TCL and TK fail to build, but I have a workaround for their makefile. OpenSSL also had a problem with VC14 but their fix isn't in the build we've got on svn.python.org.

If possible, I'd like to get the workarounds into our sources for those before this is checked in, so that the buildbots (currently there's one that I know of with VS 2015 Preview installed) can pick up those fixes and won't fail because of these.

The nmake issue should be fixed for VS 2015 RC and the OpenSSL issue is already fixed (in their 1.1 branch, IIRC). I've attached a patch listing the changes needed.

----------
Added file: http://bugs.python.org/file37248/fixups.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:56:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2014 21:56:28 +0000
Subject: [issue22920] Crash with itertools
Message-ID: <1416693388.96.0.0990071080113.issue22920@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

import itertools

l = []
it = itertools.chain.from_iterable(l)
l.append(it)
next(it)

Ian Kelly (python-list, version unspecified) got "Segmentation fault (core dumped)".  With 2.7, 3.4.2, 3.5, I get same in interactive interpreter, the Windows "python has stopped working" box from console, or subprocess hang with Idle.

----------
messages: 231534
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Crash with itertools
type: crash
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22920>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:56:51 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2014 21:56:51 +0000
Subject: [issue22920] Crash with itertools
In-Reply-To: <1416693388.96.0.0990071080113.issue22920@psf.upfronthosting.co.za>
Message-ID: <1416693411.08.0.434155075466.issue22920@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22920>
_______________________________________

From report at bugs.python.org  Sat Nov 22 22:59:35 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Nov 2014 21:59:35 +0000
Subject: [issue22920] Crash with itertools.chain.from_iterable
In-Reply-To: <1416693388.96.0.0990071080113.issue22920@psf.upfronthosting.co.za>
Message-ID: <1416693575.22.0.233126657724.issue22920@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Crash with itertools -> Crash with itertools.chain.from_iterable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22920>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:03:50 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Nov 2014 22:03:50 +0000
Subject: [issue22920] Crash with itertools.chain.from_iterable
In-Reply-To: <1416693388.96.0.0990071080113.issue22920@psf.upfronthosting.co.za>
Message-ID: <1416693830.12.0.8723606663.issue22920@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman
resolution:  -> duplicate
status: open -> closed
superseder:  -> deeply nested filter segfaults

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22920>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:05:11 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Nov 2014 22:05:11 +0000
Subject: [issue14010] deeply nested filter segfaults
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1416693911.78.0.329762087809.issue14010@psf.upfronthosting.co.za>


Ethan Furman added the comment:

>From Terry Reedy in issue22920:
------------------------------
Ian Kelly (python-list, version unspecified) got "Segmentation fault (core dumped)".  With 2.7, 3.4.2, 3.5, I get same in interactive interpreter, the Windows "python has stopped working" box from console, or subprocess hang with Idle.

----------
nosy: +ethan.furman
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:07:23 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Nov 2014 22:07:23 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416694043.66.0.871734899714.issue22919@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/issue22919>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:28:33 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Nov 2014 22:28:33 +0000
Subject: [issue22916] Interpreter segfault on attempted tab complete
In-Reply-To: <1416674178.09.0.829992164977.issue22916@psf.upfronthosting.co.za>
Message-ID: <1416695313.11.0.524406896618.issue22916@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22916>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:36:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Nov 2014 22:36:32 +0000
Subject: [issue22918] Doc for __iter__ makes inexact comment about
 dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416695792.59.0.445054635301.issue22918@psf.upfronthosting.co.za>


R. David Murray added the comment:

They aren't equivalent in python2, either.  I think probably the wording should be changed to something like "and the method keys() should return an iterable that provides access to the same data".

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22918>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:52:20 2014
From: report at bugs.python.org (Jocelyn)
Date: Sat, 22 Nov 2014 22:52:20 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416696740.01.0.771673814399.issue22915@psf.upfronthosting.co.za>


Jocelyn added the comment:

Here is a patch to add a test to test_sax.py.

I'm not sure on the fix. Is the following one a correct one ?

     def prepareParser(self, source):
         if source.getSystemId() is not None:
-            self._parser.SetBase(source.getSystemId())
+            self._parser.SetBase(str(source.getSystemId()))


Or should I remove the call to SetBase if getSystemId() is not a string ?

----------
keywords: +patch
Added file: http://bugs.python.org/file37249/test-22915.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sat Nov 22 23:57:39 2014
From: report at bugs.python.org (Jocelyn)
Date: Sat, 22 Nov 2014 22:57:39 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416697059.77.0.374993840162.issue22915@psf.upfronthosting.co.za>


Jocelyn added the comment:

Forgot to attach the testcase when opening the bug.

----------
Added file: http://bugs.python.org/file37250/toto.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sun Nov 23 00:03:36 2014
From: report at bugs.python.org (heme)
Date: Sat, 22 Nov 2014 23:03:36 +0000
Subject: [issue22917] Calculating problem
In-Reply-To: <1416688425.91.0.356398770952.issue22917@psf.upfronthosting.co.za>
Message-ID: <f5213ac385fb5707d971525cd04560e8@jubii.dk>


heme added the comment:

Hi SilentGhost 

Thanx for a quick response. 

Sorry to hear that it is not a bug, my old GW basic interpretor from
1988 has no problem with this simple calculation (123.56 - 62.12 =
61.44) but my new Python interpreter cannot give me a correct answer. 

Yes, I know about precision, I have been using C for several years, but
as I am interested in the Raspberry Pi I would like to use Python with
it. 

And as I would use it as a data collector (from instruments), I need
good precision and reliability. 

Is there anything I can do? (exept changing to another language) 

brg 

Henning 

SilentGhost skrev den 22/11/2014 21:33: 

> SilentGhost added the comment:
> 
> Hi Henning,
> 
> this is not a bug. This is to do with how floating point numbers represented in computers. I'd suggest https://en.wikipedia.org/wiki/IEEE_floating_point [1] as a starting point. Briefly, due to binary base that the computers operate on, not every number can be stored/represented precisely. In any case there are plenty of other information online that you can find useful, the easiest solution is to output correctly formatted strings corresponding to your answers.
> 
> Good luck.
> 
> ----------
> nosy: +SilentGhost
> resolution: -> not a bug
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22917 [2]>
> _______________________________________

Links:
------
[1] https://en.wikipedia.org/wiki/IEEE_floating_point
[2] http://bugs.python.org/issue22917

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22917>
_______________________________________

From report at bugs.python.org  Sun Nov 23 00:23:39 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Nov 2014 23:23:39 +0000
Subject: [issue22917] Calculating problem
In-Reply-To: <a028839fc31febb219cd72f70ef4967a@jubii.dk>
Message-ID: <1416698619.11.0.99273527065.issue22917@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

https://docs.python.org/3/tutorial/floatingpoint.html

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22917>
_______________________________________

From report at bugs.python.org  Sun Nov 23 00:27:08 2014
From: report at bugs.python.org (Martin Dengler)
Date: Sat, 22 Nov 2014 23:27:08 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416698828.14.0.166266645092.issue22919@psf.upfronthosting.co.za>


Changes by Martin Dengler <martin at martindengler.com>:


----------
nosy: +mdengler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sun Nov 23 01:01:44 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Nov 2014 00:01:44 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416700904.84.0.133112331881.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

Fixed and pushed a minor issue with debug builds - I wasn't setting the 'g' suffix on the tcltk libs correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sun Nov 23 01:08:43 2014
From: report at bugs.python.org (heme)
Date: Sun, 23 Nov 2014 00:08:43 +0000
Subject: [issue22917] Calculating problem
In-Reply-To: <1416698619.11.0.99273527065.issue22917@psf.upfronthosting.co.za>
Message-ID: <f97450d30a468671b2dafccd9e71bc55@jubii.dk>


heme added the comment:

Thank you 

I understand that it is not always that you see what you get (GW basic
has shurely cut off the big precision, and Python doesnt, so I see the
small difference. I will take care of thinking of it next time! 

Sorry for any inconvience. 

brg 

Henning 

Mark Lawrence skrev den 23/11/2014 00:23: 

> Mark Lawrence added the comment:
> 
> https://docs.python.org/3/tutorial/floatingpoint.html [1]
> 
> ----------
> nosy: +BreamoreBoy
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22917 [2]>
> _______________________________________

Links:
------
[1] https://docs.python.org/3/tutorial/floatingpoint.html
[2] http://bugs.python.org/issue22917

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22917>
_______________________________________

From report at bugs.python.org  Sun Nov 23 02:05:39 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Nov 2014 01:05:39 +0000
Subject: [issue22918] Doc for __iter__ makes inexact comment about
 dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416704739.33.0.322065390953.issue22918@psf.upfronthosting.co.za>


?ric Araujo added the comment:

The Python 2 doc is alright, the same line says that d.__iter__() is equivalent to d.iterkeys().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22918>
_______________________________________

From report at bugs.python.org  Sun Nov 23 06:27:45 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 23 Nov 2014 05:27:45 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
Message-ID: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>


New submission from Donald Stufft:

The SSLContext().wrap_socket() method allows you to pass in a server_hostname option which will be used for two purposes, it will be used as the server name for SNI and it will be used to verify the server name of the certificate. However currently if the OpenSSL you're using does not have SNI then sending the server_hostname option to wrap_socket() will raise a ValueError.

I think that instead server_hostname should always be accepted by SSLContext().wrap_socket() regardless of if SNI is available or if check_hostname is available. It's just going to be stored and used later so we can conditonally use it for SNI or for checking the hostname depending on if SNI is available or checking if a hostname is available. The way it works right now is that unless you're happy not working when SNI is not available you have to check the hostname yourself.

If we can fix this, I think it would be smart to do it ASAP and get it into Python 2.7.9 and backported to the various Python 3.x's so that in the near future it works with all recent versions of the various Pythons (though older micro releases it may not).

This shouldn't break any code since it's changing what used to be an error into a saner working case.

----------
messages: 231544
nosy: alex, benjamin.peterson, christian.heimes, dstufft
priority: normal
severity: normal
status: open
title: SSLContext's check_hostname needlessly intertwined with SNI
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 06:46:36 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Nov 2014 05:46:36 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416721596.83.0.125817661944.issue22915@psf.upfronthosting.co.za>


R. David Murray added the comment:

Has anyone investigated what exactly sax uses SystemId/SetBase *for*?  I think think we need that info in order to decide what to do, and I'm not familiar with sax.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sun Nov 23 06:49:55 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Nov 2014 05:49:55 +0000
Subject: [issue22918] Doc for __iter__ makes inexact comment about
 dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416721795.76.0.419857747596.issue22918@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  So the python3 docs should say "and should be equivalent to iter(dict.keys())" ?  Or maybe the whole phrase should just be dropped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22918>
_______________________________________

From report at bugs.python.org  Sun Nov 23 07:06:21 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Nov 2014 06:06:21 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416722781.39.0.537372591031.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

Pushed some changes based on Zach's feedback and added a new complete patch (minus the deletion of the PC/VS9.0 and PC/VS10.0 folders).

----------
Added file: http://bugs.python.org/file37251/cpython_93607_to_93616.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sun Nov 23 07:57:42 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Nov 2014 06:57:42 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416725862.4.0.342829749077.issue22895@psf.upfronthosting.co.za>


?ric Araujo added the comment:

What about using ?not sysconfig.is_python_build()??

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Sun Nov 23 10:32:03 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2014 09:32:03 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
Message-ID: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za>


New submission from STINNER Victor:

call_soon() call be called before the event loop starts and after run_forever(), the call will be executed by the next call to run_forever() (or run_until_complete).

But calling call_soon() after close() does not make sense and the user may be surprised to not see its function called. It can be obvious in a simple program, but not in a large application.

----------
components: asyncio
keywords: easy
messages: 231549
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call_soon() should raise an exception if the event loop is closed
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Sun Nov 23 10:45:42 2014
From: report at bugs.python.org (Yoha)
Date: Sun, 23 Nov 2014 09:45:42 +0000
Subject: [issue22923] No prompt for "display all X possibilities" on
 completion-enabled input()
Message-ID: <1416735942.39.0.542265470543.issue22923@psf.upfronthosting.co.za>


New submission from Yoha:

When running input() (or raw_input() for Python 2) while tab-completion has been enabled using `readline.parse_and_bind('tab: complete')`, pressing the tab key twice display the message `Display all X possibilities? (y or n)` when there are more than 100 remaining possibilities (default value). However, I am not asked any input to answer the question, and readline then proceeds to display all possibilities.

Steps to reproduce:

* run the following code: `__import__('readline').parse_and_bind('tab:complete');input()"`
* press tab twice

If your current directory has more than 100 files, the message `Display all X possibilities? (y or n)` should show, following by a list of the files.

The bug still shows up with:
* rlcompleter or custom completer
* versions 2.7.3, 2.7.8, 3.2.3 and 3.4.2
* bash or zsh
* tty, screen, ssh+screen, xterm, urxvt, gnome-terminal
* command-line flags -S (no `site` module), -u (unbuffered) or -Su
* being run as script, as `-c` command-line argument, or in the interactive interpreter
* `import readline;readline.` or `from readline import *` in stead of `__import__('readline').`


On the other hand, the C program "#include <readline/readline.h>", "main(){readline(0);}" behaves as expected: after the message is displayed, user input is waited for and typing "y" lists the possibilities, "n" resumes the line editing, and anything else is ignored.

----------
components: IO, Library (Lib)
messages: 231550
nosy: yoha
priority: normal
severity: normal
status: open
title: No prompt for "display all X possibilities" on completion-enabled input()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22923>
_______________________________________

From report at bugs.python.org  Sun Nov 23 10:49:05 2014
From: report at bugs.python.org (Yoha)
Date: Sun, 23 Nov 2014 09:49:05 +0000
Subject: [issue22923] No prompt for "display all X possibilities" on
 completion-enabled input()
In-Reply-To: <1416735942.39.0.542265470543.issue22923@psf.upfronthosting.co.za>
Message-ID: <1416736145.36.0.528800792671.issue22923@psf.upfronthosting.co.za>


Yoha added the comment:

Forgot to list the system: the bug has been tested and reproduced on Debian amd64, both wheezie and jessie.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22923>
_______________________________________

From report at bugs.python.org  Sun Nov 23 11:06:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 10:06:15 +0000
Subject: [issue22924] Use of deprecated cgi.escape
Message-ID: <1416737175.16.0.367831967609.issue22924@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Deprecated cgi.escape() is used in Tools/scripts/gprof2html.py and Tools/scripts/highlight.py. It should be replaced by html.escape(). Unfortunately the html module clashes with the html parameter in highlight.py so I left this issue for Reymond.

----------
assignee: rhettinger
components: Demos and Tools
keywords: easy
messages: 231552
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Use of deprecated cgi.escape
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22924>
_______________________________________

From report at bugs.python.org  Sun Nov 23 11:47:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 10:47:15 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416739635.1.0.610222605942.issue22915@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This bug should be fixed in other place. Here is a patch.

----------
assignee:  -> serhiy.storchaka
nosy: +christian.heimes, serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37252/sax_non_str_file_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sun Nov 23 12:03:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 11:03:05 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1416740585.89.0.376444807517.issue1610654@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

New test fail with non-modified code. Either there is a bug in current code or tests are wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1610654>
_______________________________________

From report at bugs.python.org  Sun Nov 23 13:11:48 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 12:11:48 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1416744708.97.0.333493392908.issue2175@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------
keywords: +needs review
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Sun Nov 23 13:18:05 2014
From: report at bugs.python.org (Yoha)
Date: Sun, 23 Nov 2014 12:18:05 +0000
Subject: [issue22923] No prompt for "display all X possibilities" on
 completion-enabled input()
In-Reply-To: <1416735942.39.0.542265470543.issue22923@psf.upfronthosting.co.za>
Message-ID: <1416745085.09.0.740080021134.issue22923@psf.upfronthosting.co.za>


Yoha added the comment:

I have found the culprit. It is actually coming from libreadline: <http://git.savannah.gnu.org/cgit/readline.git/tree/complete.c#n517> where the answer is always set to yes in callback mode. According to `git blame`, this is has been so since version 6.2 at least three years ago.

Should Python patch its code to fix readline's behavior? Should I a bug be filed in the GNU maling list for readline? Should I wait and hope this is fixed someday?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22923>
_______________________________________

From report at bugs.python.org  Sun Nov 23 14:45:12 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Nov 2014 13:45:12 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416750312.35.0.185446903956.issue22921@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This sounds ok to me, but are there still SNI-less OpenSSLs around?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 14:45:25 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Nov 2014 13:45:25 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416750325.74.0.119360344671.issue22921@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 15:46:46 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Nov 2014 14:46:46 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416754006.03.0.431418912711.issue22638@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I was looking into a 2.7 backport but it turns out _create_stdlib_context() isn't used anywhere in 2.7 (yet?), so the backport wouldn't achieve anything. I will backport to 3.4 at least.

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sun Nov 23 15:50:41 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Nov 2014 14:50:41 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <20141123145039.69785.68660@psf.io>


Roundup Robot added the comment:

New changeset 653dfb1240d5 by Antoine Pitrou in branch '3.4':
Issue #22638: SSLv3 is now disabled throughout the standard library.
https://hg.python.org/cpython/rev/653dfb1240d5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sun Nov 23 15:55:26 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 23 Nov 2014 14:55:26 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416754526.84.0.166394255183.issue22638@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

In a post-pep476 world, this method will be used on Python2.7, so it would be good to backport now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sun Nov 23 15:57:59 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Nov 2014 14:57:59 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1416754679.5.0.917074001295.issue22895@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> What about using ?not sysconfig.is_python_build()??

I had forgotten about it, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Sun Nov 23 16:01:31 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Nov 2014 15:01:31 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <20141123150127.55127.92422@psf.io>


Roundup Robot added the comment:

New changeset 993e8f795194 by Antoine Pitrou in branch '3.4':
Issue #22894: TestCase.subTest() would cause the test suite to be stopped when in failfast mode, even in the absence of failures.
https://hg.python.org/cpython/rev/993e8f795194

New changeset 04103cece49d by Antoine Pitrou in branch 'default':
Issue #22894: TestCase.subTest() would cause the test suite to be stopped when in failfast mode, even in the absence of failures.
https://hg.python.org/cpython/rev/04103cece49d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Sun Nov 23 16:06:40 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Nov 2014 15:06:40 +0000
Subject: [issue22894] unittest.TestCase.subTest causes all subsequent tests to
 be skipped in failfast mode
In-Reply-To: <1416262689.15.0.441950647675.issue22894@psf.upfronthosting.co.za>
Message-ID: <1416755200.66.0.211731019554.issue22894@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22894>
_______________________________________

From report at bugs.python.org  Sun Nov 23 16:26:31 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Nov 2014 15:26:31 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <20141123152628.84275.33981@psf.io>


Roundup Robot added the comment:

New changeset f762cbb712de by Antoine Pitrou in branch '2.7':
Backport disabling of SSLv3 in ssl._create_stdlib_context() (issue #22638).
https://hg.python.org/cpython/rev/f762cbb712de

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sun Nov 23 16:26:52 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Nov 2014 15:26:52 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416756412.11.0.69722674501.issue22638@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, this is done. Is there anything left in this issue?

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Sun Nov 23 16:50:17 2014
From: report at bugs.python.org (=?utf-8?b?QmFyacWhYSBPYnJhZG92acSH?=)
Date: Sun, 23 Nov 2014 15:50:17 +0000
Subject: [issue22925] Backporting suppress context manager to 2.7
Message-ID: <1416757817.56.0.153442346053.issue22925@psf.upfronthosting.co.za>


New submission from Bari?a Obradovi?:

Backport one of the context manager in 3.4, to 2.7:
supressed

The patch was created by copy pasting code from 3.4 branch to 2.7 branch, and removing a single 3.4 feature:
- at support.requires_docstrings

----------
components: Build
files: suppress.patch
hgrepos: 280
keywords: patch
messages: 231565
nosy: Bari?a.Obradovi?
priority: normal
severity: normal
status: open
title: Backporting suppress context manager to 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37253/suppress.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22925>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:03:21 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 23 Nov 2014 16:03:21 +0000
Subject: [issue22925] Backporting suppress context manager to 2.7
In-Reply-To: <1416757817.56.0.153442346053.issue22925@psf.upfronthosting.co.za>
Message-ID: <1416758601.9.0.720941508384.issue22925@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, but we don't backport new features to 2.7 unless they are related to PEP 434 and PEP 466. Please send your patch to https://bitbucket.org/ncoghlan/contextlib2

----------
nosy: +berker.peksag
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22925>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:03:54 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 23 Nov 2014 16:03:54 +0000
Subject: [issue22925] Backporting suppress context manager to 2.7
In-Reply-To: <1416757817.56.0.153442346053.issue22925@psf.upfronthosting.co.za>
Message-ID: <1416758634.47.0.184215004919.issue22925@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib) -Build

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22925>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:09:22 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Nov 2014 16:09:22 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1416758962.33.0.93652294274.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Here's the latest patch.  Thoughts?

----------
keywords: +patch
stage: resolved -> patch review
Added file: http://bugs.python.org/file37254/issue22780.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22780>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:27:17 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Nov 2014 16:27:17 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416760037.22.0.0237659306262.issue22915@psf.upfronthosting.co.za>


R. David Murray added the comment:

Serhiy's patch looks correct to me.  Given that if the source doesn't have a name attribute it is simply not set in the existing code, this change should be "safe" (backward compatible).

Elsewhere the possibility was raised of converting the int to a string (<fdopen: N>), but that issue is a more global one and would apply at the io module level...and if implemented this fix would automatically take advantage of it.

So I think this should be committed.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:34:14 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Nov 2014 16:34:14 +0000
Subject: [issue22925] Backporting suppress context manager to 2.7
In-Reply-To: <1416757817.56.0.153442346053.issue22925@psf.upfronthosting.co.za>
Message-ID: <1416760454.96.0.728133998661.issue22925@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: wont fix -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22925>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:38:14 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2014 16:38:14 +0000
Subject: [issue22926] asyncio:
Message-ID: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The call_soon(), call_later() and call_at() methods of asyncio event loops should raise an exception in debug code when they are not called from the right thread.

Currently, BaseEventLoop._assert_is_current_event_loop() does nothing if the event loop policy has no event loop for the current thread, when get_event_loop() raises an AssertionError.

----------
components: asyncio
messages: 231569
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio:
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22926>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:39:17 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 23 Nov 2014 16:39:17 +0000
Subject: [issue22926] asyncio: raise an exception when called from the wrong
 thread
In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za>
Message-ID: <1416760757.38.0.86350212628.issue22926@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: asyncio: -> asyncio: raise an exception when called from the wrong thread

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22926>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:43:33 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Nov 2014 16:43:33 +0000
Subject: [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <1416761013.82.0.538173931178.issue20467@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thoughts?

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file37255/issue20467.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20467>
_______________________________________

From report at bugs.python.org  Sun Nov 23 17:57:49 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Nov 2014 16:57:49 +0000
Subject: [issue22918] Doc for __iter__ makes inexact comment about
 dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416761869.62.0.057149085704.issue22918@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think the first half of the sentence is enough: ?For mappings, it should iterate over the keys of the container.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22918>
_______________________________________

From report at bugs.python.org  Sun Nov 23 18:35:31 2014
From: report at bugs.python.org (Jocelyn)
Date: Sun, 23 Nov 2014 17:35:31 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1416764131.8.0.78460832027.issue22915@psf.upfronthosting.co.za>


Jocelyn added the comment:

The only explicit documentation I found on SystemId is from the java specification (it is my understanding that python sax implementation is adapted from Java one):
http://www.saxproject.org/apidoc/org/xml/sax/InputSource.html#setSystemId%28java.lang.String%29

The documentation says that "The system identifier is optional if there is a byte stream or a character stream".

So, I agree that Serhiy's patch looks correct.

Note that I'm not sure that my testcase with a subprocess is covered by Serhiy's tests, as these tests call parser() with a file object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Sun Nov 23 18:44:03 2014
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 23 Nov 2014 17:44:03 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416764643.18.0.327334006704.issue22919@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sun Nov 23 18:46:30 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Nov 2014 17:46:30 +0000
Subject: [issue22366] urllib.request.urlopen should take a "context"
 (SSLContext) argument
In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za>
Message-ID: <20141123174627.126766.77744@psf.io>


Roundup Robot added the comment:

New changeset 1882157b298a by Benjamin Peterson in branch '2.7':
allow passing cert/ssl information to urllib2.urlopen and httplib.HTTPSConnection
https://hg.python.org/cpython/rev/1882157b298a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22366>
_______________________________________

From report at bugs.python.org  Sun Nov 23 18:46:30 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Nov 2014 17:46:30 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
 checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <20141123174627.126766.14569@psf.io>


Roundup Robot added the comment:

New changeset 1882157b298a by Benjamin Peterson in branch '2.7':
allow passing cert/ssl information to urllib2.urlopen and httplib.HTTPSConnection
https://hg.python.org/cpython/rev/1882157b298a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Sun Nov 23 19:55:09 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 23 Nov 2014 18:55:09 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416768909.04.0.854225743039.issue22921@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I tested this patch on Python 3.5 compiled on CentOS 5.11 which does not have SNI enabled. The end result is that you can use server_hostname even when SNI isn't there to enable the SSL certificate checks. Of course the check will fail if the host your connecting to requires SNI to serve the expected certificate, but that's no different than it is today.

The docs still need updated, I can do that a little bit later today, but figured I'd let people review this since it's done and working other than the docs.

The basic gist of the patch is that we stash the hostname and use it for the validation checks, but we don't send it deeper into the stack if SNI is not available.

----------
keywords: +patch
Added file: http://bugs.python.org/file37256/check-hostname-no-sni.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 21:02:52 2014
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 23 Nov 2014 20:02:52 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416772972.65.0.679426123222.issue22921@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks a lot, Donald!

Back then I didn't pursue the point because I wasn't sure about possible security implications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 21:06:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 20:06:59 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1416773219.69.0.00247799566968.issue11145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is new patch. It first split string on areas: numnondigits (sign+"0x" if F_ALT is not set), skipped ("0x" if F_ALT is set), numdigits and optional "L" suffix, and then construct new string either in-place (if the string is not shared and result fits in original string) or in new string. It uses not more allocations than current code and should not add overhead for common cases.

----------
Added file: http://bugs.python.org/file37257/issue11145_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11145>
_______________________________________

From report at bugs.python.org  Sun Nov 23 21:46:24 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 23 Nov 2014 20:46:24 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416775584.23.0.662361528971.issue22921@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Added docs.

----------
Added file: http://bugs.python.org/file37258/check-hostname-no-sni-with-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:32:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Nov 2014 21:32:37 +0000
Subject: [issue22079] Ensure in PyType_Ready() that base class of static type
 is static
In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>
Message-ID: <1416778357.13.0.62745248584.issue22079@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22079>
_______________________________________

From report at bugs.python.org  Sun Nov 23 22:36:35 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 23 Nov 2014 21:36:35 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416778595.8.0.346437598573.issue22921@psf.upfronthosting.co.za>


Donald Stufft added the comment:

A new patch that achieves the same thing in a simpler way at benjamin's suggestion.

----------
Added file: http://bugs.python.org/file37259/check-hostname-no-sni-with-docs-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Sun Nov 23 23:48:28 2014
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 23 Nov 2014 22:48:28 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416782908.44.0.214983181363.issue22921@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Uploaded a third patch, this is the same technique as in the -2 patch, except it fixes a missed spot in Lib/ssl.py where I needed a better error message.

Additionally this goes through and unskips all of the tests that were marked as depending on HAS_SNI when what they really depended on was the ability to set SSLContext().check_hostname = True.

This also fixes a number of tests that are currently failing whenever HAS_SNI = False that started to fail as fallout of PEP 476.

----------
Added file: http://bugs.python.org/file37260/check-hostname-no-sni-with-docs-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:06:56 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 23 Nov 2014 23:06:56 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <20141123230653.69781.21220@psf.io>


Roundup Robot added the comment:

New changeset f2d4beb90a5b by Benjamin Peterson in branch '3.4':
don't require OpenSSL SNI to pass hostname to ssl functions (#22921)
https://hg.python.org/cpython/rev/f2d4beb90a5b

New changeset 24dfe7310cc1 by Benjamin Peterson in branch 'default':
merge 3.4 (#22921)
https://hg.python.org/cpython/rev/24dfe7310cc1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Mon Nov 24 00:30:09 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 23 Nov 2014 23:30:09 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1416785409.69.0.818508838936.issue22417@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Attached patch backports this to 2.7.

----------
Added file: http://bugs.python.org/file37261/issue22417.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22417>
_______________________________________

From report at bugs.python.org  Mon Nov 24 01:48:14 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 24 Nov 2014 00:48:14 +0000
Subject: [issue20530] Change the text signature format (again) to be more
 robust
In-Reply-To: <1391695750.05.0.146053236138.issue20530@psf.upfronthosting.co.za>
Message-ID: <1416790094.34.0.757029082611.issue20530@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Preparing a presentation about Python Magic methods I found something weird: (Python 3.4)

"""
>>> help(int.__lt__)
Help on wrapper_descriptor:

__lt__(self, value, /)  <- THIS!!
    Return self<value.
"""

I am amused about the "/)" suffix in the signature. It happens to all magic methods.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20530>
_______________________________________

From report at bugs.python.org  Mon Nov 24 02:36:43 2014
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 24 Nov 2014 01:36:43 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <1416793003.13.0.123131516151.issue22921@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Added a patch for Python 2.7

----------
Added file: http://bugs.python.org/file37262/check-hostname-no-sni-with-docs-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:13:49 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 02:13:49 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <20141124021345.55115.3370@psf.io>


Roundup Robot added the comment:

New changeset ce4073afd992 by Benjamin Peterson in branch '2.7':
allow hostname to be passed to SSLContext even if OpenSSL doesn't support SNI (closes #22921)
https://hg.python.org/cpython/rev/ce4073afd992

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:17:25 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 02:17:25 +0000
Subject: [issue22921] SSLContext's check_hostname needlessly intertwined with
 SNI
In-Reply-To: <1416720465.5.0.373361245299.issue22921@psf.upfronthosting.co.za>
Message-ID: <20141124021722.116310.29411@psf.io>


Roundup Robot added the comment:

New changeset 40f9e91f3626 by Benjamin Peterson in branch '2.7':
add NEWS note for #22921
https://hg.python.org/cpython/rev/40f9e91f3626

New changeset 060fd5d09063 by Benjamin Peterson in branch '3.4':
add NEWS note for #22921
https://hg.python.org/cpython/rev/060fd5d09063

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22921>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:26:56 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 24 Nov 2014 02:26:56 +0000
Subject: [issue22927] Expose an SSLContext parameter on urllib APIs
Message-ID: <1416796016.4.0.331627129896.issue22927@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

With the pep476 backport, we need a way to pass a context argument to urrlib

----------
components: Library (Lib)
messages: 231588
nosy: alex, benjamin.peterson, dstufft
priority: normal
severity: normal
status: open
title: Expose an SSLContext parameter on urllib APIs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22927>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:34:30 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 24 Nov 2014 02:34:30 +0000
Subject: [issue22927] Expose an SSLContext parameter on urllib APIs
In-Reply-To: <1416796016.4.0.331627129896.issue22927@psf.upfronthosting.co.za>
Message-ID: <1416796470.22.0.393183780363.issue22927@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file37263/issue22927.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22927>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:38:30 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 02:38:30 +0000
Subject: [issue22788] allow logging.handlers.HTTPHandler to take an SSLContext
In-Reply-To: <1415040567.63.0.29957702634.issue22788@psf.upfronthosting.co.za>
Message-ID: <20141124023828.126786.89689@psf.io>


Roundup Robot added the comment:

New changeset 5864ec6ba484 by Benjamin Peterson in branch '3.4':
add context parameter to HTTPHandler (closes #22788)
https://hg.python.org/cpython/rev/5864ec6ba484

New changeset ec4d19736b15 by Benjamin Peterson in branch 'default':
merge 3.4 (#22788)
https://hg.python.org/cpython/rev/ec4d19736b15

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22788>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:50:25 2014
From: report at bugs.python.org (Guido Vranken)
Date: Mon, 24 Nov 2014 02:50:25 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
Message-ID: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>


New submission from Guido Vranken:

Proof of concept:

# Script for Python 2
import urllib2
opener = urllib2.build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0' + chr(0x0A) + "Location: header injection")]
response = opener.open("http://localhost:9999")

# Data sent is:
"""
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost:9999
Connection: close
User-Agent: Mozilla/5.0
Location: header injection

"""

# End of script

# Python 3
from urllib.request import urlopen, build_opener
opener = build_opener()
opener.addheaders = [('User-agent', 'Mozilla/5.0' + chr(0x0A) + "Location: header injection")]
opener.open("http://localhost:9999")

# Data sent is:
"""
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost:9999
Connection: close
User-Agent: Mozilla/5.0
Location: header injection

"""

# End of script

It is the responsibility of the developer leveraging Python and its HTTP client libraries to ensure that their (web) application acts in accordance to official HTTP specifications and that no threats to security will arise from their code.
However, newlines inside headers are arguably a special case of breaking the conformity with RFC's in regard to the allowed character set. No illegal character used inside a HTTP header is likely to have a compromising side effect on back-end clients and servers and the integrity of their communication, as a result of the leniency of most web servers. However, a newline character (0x0A) embedded in a HTTP header invariably has the semantic consequence of denoting the start of an additional header line. To put it differently, not sanitizing headers in complete accordance to RFC's could be seen as as virtue in that it gives the programmer a maximum amount of freedom, without having to trade it for any likely or severe security ramifications, so that they may use illegal characters in testing environments and environments that are outlined by an expliticly less strict interpretation of the HTTP protocol. Newlines are special in that they enable anyone who is able to influence the header content, to, in effect, perform additional invocations to add_header().

In issue 17322 ( http://bugs.python.org/issue17322 ) there is some discussion as to the general compliance to RFC's by the HTTP client libraries. I'd like to opt to begin with prohibiting newline characters to be present in HTTP headers. Although this issue is not a "hard vulnerability" such as a buffer overflow, it does translate to a potentially equal level of severity when considered from the perspective of a web-enabled application, for which purpose the HTTP libraries are typically used for. Lack of input validation on the application developer's end will faciliate header injections, for example if user-supplied data will end up as cookie content verbatim.
Adding this proposed additional layer of validation inside Python minimizes the likelihood of a successful header injection while functionality is not notably affected.

I'm inclined to add this validation to putheader() in the 'http' module rather than in urllib, as this will secure all invocations to 'http' regardless of intermediate libraries such as urllib.

Included is a patch for the latest checkout of the default branch that will cause CannotSendHeader() to be raised if a newline character is detected in either a header name or its value. Aside from detecting "\n", it also breaks on "\r" as their respective implications can be similar. Feel free to adjust, rewrite and transpose this to other branches where you feel this is appropriate.


Guido Vranken
Intelworks

----------
components: Library (Lib)
files: disable_http_header_injection.patch
keywords: patch
messages: 231590
nosy: Guido
priority: normal
severity: normal
status: open
title: HTTP header injection in urrlib2/urllib/httplib/http.client
type: security
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/file37264/disable_http_header_injection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Mon Nov 24 03:55:42 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 02:55:42 +0000
Subject: [issue22927] Expose an SSLContext parameter on urllib APIs
In-Reply-To: <1416796016.4.0.331627129896.issue22927@psf.upfronthosting.co.za>
Message-ID: <20141124025537.126790.75218@psf.io>


Roundup Robot added the comment:

New changeset c84f36a5f556 by Benjamin Peterson in branch '2.7':
give urllib.urlopen a context parameter (closes #22927)
https://hg.python.org/cpython/rev/c84f36a5f556

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22927>
_______________________________________

From report at bugs.python.org  Mon Nov 24 04:02:23 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 03:02:23 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <20141124030214.116310.93036@psf.io>


Roundup Robot added the comment:

New changeset fb83916c3ea1 by Benjamin Peterson in branch '2.7':
pep 476: verify certificates by default (#22417)
https://hg.python.org/cpython/rev/fb83916c3ea1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22417>
_______________________________________

From report at bugs.python.org  Mon Nov 24 04:22:15 2014
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Nov 2014 03:22:15 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416799335.98.0.686603952864.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

Added some fixes to the python3.dll build (and xxlimited test project) which I noticed thanks to Antoine's feedback.

----------
Added file: http://bugs.python.org/file37265/python3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Mon Nov 24 05:58:27 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2014 04:58:27 +0000
Subject: [issue22417] PEP 476: verify HTTPS certificates by default
In-Reply-To: <1410784469.95.0.475937020841.issue22417@psf.upfronthosting.co.za>
Message-ID: <1416805107.91.0.631366473621.issue22417@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22417>
_______________________________________

From report at bugs.python.org  Mon Nov 24 05:58:39 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Nov 2014 04:58:39 +0000
Subject: [issue22366] urllib.request.urlopen should take a "context"
 (SSLContext) argument
In-Reply-To: <1410198352.63.0.605714024836.issue22366@psf.upfronthosting.co.za>
Message-ID: <1416805119.69.0.594276557684.issue22366@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22366>
_______________________________________

From report at bugs.python.org  Mon Nov 24 08:12:44 2014
From: report at bugs.python.org (Bob Chen)
Date: Mon, 24 Nov 2014 07:12:44 +0000
Subject: [issue22231] httplib: unicode url will cause an ascii codec error
 when combined with a utf-8 string header
In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za>
Message-ID: <1416813164.55.0.641454759753.issue22231@psf.upfronthosting.co.za>


Bob Chen added the comment:

Someone come and pick up this? It has been a long time...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22231>
_______________________________________

From report at bugs.python.org  Mon Nov 24 08:13:51 2014
From: report at bugs.python.org (Bob Chen)
Date: Mon, 24 Nov 2014 07:13:51 +0000
Subject: [issue22231] httplib: unicode url will cause an ascii codec error
 when combined with a utf-8 string header
In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za>
Message-ID: <1416813231.17.0.483808660142.issue22231@psf.upfronthosting.co.za>


Changes by Bob Chen <175818323 at qq.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22231>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:00:20 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Nov 2014 10:00:20 +0000
Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's
 close() fails
In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>
Message-ID: <1416823220.91.0.206671141681.issue21802@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Why don't you reuse the API from issue21715?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21802>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:39:37 2014
From: report at bugs.python.org (era)
Date: Mon, 24 Nov 2014 10:39:37 +0000
Subject: [issue22929] cp874 encoding almost empty
Message-ID: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>


New submission from era:

I created a simple script to map character codes in the 8bit range to Unicode for simple lookup:

https://github.com/tripleee/8bit

In the generated output, on Python 2.6.6 (but corroborated on Python 2.7.6), almost all character codes come up as "undefined" in CP874.

According to http://en.wikipedia.org/wiki/ISO/IEC_8859-11, CP874 should be a superset of ISO-8859-11, with a few character codes *added* in the ISO control range.

----------
components: Unicode
messages: 231596
nosy: era, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: cp874 encoding almost empty
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22929>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:43:24 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Nov 2014 10:43:24 +0000
Subject: [issue22929] cp874 encoding almost empty
In-Reply-To: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>
Message-ID: <1416825804.94.0.338099966943.issue22929@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22929>
_______________________________________

From report at bugs.python.org  Mon Nov 24 11:49:19 2014
From: report at bugs.python.org (Dmitry Shachnev)
Date: Mon, 24 Nov 2014 10:49:19 +0000
Subject: [issue22930] Value of time.timezone is sometimes wrong
Message-ID: <1416826159.48.0.941875897993.issue22930@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

Here, on Linux, I get:

$ python3 -c "import time; print(time.timezone)"
-14400

? which means I am in UTC+4. However, Russia recently (in October) switched time, and moved from UTC+4 to UTC+3 timezone (my tzdata is up-to-date), so this reported value is wrong.

The relevant code in timemodule.c looks like (simplified):

  #define YEAR ((time_t)((365 * 24 + 6) * 3600))
  time_t t = (time((time_t *)0) / YEAR) * YEAR;
  struct tm *p = localtime(&t);
  janzone = -p->tm_gmtoff;
  PyModule_AddIntConstant(m, "timezone", janzone);

The value of t is the *January 1st* of current year, i.e. 2014-01-01 currently. But the timezone of a country in the year beginning may be different from its timezone in the year end, which is the case for me.

This bug will be relevant for Russia until the end of 2014, but may be still relevant for other countries that wish to change their timezone.

----------
components: Extension Modules
messages: 231597
nosy: mitya57
priority: normal
severity: normal
status: open
title: Value of time.timezone is sometimes wrong
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22930>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:02:43 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 24 Nov 2014 11:02:43 +0000
Subject: [issue22929] cp874 encoding almost empty
In-Reply-To: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>
Message-ID: <1416826963.98.0.172753111706.issue22929@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I'm not sure I understand the bug report. What's the problem ? :-)

The codec is a charmap codec generated from the file MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT (http://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT)

This mapping does have quite a few undefined characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22929>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:09:08 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 24 Nov 2014 11:09:08 +0000
Subject: [issue22929] cp874 encoding almost empty
In-Reply-To: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>
Message-ID: <1416827348.84.0.681244864612.issue22929@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

BTW: The table on the wiki page shows the same undefined chars.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22929>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:47:09 2014
From: report at bugs.python.org (era)
Date: Mon, 24 Nov 2014 11:47:09 +0000
Subject: [issue22929] cp874 encoding almost empty
In-Reply-To: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>
Message-ID: <1416829629.77.0.948174803772.issue22929@psf.upfronthosting.co.za>


era added the comment:

My apologies -- I already attemptd to close this as a mistake on my part, but apparently, that failed too.  )-:  Sorry.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22929>
_______________________________________

From report at bugs.python.org  Mon Nov 24 12:49:45 2014
From: report at bugs.python.org (Martin Dengler)
Date: Mon, 24 Nov 2014 11:49:45 +0000
Subject: [issue20954] Bug in subprocess._args_from_interpreter_flags causes
 MemoryError
In-Reply-To: <1395049138.68.0.283816495419.issue20954@psf.upfronthosting.co.za>
Message-ID: <1416829785.88.0.418341980208.issue20954@psf.upfronthosting.co.za>


Martin Dengler added the comment:

FWIW, I've been using a this patch for 2.7.5 in a production setting for a month now and have had no problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20954>
_______________________________________

From report at bugs.python.org  Mon Nov 24 15:38:21 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 14:38:21 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1416839901.55.0.969035763203.issue22928@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +orsenthil, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Mon Nov 24 15:39:36 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 14:39:36 +0000
Subject: [issue22929] cp874 encoding almost empty
In-Reply-To: <1416825577.9.0.423392091227.issue22929@psf.upfronthosting.co.za>
Message-ID: <1416839976.87.0.723067789283.issue22929@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22929>
_______________________________________

From report at bugs.python.org  Mon Nov 24 15:41:11 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 14:41:11 +0000
Subject: [issue22930] Value of time.timezone is sometimes wrong
In-Reply-To: <1416826159.48.0.941875897993.issue22930@psf.upfronthosting.co.za>
Message-ID: <1416840071.15.0.401790916427.issue22930@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a duplicate of issue 22752.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> incorrect time.timezone value

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22930>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:02:46 2014
From: report at bugs.python.org (Dmitry Shachnev)
Date: Mon, 24 Nov 2014 15:02:46 +0000
Subject: [issue22752] incorrect time.timezone value
In-Reply-To: <1414506398.58.0.3585243804.issue22752@psf.upfronthosting.co.za>
Message-ID: <1416841366.3.0.729970208703.issue22752@psf.upfronthosting.co.za>


Dmitry Shachnev added the comment:

Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call?

This bug is not just about returning the wrong timezone. Because of it, the full time string produced with Python may be wrong. For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently.

----------
nosy: +mitya57
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22752>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:25:45 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 24 Nov 2014 15:25:45 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416842745.28.0.24305174308.issue22919@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Another round of review posted on Rietveld.  I'll try to get the VS2015 preview downloaded today and give some more feedback after using it.

Just one inconsequential note on python3.diff: the 'lib' command in python3dll.vcxproj could use a '/nologo' flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Mon Nov 24 16:43:24 2014
From: report at bugs.python.org (Waldemar Parzonka)
Date: Mon, 24 Nov 2014 15:43:24 +0000
Subject: [issue22931] cookies with square brackets in value
Message-ID: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>


New submission from Waldemar Parzonka:

There seems to be weird behaviour in BaseCookie.load() when cookie that has '[' in one of the values is being loaded.

There is no exception being thrown as the key is still legal but the cookie is not getting loaded properly and everything that was after the '[' valued cookie is being silently ignored.

>>> dd = SimpleCookie()
>>> dd
<SimpleCookie: >
>>> s = 'a=b; c=[; d=r; f=h'
>>> dd.load(s)
>>> dd
<SimpleCookie: a='b'>
>>>

----------
components: Library (Lib)
messages: 231605
nosy: Waldemar.Parzonka
priority: normal
severity: normal
status: open
title: cookies with square brackets in value
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:07:00 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 24 Nov 2014 16:07:00 +0000
Subject: [issue1962] ctypes feature request: Automatic type conversion of
 input arguments to C functions
In-Reply-To: <1201597182.13.0.442457985171.issue1962@psf.upfronthosting.co.za>
Message-ID: <1416845220.23.0.677138274133.issue1962@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1962>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:08:14 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2014 16:08:14 +0000
Subject: [issue22752] incorrect time.timezone value
In-Reply-To: <1414506398.58.0.3585243804.issue22752@psf.upfronthosting.co.za>
Message-ID: <1416845294.22.0.671624967248.issue22752@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Is it possible to set timezone based on localtime(current_time) where current_time is the result of time() call?

No. time.timezone is a constant it cannot change with time.  This is a limitation of the POSIX and C standards on which time module is based.

> For example, my mail sending program uses `email.utils.formatdate(localtime=True)', and that is returning a time one hour in the past currently.

I thought email.utils.formatdate was fixed in 3.x series.  Can you report this as a separate issue?

----------
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22752>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:12:42 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 16:12:42 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1416845562.7.0.866620410386.issue22931@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:16:58 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 24 Nov 2014 16:16:58 +0000
Subject: [issue7255] "Default" word boundaries for Unicode data?
In-Reply-To: <1257222123.85.0.715983159645.issue7255@psf.upfronthosting.co.za>
Message-ID: <1416845818.52.0.788837253509.issue7255@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Closing this old issue: either use the 'regex' module, or wait for issue2636.

----------
nosy: +amaury.forgeotdarc
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7255>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:17:20 2014
From: report at bugs.python.org (Dmitry Shachnev)
Date: Mon, 24 Nov 2014 16:17:20 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
Message-ID: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>


New submission from Dmitry Shachnev:

The value of time.timezone may be wrong sometimes (see http://bugs.python.org/issue22752), so I think the email library should not use it:

$ python3 -c "from email.utils import formatdate; print(formatdate(localtime=True))"
Mon, 24 Nov 2014 19:16:32 +0400
$ date -R
Mon, 24 Nov 2014 19:16:32 +0300

Using something from datetime module may be a better solution.

----------
components: Library (Lib)
messages: 231608
nosy: belopolsky, mitya57
priority: normal
severity: normal
status: open
title: email.utils.formatdate uses unreliable time.timezone constant
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:20:35 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2014 16:20:35 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416846035.04.0.821064683576.issue22932@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

See also issue 665194.

----------
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:28:33 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2014 16:28:33 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416846513.58.0.614056503119.issue22932@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I was able to reproduce the problem on a Mac as follows:

$ TZ=Europe/Moscow date "+%c %z"
Mon Nov 24 19:27:51 2014 +0300
$ TZ=Europe/Moscow python3 -c "from email.utils import formatdate; print(formatdate(localtime=True))"
Mon, 24 Nov 2014 19:28:03 +0400

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:31:15 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2014 16:31:15 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416846675.93.0.0778503220566.issue22932@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

"Using something from datetime module" works as expected:

$ TZ=Europe/Moscow python3 -c "from datetime import datetime, timezone; print(datetime.now(timezone.utc).astimezone())"
2014-11-24 19:30:27.141542+03:00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 17:32:33 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2014 16:32:33 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416846753.44.0.472984143758.issue22932@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:10:36 2014
From: report at bugs.python.org (newbie)
Date: Mon, 24 Nov 2014 17:10:36 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
Message-ID: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>


New submission from newbie:

First sentence of 3rd paragraph of 10.10. "shutil" documentation for shutil.move command, "The destination directory must not already exist", is misleading and contradicts other information in the entry.  I took it to mean that if dst did not exist, python would create it as a directory.  What actually happens is that python renames src to dst. In my test, I was moving several files to a new directory, and the result was a file with the pathname dst and contents matching the last move command, consistent with the behavior described in the rest of the paragraph and the following one. When I changed the code to create the directory with os.mkdirs before calling shutil.move, it worked as I wanted, so obviously there's nothing wrong with the destination directory already existing. The preceding paragraph implies this with its description of behavior when dst refers to a directory.  I suggest removing this sentence, and maybe adding some text indicating what to do if you want to move a file to a new directory.
I was using Python 2.7.5 on Windows, and branch 2.7.8 of the documentation (there does not appear to be a branch 2.7.5 available.)

----------
assignee: docs at python
components: Documentation
messages: 231612
nosy: docs at python, newbie
priority: normal
severity: normal
status: open
title: Misleading sentence in doc for shutil.move
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22933>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:17:13 2014
From: report at bugs.python.org (Dmitry Shachnev)
Date: Mon, 24 Nov 2014 17:17:13 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416849433.66.0.767616732902.issue22932@psf.upfronthosting.co.za>


Dmitry Shachnev added the comment:

This patch fixes the issue for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file37266/issue22932.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:30:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 17:30:32 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416850232.59.0.0514978182088.issue22932@psf.upfronthosting.co.za>


R. David Murray added the comment:

email.utils.format_datetime uses datetime.  formatdate wasn't touched, for backward compatibility reasons.  If it has an actual bug we can fix it.

If it can be converted to use datetime without sacrificing backward compatibility, that's also fine with me.

Frankly I don't know enough at the moment to know if the proposed patch is correct.  Alexander?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:30:45 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 17:30:45 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416850245.13.0.380025364967.issue22932@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: needs patch -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 18:43:30 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 24 Nov 2014 17:43:30 +0000
Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone
 constant
In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za>
Message-ID: <1416851010.55.0.922663960699.issue22932@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

The proposed patch will not work on platforms that don't support tm_gmtoff.  A proper fix may look like this:

dt = datetime.fromtimestamp(timeval, timezone.utc)
if localtime:
  dt = dt.astimezone()
return format_datetime(dt, usegmt)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22932>
_______________________________________

From report at bugs.python.org  Mon Nov 24 19:32:31 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 18:32:31 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1416853951.96.0.685665226746.issue22933@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think you are correct that that sentence should just be deleted.  The preceding sentence should start "If the destination is an existing directory..."

I also wonder if shutil should be changed to use os.replace, but that is a separate issue.

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22933>
_______________________________________

From report at bugs.python.org  Mon Nov 24 20:48:32 2014
From: report at bugs.python.org (joseph)
Date: Mon, 24 Nov 2014 19:48:32 +0000
Subject: [issue22934] Python/importlib.h is now generated by
 Programs/_freeze_importlib.c, change comment
Message-ID: <1416858512.31.0.184261411621.issue22934@psf.upfronthosting.co.za>


New submission from joseph:

Since the changeset 91853:88a532a31eb3 _freeze_importlib.c resides in the Programs dir. The header comment of Python/importlib.h should be changed to reflect this.

----------
components: Build
files: freeze_importlib_comment.patch
keywords: patch
messages: 231617
nosy: crozzy
priority: normal
severity: normal
status: open
title: Python/importlib.h is now generated by Programs/_freeze_importlib.c, change comment
versions: Python 3.5
Added file: http://bugs.python.org/file37267/freeze_importlib_comment.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22934>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:25:59 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 21:25:59 +0000
Subject: [issue22934] Python/importlib.h is now generated by
 Programs/_freeze_importlib.c, change comment
In-Reply-To: <1416858512.31.0.184261411621.issue22934@psf.upfronthosting.co.za>
Message-ID: <20141124212554.126764.76564@psf.io>


Roundup Robot added the comment:

New changeset 0ddcc455e001 by Berker Peksag in branch 'default':
Issue #22934: Update the comment to mention Programs/_freeze_importlib.c.
https://hg.python.org/cpython/rev/0ddcc455e001

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22934>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:27:02 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 24 Nov 2014 21:27:02 +0000
Subject: [issue22934] Python/importlib.h is now generated by
 Programs/_freeze_importlib.c, change comment
In-Reply-To: <1416858512.31.0.184261411621.issue22934@psf.upfronthosting.co.za>
Message-ID: <1416864422.59.0.350610977919.issue22934@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Joseph.

----------
assignee:  -> berker.peksag
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22934>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:46:56 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 21:46:56 +0000
Subject: [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <20141124214651.126764.4523@psf.io>


Roundup Robot added the comment:

New changeset 268ceaa78cf9 by Berker Peksag in branch '3.4':
Issue #20351: Add examples for csv.DictReader and csv.DictWriter.
https://hg.python.org/cpython/rev/268ceaa78cf9

New changeset c2b36196b7f5 by Berker Peksag in branch 'default':
Issue #20351: Add examples for csv.DictReader and csv.DictWriter.
https://hg.python.org/cpython/rev/c2b36196b7f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20351>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:50:35 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 21:50:35 +0000
Subject: [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <20141124215032.126778.75897@psf.io>


Roundup Robot added the comment:

New changeset e504c3bc6897 by Berker Peksag in branch '2.7':
Issue #20351: Add examples for csv.DictReader and csv.DictWriter.
https://hg.python.org/cpython/rev/e504c3bc6897

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20351>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:51:50 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 24 Nov 2014 21:51:50 +0000
Subject: [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1416865910.28.0.336071442123.issue20351@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Charles-Axel.

----------
assignee: rhettinger -> berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20351>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:56:56 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 21:56:56 +0000
Subject: [issue16056] shadowed test names in std lib regression tests
In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za>
Message-ID: <20141124215649.116320.60140@psf.io>


Roundup Robot added the comment:

New changeset fd786e4e331c by Berker Peksag in branch '2.7':
Issue #16056: Rename test methods to avoid conflict.
https://hg.python.org/cpython/rev/fd786e4e331c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16056>
_______________________________________

From report at bugs.python.org  Mon Nov 24 22:57:44 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 24 Nov 2014 21:57:44 +0000
Subject: [issue16056] shadowed test names in std lib regression tests
In-Reply-To: <1348691657.67.0.693161474206.issue16056@psf.upfronthosting.co.za>
Message-ID: <1416866264.61.0.806269249232.issue16056@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee:  -> berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16056>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:14:20 2014
From: report at bugs.python.org (Kurt Roeckx)
Date: Mon, 24 Nov 2014 22:14:20 +0000
Subject: [issue22935] Disabling SSLv3 support
Message-ID: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>


New submission from Kurt Roeckx:

Hi,

The attached patch makes python work when openssl doesn't have SSLv3 support.  It also updates the documentation, which has already improved a lot since my original patch.

The current upstream openssl when compiled with no-ssl2 it defines OPENSSL_NO_SSL2, drops the SSLv2_* method and drops support for SSLv2 in the SSLv23_* methods.  When build with no-ssl3 it defines OPENSSL_NO_SSL3 and currently just drops supports for SSLv3 in the SSLv23_method, it does not yet drop the SSLv3_* methods.  It's still being argued whether no-ssl3 should drop those symbols or that a new option will be used instead.

So that means that with OPENSSL_NO_SSL3 defined it could be that the SSLv3_* methods still exist and that you can create a socket that only support SSLv3.

I made the SSLv3 methods go away in python if OPENSSL_NO_SSL3 is defined.  This at least makes things easier for the test suite so that you know you can test a combination like v3 with v23 or not.

This patch is for 2.7.  Please let me know if you need a patch for a different version.

----------
files: python2.7-nossl3.patch
keywords: patch
messages: 231624
nosy: kroeckx
priority: normal
severity: normal
status: open
title: Disabling SSLv3 support
Added file: http://bugs.python.org/file37268/python2.7-nossl3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:15:46 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 24 Nov 2014 22:15:46 +0000
Subject: [issue22935] Disabling SSLv3 support
In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>
Message-ID: <1416867346.99.0.0754320897219.issue22935@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

FWIW, Debian expiremental appears to be using a different #define for this. Here's how we handled it in pyca/cryptography: https://github.com/pyca/cryptography/commit/04a3f1f2c4086c0d7162b6dd79b6332d9115b2c0

----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:20:47 2014
From: report at bugs.python.org (Kurt Roeckx)
Date: Mon, 24 Nov 2014 22:20:47 +0000
Subject: [issue22935] Disabling SSLv3 support
In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>
Message-ID: <1416867647.68.0.637039488345.issue22935@psf.upfronthosting.co.za>


Kurt Roeckx added the comment:

I know what I uploaded to Debian experimental.  And I can't promise that I'll keep that define.  I suggest you assume that NO_SSL3 will disable both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:21:37 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 24 Nov 2014 22:21:37 +0000
Subject: [issue22935] Disabling SSLv3 support
In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>
Message-ID: <1416867697.11.0.489237708868.issue22935@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Good to know, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Mon Nov 24 23:37:25 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Nov 2014 22:37:25 +0000
Subject: [issue22935] Disabling SSLv3 support
In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>
Message-ID: <1416868645.51.0.544027678922.issue22935@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type:  -> compile error
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:05:27 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Nov 2014 02:05:27 +0000
Subject: [issue22936] traceback module has no way to show locals
Message-ID: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals.

To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib).

----------
components: Library (Lib)
messages: 231628
nosy: rbcollins
priority: normal
severity: normal
status: open
title: traceback module has no way to show locals
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:06:22 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Nov 2014 02:06:22 +0000
Subject: [issue22937] unittest errors can't show locals
Message-ID: <1416881182.95.0.816242293699.issue22937@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://github.com/testing-cabal/testtools/issues/111 - any code that is data dependent can be hard to diagnose from a backtrace alone. Many unittest and server environments address this by doing custom tracebacks that include locals.

To address this in unittest, we need to add a similar capacity to traceback, and then use it from unittest (as we can't just depend on a module from PyPI in the stdlib). This issue is for the unittest part of it. For the traceback dependency see http://bugs.python.org/issue22936 .

----------
components: Library (Lib)
messages: 231629
nosy: rbcollins
priority: normal
severity: normal
status: open
title: unittest errors can't show locals
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22937>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:06:34 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Nov 2014 02:06:34 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1416881194.83.0.364666086049.issue22936@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Tue Nov 25 03:07:00 2014
From: report at bugs.python.org (Robert Collins)
Date: Tue, 25 Nov 2014 02:07:00 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1416881220.81.0.998119104165.issue22936@psf.upfronthosting.co.za>


Robert Collins added the comment:

See http://bugs.python.org/issue22936 for the unittest aspect of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Tue Nov 25 05:13:56 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 25 Nov 2014 04:13:56 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416888836.08.0.694011175488.issue22919@psf.upfronthosting.co.za>


Zachary Ware added the comment:

After a debug build with VS2015, my biggest concern is this:

  ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj]

There's also a slew of new warnings, mostly C4456 and C4457 with a few C4459s thrown in.  I think we can safely disable those three (which are all about name shadowing), perhaps with a XXX comment alongside to the effect of 'it might be nice to not disable these warnings someday'.

Interestingly, there's also this warning:

  C:\Program Files (x86)\Windows Kits\8.1\Include\um\shlobj.h(1054): warning C4091: 'typedef ': ignored on left of 'tagGPFIDL_FLAGS' when no variable is declared [P:\ath\to\cpython\PCbuild\pylauncher.vcxproj]

And a matching one for pywlauncher.vcxproj.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Tue Nov 25 05:35:15 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 25 Nov 2014 04:35:15 +0000
Subject: [issue22676] _pickle's whichmodule() is slow
In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>
Message-ID: <1416890115.63.0.78553345935.issue22676@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This is still causing a somewhat serious warning on Windows, see [1] for example.  The condition warned about affects every platform.

It took me some time to make sense of that function, but I think I finally understand what's going on.  I think Steve's suggestion of initializing module to Py_None would be fine, or just pass in a known good object like global instead since the 'obj' parameter is only used for error message formatting.  Either way, I think the error check at Modules/_pickle.c:1657 [2] should either use reformat_attribute_error() or do the reformatting itself (to provide a different message) because I don't think the AttributeError message from get_dotted_path would be anywhere close to correct (especially if 'obj' is given as Py_None).

[1] http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8969/steps/compile/logs/stdio
[2] Steve: the 'Comment:' label in the form is a handy link to the devguide section about how magic links work.  In this case, it's filepath.ext:number

----------
nosy: +zach.ware
resolution: fixed -> 
stage: resolved -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 06:46:26 2014
From: report at bugs.python.org (Archana Pandey)
Date: Tue, 25 Nov 2014 05:46:26 +0000
Subject: [issue22938] assignment operator += does not behave same as a = a + b
 for List
Message-ID: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>


New submission from Archana Pandey:

List is mutable with += operator. But the same cannot be achieved when we use arithmatic + and assignment = operator used

Please Find the attached python module

----------
components: Windows
files: Operator_bug_python.py
messages: 231633
nosy: archi-pandey, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: assignment operator += does not behave same as a = a + b for List
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file37269/Operator_bug_python.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22938>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:09:46 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Nov 2014 06:09:46 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416895786.93.0.949421698924.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

> After a debug build with VS2015, my biggest concern is this:
>
>  ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open 
> include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj]

I thought I had a workaround for this, but I'll have to check it out. Oddly enough, all of my builds have been fine (I think I'm mostly doing release builds - does that make a difference?)

> There's also a slew of new warnings, mostly C4456 and C4457 with a 
> few C4459s thrown in.  I think we can safely disable those three 
> (which are all about name shadowing), perhaps with a XXX comment 
> alongside to the effect of 'it might be nice to not disable these 
> warnings someday'.

I'm torn about that. Ideally I'd like to suppress the existing ones and still have new ones appear, but that probably requires going through and fixing them. Maybe leaving the warnings there will encourage someone to do it? :)

> Interestingly, there's also this warning:
>
>   C:\Program Files (x86)\Windows Kits\8.1\Include\um\shlobj.h(1054): 
> warning C4091: 'typedef ': ignored on left of 'tagGPFIDL_FLAGS' when 
> no variable is declared [P:\ath\to\cpython\PCbuild\pylauncher.vcxproj]
>
> And a matching one for pywlauncher.vcxproj.

This is a known issue with the Windows SDK - they need to release a new version to handle the changes in the compiler. It doesn't affect the Python build, though it is currently breaking some of my installer work :( I'm confident it will be fixed soon - they're getting a lot of reports about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:11:21 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Nov 2014 06:11:21 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1416895881.3.0.961081101639.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

Added changes from Zach's last review.

Highlight: I deleted the make_versioninfo project and build step :)

----------
Added file: http://bugs.python.org/file37270/round4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:12:00 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Nov 2014 06:12:00 +0000
Subject: [issue21236] patch to use cabinet.lib instead of fci.lib (fixes build
 with Windows SDK 8.0)
In-Reply-To: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za>
Message-ID: <1416895920.28.0.247680625424.issue21236@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've inadvertently picked this up with my changes for #22919, so it'll get into 3.5 that way.

Do we need to apply this to 3.4 as well? What about 2.7?

----------
assignee:  -> steve.dower
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21236>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:19:44 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Nov 2014 06:19:44 +0000
Subject: [issue22938] assignment operator += does not behave same as a = a + b
 for List
In-Reply-To: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>
Message-ID: <1416896384.11.0.447151378909.issue22938@psf.upfronthosting.co.za>


Steve Dower added the comment:

This is by design. I'm sure if you email python-list then someone there will be able to explain how the difference can help you write clearer code than if they both behaved exactly the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22938>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:20:27 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Nov 2014 06:20:27 +0000
Subject: [issue22938] assignment operator += does not behave same as a = a + b
 for List
In-Reply-To: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>
Message-ID: <1416896427.71.0.987356393688.issue22938@psf.upfronthosting.co.za>


Steve Dower added the comment:

Info about python-list is at https://mail.python.org/mailman/listinfo/python-list

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22938>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:20:41 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 25 Nov 2014 06:20:41 +0000
Subject: [issue21236] patch to use cabinet.lib instead of fci.lib (fixes build
 with Windows SDK 8.0)
In-Reply-To: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za>
Message-ID: <1416896441.67.0.384821257908.issue21236@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Definitely not 2.7, since it's still on VS2008 and would require so many changes for this to matter that it's just not an issue; I'm not sure on 3.4.  Is cabinet.lib available (and have everything we need) for MSVC10 and SDK 7.1 (which are the important targets for 3.4)?

----------
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21236>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:21:31 2014
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Nov 2014 06:21:31 +0000
Subject: [issue22938] assignment operator += does not behave same as a = a + b
 for List
In-Reply-To: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>
Message-ID: <1416896491.52.0.710627954142.issue22938@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22938>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:22:19 2014
From: report at bugs.python.org (Akira Li)
Date: Tue, 25 Nov 2014 06:22:19 +0000
Subject: [issue22752] incorrect time.timezone value
In-Reply-To: <1414506398.58.0.3585243804.issue22752@psf.upfronthosting.co.za>
Message-ID: <1416896539.47.0.68825704159.issue22752@psf.upfronthosting.co.za>


Akira Li added the comment:

C standard delegates to implementations:

  The local time zone and Daylight Saving Time are implementation-defined.

gcc (one of the implementations) says [1]:

  [timezone] contains the difference between UTC and the latest local standard time, in seconds west of UTC. 

Notice the word "latest". To be fair, gcc (the actual implementation) 
uses a weird logic to assign timezone, daylight values in Europe/Moscow 
timezone in 2011-2015.

Python own tests assume that time.timezone reflects the *current* 
(most recent) time http://bugs.python.org/issue22799

C tzname, timezone, daylight are not constants. They may change e.g., see 
http://bugs.python.org/issue22798 (the C code demonstrates that 
tzname changes even for the same local timezone).

POSIX specifies a profile (additional restrictions but no conflict) of C 
standard for the time functions e.g., tzset(), mktime() [2], ctime(), 
localtime() may change tzname, timezone, daylight (but *not* gmtime() or 
asctime()).

To summarize:

- timezone is implementation-defined in C
- gcc (one of implementations) says that timezone corresponds to 
  the latest time (the actual behavior is complicated)
- POSIX says that time functions shall set timezone info i.e., timezone 
  is not a constant (it is obvious due to tzset() existence)
- Python tests assume that timezone corresponds to the current time (not 
  january or july)

I'm not sure what time.timezone behaviour should be:

- leave it as is (unsynchronized with C values and it may be different
  from the current correct value) -- it makes time module unusable in
  some timezones (60% all time, 11% since 2001), some of the time
- use "latest" correct (gmtoff where available) value during importing
  the time module -- it would fix this issue22752
- synchronize with C values -- it improves some things e.g., it may fix
  http://bugs.python.org/issue22426 but it might make the behavior
  more platform dependent (tests needed) and it make things worse in some
  timezones e.g., where dst() != 1 hour (13% all time, 0.9% since 2000)


[1] http://www.gnu.org/software/libc/manual/html_node/Time-Zone-Functions.html

[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22752>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:22:53 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 25 Nov 2014 06:22:53 +0000
Subject: [issue22938] assignment operator += does not behave same as a = a + b
 for List
In-Reply-To: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>
Message-ID: <1416896573.56.0.677186741731.issue22938@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22938>
_______________________________________

From report at bugs.python.org  Tue Nov 25 07:23:15 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 25 Nov 2014 06:23:15 +0000
Subject: [issue22938] assignment operator += does not behave same as a = a + b
 for List
In-Reply-To: <1416894386.29.0.913544398942.issue22938@psf.upfronthosting.co.za>
Message-ID: <1416896595.95.0.280211665457.issue22938@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components:  -Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22938>
_______________________________________

From report at bugs.python.org  Tue Nov 25 08:41:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 07:41:18 +0000
Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's
 close() fails
In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>
Message-ID: <1416901278.26.0.304486586296.issue21802@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because this API was not still committed. Here is a patch which uses it.

----------
Added file: http://bugs.python.org/file37271/bufferedrwpair_close_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21802>
_______________________________________

From report at bugs.python.org  Tue Nov 25 08:50:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 07:50:36 +0000
Subject: [issue22896] Don't use PyObject_As*Buffer() functions
In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za>
Message-ID: <1416901836.93.0.220833740114.issue22896@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which replaces deprecated functions with PyObject_GetBuffer() and like. It also introduce _PyBuffer_Converter for using in PyArgs_Parse* and clinic converter simple_buffer_converter which unlike to Py_buffer_converter ("y*") does not not force C contiguousity (is it correct?).

----------
keywords: +patch
nosy: +larry, pitrou
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37272/buffers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22896>
_______________________________________

From report at bugs.python.org  Tue Nov 25 09:57:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 08:57:51 +0000
Subject: [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416905871.59.0.538406814567.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please look at the patch? I touches only docs and comments.

----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22581>
_______________________________________

From report at bugs.python.org  Tue Nov 25 09:58:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 08:58:59 +0000
Subject: [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416905939.81.0.729315266674.issue22581@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg231643

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22581>
_______________________________________

From report at bugs.python.org  Tue Nov 25 09:59:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 08:59:20 +0000
Subject: [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416905960.15.0.443806831058.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please look at the patch? It touches only docs and comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22581>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:09:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 09:09:40 +0000
Subject: [issue20899] Nested namespace imports do not work inside zip archives
In-Reply-To: <1394656225.26.0.176386437395.issue20899@psf.upfronthosting.co.za>
Message-ID: <1416906580.63.0.567303821795.issue20899@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20899>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:15:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 09:15:02 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>
Message-ID: <1416906902.42.0.750826599821.issue20002@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If you are not interested in any of proposed changes Antoine, this issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:18:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 09:18:29 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>
Message-ID: <1416907109.63.0.0757484590387.issue20002@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/issue20002>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:21:25 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 25 Nov 2014 09:21:25 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>
Message-ID: <1416907285.67.0.619278519095.issue20002@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Not really, sorry.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:30:55 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 09:30:55 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1416907855.62.0.315580854094.issue19676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------
assignee:  -> serhiy.storchaka
keywords: +needs review
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:33:41 2014
From: report at bugs.python.org (Akira Li)
Date: Tue, 25 Nov 2014 09:33:41 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1416908021.23.0.345449077987.issue22798@psf.upfronthosting.co.za>


Akira Li added the comment:

One of the ways to fix this issue is to synchronize time.tzname 
attribute with the corresponding C tzname variable.

I've uploaded sync-time-timezone-attr-with-c.diff patch that
synchronizes tzname, timezone, altzone, daylight attributes.
The patch also includes tests. No docs changes are necessary.
The code follows C, POSIX standards and the time module documentation.
Any differences are unintetional.

The patch also fixes "wrong time.timezone" issue
http://bugs.python.org/issue22799

The patch doesn't use tm_gmtoff, tm_zone C values from jan, jul to set 
timezone, tzname time module attributes therefore it may break
software that relies on that behaviour. I would be interested to hear
about such instances.

I've removed the cygwin branch in the code (I haven't found cygwin 
buildbot). It could be added back as is if necessary.

----------
Added file: http://bugs.python.org/file37273/sync-time-timezone-attr-with-c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Tue Nov 25 10:37:41 2014
From: report at bugs.python.org (Akira Li)
Date: Tue, 25 Nov 2014 09:37:41 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1416908261.85.0.22350756289.issue22798@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Removed file: http://bugs.python.org/file37132/test_mktime_changes_tzname.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________

From report at bugs.python.org  Tue Nov 25 11:34:07 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 25 Nov 2014 10:34:07 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1416911647.98.0.770888875554.issue19676@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

The patch looks good to me.
But it seems that the reverse operation is not possible in the general case: .decode('unicode_escape') assumes a latin-1 or ascii encoding.
Should we document this?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 11:54:01 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 25 Nov 2014 10:54:01 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1416912841.48.0.470987102312.issue19676@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The patch looks good.

One nit: the name buffer length should be NAME_MAXLEN instead of 100.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 11:56:33 2014
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 25 Nov 2014 10:56:33 +0000
Subject: [issue22939] integer overflow in iterator object
Message-ID: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za>


New submission from Clement Rouault:

I found an interger overflow in the standard iterator object (Objects/iterobject.c)

The `it_index` attribute used by the iterator is a `Py_ssize_t` but overflow is never checked. So after the index `PY_SSIZE_T_MAX`, the iterator object will ask for the index `PY_SSIZE_T_MIN`.

Here is an example:

    import sys

    class Seq:
        def __getitem__(self, item):
            print("[-] Asked for item at <{0}>".format(item))
            return 0

    s = Seq()
    i = iter(s)
    # Manually set `it_index` to PY_SSIZE_T_MAX without a loop
    i.__setstate__(sys.maxsize)

    next(i)
    [-] Asked for item at <9223372036854775807>
    next(i)
    [-] Asked for item at <-9223372036854775808>


I would be really interested in writing a patch but first I wanted to discuss the expected behaviour and fix.

The iterator could stop after `PY_SSIZE_T_MAX` but it seems strange as other iterator (like `enumobject`) handle values bigger than `PY_SSIZE_T_MAX`.

Or the same technique used in `enumobject` could be used: adding a field `PyObject* en_longindex` (a python long) which would be used for values bigger than `PY_SSIZE_T_MAX`

----------
components: Interpreter Core
messages: 231651
nosy: hakril
priority: normal
severity: normal
status: open
title: integer overflow in iterator object
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 11:58:27 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 25 Nov 2014 10:58:27 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1416913107.2.0.613331618562.issue19676@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Patch looks good to me, too.

As far as Amaury's question goes, isn't the general reverse operation the same as for the existing backslashreplace handler?

That is, decode with the appropriate ASCII compatible encoding (since ASCII compatibility is needed for the escape sequences to be valid), then run the result through ast.literal_eval?

(I'll grant we don't currently provide guidance on reversing backslashreplace either, but addressing that sounds like a separate question from this change)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 12:42:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 11:42:09 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>
Message-ID: <1416915729.74.0.241814519345.issue20002@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:13:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Nov 2014 12:13:46 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <20141125121329.55119.14164@psf.io>


Roundup Robot added the comment:

New changeset 32d08aacffe0 by Serhiy Storchaka in branch 'default':
Issue #19676: Added the "namereplace" error handler.
https://hg.python.org/cpython/rev/32d08aacffe0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:29:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 12:29:35 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1416918575.52.0.428473447449.issue19676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you all for reviews.

> One nit: the name buffer length should be NAME_MAXLEN instead of 100.

NAME_MAXLEN is private name available only in Modules/unicodedata.c. Making it public name would be other issue. I have increased buffer size to 256.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:43:07 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 12:43:07 +0000
Subject: [issue22286] Allow backslashreplace error handler to be used on input
In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za>
Message-ID: <1416919387.32.0.93155721194.issue22286@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Synchronized with the tip (resolved conflicts with issue22470 and issue19676).

----------
assignee:  -> serhiy.storchaka
keywords: +needs review
Added file: http://bugs.python.org/file37274/backslashreplace_decode_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22286>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:45:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 12:45:53 +0000
Subject: [issue19105] pprint doesn't use all width
In-Reply-To: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za>
Message-ID: <1416919553.91.0.0444455310344.issue19105@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review?

----------
keywords: +needs review
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19105>
_______________________________________

From report at bugs.python.org  Tue Nov 25 13:51:46 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 12:51:46 +0000
Subject: [issue18965] 2to3 can produce illegal bytes literals
In-Reply-To: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za>
Message-ID: <1416919906.68.0.675538157085.issue18965@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Now Python 2 with the -3 option warns about b-prefixed strings with non-ASCII characters (issue19656).

----------
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18965>
_______________________________________

From report at bugs.python.org  Tue Nov 25 14:14:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 13:14:40 +0000
Subject: [issue22939] integer overflow in iterator object
In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za>
Message-ID: <1416921280.9.0.338025047518.issue22939@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger, serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 14:40:12 2014
From: report at bugs.python.org (Robert Kuska)
Date: Tue, 25 Nov 2014 13:40:12 +0000
Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE"
 attack)
In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>
Message-ID: <1416922812.31.0.441490767364.issue22638@psf.upfronthosting.co.za>


Robert Kuska added the comment:

FYI fedora (rawhide) has SSLv3 disabled in SSLv23 method of openssl package.
http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=80b5477597e9f0d9fababd854adfb4988b37efd5

This looks like the same approach as in attached issue22638.diff.

----------
nosy: +rkuska

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22638>
_______________________________________

From report at bugs.python.org  Tue Nov 25 14:51:24 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Nov 2014 13:51:24 +0000
Subject: [issue22939] integer overflow in iterator object
In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za>
Message-ID: <1416923483.99.0.533844464629.issue22939@psf.upfronthosting.co.za>


R. David Murray added the comment:

For possibly relevant background information, see issue 21444 and the issues linked from it, and issue 14794.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 15:23:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 14:23:33 +0000
Subject: [issue22939] integer overflow in iterator object
In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za>
Message-ID: <1416925413.03.0.119685022417.issue22939@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The `it_index` attribute used by the iterator is a `Py_ssize_t` but overflow is never checked.

Yes it is a bug. iter_iternext() must raises an OverflowError if it->it_index is equal to PY_SSIZE_T_MAX.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 15:30:57 2014
From: report at bugs.python.org (bru)
Date: Tue, 25 Nov 2014 14:30:57 +0000
Subject: [issue22940] readline does not offer partial saves
Message-ID: <1416925857.17.0.992509064643.issue22940@psf.upfronthosting.co.za>


New submission from bru:

The "readline" module offers "write_history_file" from readline/history.h "write_history", but there's no "append_history_file" that would invoke "append_history" from the C header.

This causes inconveniences when saving history to a file (like shown there: https://docs.python.org/3.5/library/readline.html?highlight=readline#example). Indeed, say you have 2 interpreters (A) and (B) open.
- (A) and (B) load the history, composed of (z) lines
- you work on both, writing (a) lines in (A) and (b) lines in (b)
- you close (A), the history file now has (z)+(a)
- you close (B), the history file now has (z)+(b)
Therefore (A) history (the (a) lines) is lost. Offering "append_history_file" would be a nice way to fix this problem: having (z)+(a)+(b) in the end would be easy.

This is exactly what the attached patch does. With it are tests, doc and an example. I've not updated Misc/NEWS yet though (no issue #).

----------
components: Library (Lib)
files: 0001-Add-readline.append_history_file-function.patch
keywords: patch
messages: 231661
nosy: bru
priority: normal
severity: normal
status: open
title: readline does not offer partial saves
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37275/0001-Add-readline.append_history_file-function.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22940>
_______________________________________

From report at bugs.python.org  Tue Nov 25 15:36:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 14:36:13 +0000
Subject: [issue22841] Avoid to use coroutine with add_signal_handler()
In-Reply-To: <1415662547.93.0.350675273647.issue22841@psf.upfronthosting.co.za>
Message-ID: <1416926173.69.0.771482167841.issue22841@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/issue22841>
_______________________________________

From report at bugs.python.org  Tue Nov 25 15:37:46 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 14:37:46 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416926266.29.0.317638253389.issue22685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Here is a patch with a simple unit test.

Can someone review it? If not, I will commit it without review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Tue Nov 25 15:39:53 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Nov 2014 14:39:53 +0000
Subject: [issue20899] Nested namespace imports do not work inside zip archives
In-Reply-To: <1394656225.26.0.176386437395.issue20899@psf.upfronthosting.co.za>
Message-ID: <1416926393.78.0.0727756182752.issue20899@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +gregory.p.smith, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20899>
_______________________________________

From report at bugs.python.org  Tue Nov 25 16:02:30 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Nov 2014 15:02:30 +0000
Subject: [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416927750.52.0.373958647688.issue22581@psf.upfronthosting.co.za>


R. David Murray added the comment:

There's no review link.  And no obvious reason why there isn't.  Could you try regenerating the patch and uploading it again?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22581>
_______________________________________

From report at bugs.python.org  Tue Nov 25 16:22:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 15:22:08 +0000
Subject: [issue22939] integer overflow in iterator object
In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za>
Message-ID: <1416928928.89.0.258729553529.issue22939@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think OverflowError is good for maintained releases, but for 3.5 Clement's idea with long index looks attractive to me. In any case an exception should be raised for negative argument in __setstate__(). Let split this issue on two parts. First fix the bug by raising exceptions, and then add long index (if anyone will need it).

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 16:32:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 15:32:50 +0000
Subject: [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416929570.06.0.688188042415.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Regenerated for review. I don't know why Rietweld didn't like previous patch.

----------
Added file: http://bugs.python.org/file37276/bytes_like.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22581>
_______________________________________

From report at bugs.python.org  Tue Nov 25 16:37:56 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 25 Nov 2014 15:37:56 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1416926266.29.0.317638253389.issue22685@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ6fyV9KPdKDVB97DNP3ktrRqwnQd_ViUAwsc5TwJD7cg@mail.gmail.com>


Guido van Rossum added the comment:

Sorry, looks good.

On Tue, Nov 25, 2014 at 6:37 AM, STINNER Victor <report at bugs.python.org>
wrote:

>
> STINNER Victor added the comment:
>
> > Here is a patch with a simple unit test.
>
> Can someone review it? If not, I will commit it without review.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22685>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:25:13 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Nov 2014 16:25:13 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <20141125162457.55119.30954@psf.io>


Roundup Robot added the comment:

New changeset f75d40c02f0a by Victor Stinner in branch '3.4':
Closes #22685, asyncio: Set the transport of stdout and stderr StreamReader
https://hg.python.org/cpython/rev/f75d40c02f0a

New changeset 7da2288183d1 by Victor Stinner in branch 'default':
(Merge 3.4) Closes #22685, asyncio: Set the transport of stdout and stderr
https://hg.python.org/cpython/rev/7da2288183d1

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:25:56 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 16:25:56 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416932756.35.0.8917804164.issue22685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Fix also pushed to Python 3.4, 3.5 and to Tulip. Thanks for the report wabu.

Tulip commit:

changeset:   1350:c3a9d355eb34
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Nov 25 17:17:13 2014 +0100
files:       asyncio/subprocess.py tests/test_subprocess.py
description:
Python issue #22685: Set the transport of stdout and stderr StreamReader
objects in the SubprocessStreamProtocol. It allows to pause the transport to
not buffer too much stdout or stderr data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:40:32 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 16:40:32 +0000
Subject: [issue22939] integer overflow in iterator object
In-Reply-To: <1416928928.89.0.258729553529.issue22939@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbJ3VCSzwtR2B4vdVOq=-b2y+002WgOkVDTvaEV-GtjXQ@mail.gmail.com>


STINNER Victor added the comment:

> I think OverflowError is good for maintained releases, but for 3.5 Clement's idea with long index looks attractive to me.

What is your use case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:41:57 2014
From: report at bugs.python.org (=?utf-8?b?U8O4cmVuIEzDuHZib3Jn?=)
Date: Tue, 25 Nov 2014 16:41:57 +0000
Subject: [issue22941] IPv4Interface arithmetic changes subnet mask
Message-ID: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za>


New submission from S?ren L?vborg:

Addition and subtraction of integers are documented for ipaddress.IPv4Address and ipaddress.IPv6Address, but also work for IPv4Interface and IPv6Interface (though the only documentation of this is a brief mention that the Interface classes inherit from the respective Address classes). That's good.

The problem is that adding/subtracting an integer to an Interface object changes the subnet mask (to max_prefixlen), something which is 1) not documented and 2) not the least surprising result.

>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/32')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/128')

Changing this breaks backwards compatibility; though since the ipaddress module was provisional until recently and the behavior is undocumented, I hope it's not too late to change.

----------
components: Library (Lib)
messages: 231670
nosy: kwi.dk
priority: normal
severity: normal
status: open
title: IPv4Interface arithmetic changes subnet mask
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22941>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:51:46 2014
From: report at bugs.python.org (=?utf-8?b?U8O4cmVuIEzDuHZib3Jn?=)
Date: Tue, 25 Nov 2014 16:51:46 +0000
Subject: [issue22941] IPv4Interface arithmetic changes subnet mask
In-Reply-To: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za>
Message-ID: <1416934306.31.0.530171442243.issue22941@psf.upfronthosting.co.za>


S?ren L?vborg added the comment:

Proposed implementation patch attached. If this has any interest, I'll look into expanding the patch to include documentation and unit tests.

Resulting behavior:
>>> import ipaddress
>>> ipaddress.IPv4Interface('10.0.0.1/8') + 1
IPv4Interface('10.0.0.2/8')
>>> ipaddress.IPv6Interface('fd00::1/64') + 1
IPv6Interface('fd00::2/64')

----------
keywords: +patch
Added file: http://bugs.python.org/file37277/ipaddress.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22941>
_______________________________________

From report at bugs.python.org  Tue Nov 25 17:59:24 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Nov 2014 16:59:24 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <20141125165901.116332.16626@psf.io>


Roundup Robot added the comment:

New changeset b6fab008d63a by Berker Peksag in branch 'default':
Issue #19676: Tweak documentation a bit.
https://hg.python.org/cpython/rev/b6fab008d63a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Tue Nov 25 18:03:35 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Nov 2014 17:03:35 +0000
Subject: [issue22941] IPv4Interface arithmetic changes subnet mask
In-Reply-To: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za>
Message-ID: <1416935015.32.0.869750306619.issue22941@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +ncoghlan, pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22941>
_______________________________________

From report at bugs.python.org  Tue Nov 25 18:18:56 2014
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 25 Nov 2014 17:18:56 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1416935936.31.0.671844761394.issue22524@psf.upfronthosting.co.za>


Miki Tebeka added the comment:

Can we also update iglob [1] as well?

[1] https://docs.python.org/2/library/glob.html#glob.iglob

----------
nosy: +tebeka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Nov 25 18:43:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 17:43:34 +0000
Subject: [issue20204] pydocs fails for some C implemented classes
In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>
Message-ID: <1416937414.1.0.392756021892.issue20204@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem not in pydoc or inspect itself. In Python 3.3 _tkinter.TkappType has the __module__ attribute:

>>> import _tkinter
>>> _tkinter.TkappType.__module__
'builtins'

Something was changed in 3.4 and builtin classes without dot in qualified name no longer have the __module__ attribute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20204>
_______________________________________

From report at bugs.python.org  Tue Nov 25 19:02:40 2014
From: report at bugs.python.org (Chris Angelico)
Date: Tue, 25 Nov 2014 18:02:40 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1416938560.03.0.476994047981.issue22906@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Known issues with the current patch, if anyone feels like playing with this who better knows the code:

1) Needs a __future__ directive to control behaviour
2) test_generators needs to be heavily reworked
3) The test of what exception was thrown needs to also handle StopIteration subclasses
4) Check for refleaks and/or over-freeing
5) Properly provide a traceback for the original StopIteration (not always happening)

Any others?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Tue Nov 25 19:21:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 18:21:29 +0000
Subject: [issue22939] integer overflow in iterator object
In-Reply-To: <CAMpsgwbJ3VCSzwtR2B4vdVOq=-b2y+002WgOkVDTvaEV-GtjXQ@mail.gmail.com>
Message-ID: <7016985.gIj7ySOekU@raxxla>


Serhiy Storchaka added the comment:

> What is your use case?

Something like range(). I agree that it is very unlike to encounter this 
problem in real work, and we can live with implementation-related limitation 
(for which OverflowError exists).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22939>
_______________________________________

From report at bugs.python.org  Tue Nov 25 19:31:52 2014
From: report at bugs.python.org (Akira Li)
Date: Tue, 25 Nov 2014 18:31:52 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1416940312.61.0.358583690279.issue22524@psf.upfronthosting.co.za>


Akira Li added the comment:

scandir is slower on my machine:

  $ git clone https://github.com/benhoyt/scandir 
  $ cd scandir/
  $ ../cpython/python benchmark.py /usr/
  Using slower ctypes version of scandir
  Comparing against builtin version of os.walk()
  Priming the system's cache...
  Benchmarking walks on /usr/, repeat 1/3...
  Benchmarking walks on /usr/, repeat 2/3...
  Benchmarking walks on /usr/, repeat 3/3...
  os.walk took 7.761s, scandir.walk took 10.420s -- 0.7x as fast

What commands should I run to benchmark the attached patch (scandir-2.patch)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Nov 25 19:47:18 2014
From: report at bugs.python.org (wabu)
Date: Tue, 25 Nov 2014 18:47:18 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416941238.26.0.701932594209.issue22685@psf.upfronthosting.co.za>


wabu added the comment:

thanks for the fixes 'n' integration

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Tue Nov 25 20:52:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 19:52:22 +0000
Subject: [issue22518] integer overflow in encoding unicode
In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za>
Message-ID: <1416945142.88.0.769692905434.issue22518@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you want to add a bigmem test or close this issue Benjamin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22518>
_______________________________________

From report at bugs.python.org  Tue Nov 25 20:52:38 2014
From: report at bugs.python.org (Jordan)
Date: Tue, 25 Nov 2014 19:52:38 +0000
Subject: [issue22942] Language Reference - optional comma
Message-ID: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>


New submission from Jordan:

# I would like to report three bugs in the
# Language Reference Python 3.4.2

#################################
# bug 1: Typo in parameter_list #
#################################

# In 8.6 the rule for parameter_list should be corrected: The first "|" should be "("

# parameter_list ::=  (defparameter ",")*
#                     | "*" [parameter] ("," defparameter)* ["," "**" parameter]
#                     | "**" parameter
#                     | defparameter [","] )

# This rule was correct in 3.3 but has been changed with issue #21439, I guess.

                    
###############################################################################
# bug 2: print(*(1,2),) is allowed according to the syntax - but not accepted #
###############################################################################

# In 6.3.4:
# call                 ::=  primary "(" [argument_list [","] | comprehension] ")"
# argument_list        ::=  positional_arguments ["," keyword_arguments]
#                             ["," "*" expression] ["," keyword_arguments]
#                             ["," "**" expression]
#                           | keyword_arguments ["," "*" expression]
#                             ["," keyword_arguments] ["," "**" expression]
#                           | "*" expression ["," keyword_arguments] ["," "**" expression]
#                           | "**" expression

# Why is this wrong?
print(1,2,)     # is allowed
print(*(1,2))   # is allowed
#print(*(1,2),) # is allowed according to the syntax - but not accepted

# I guess the trailing comma is only allowed when there is no *-argument
# as it is in the rule for parameter_list

###########################################################
# bug 3: decorator rule allows (aditional) trailing comma #
###########################################################

# In 8.6:
# decorator      ::=  "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE
# parameter_list ::=  (defparameter ",")*
#                     ( "*" [parameter] ("," defparameter)* ["," "**" parameter]
#                     | "**" parameter
#                     | defparameter [","] )

# Why is this wrong?
def klammer(klammer_left,klammer_right):
    def klammer_decorator(func):
        def func_wrapper(name):
            return klammer_left + func(name) + klammer_right
        return func_wrapper
    return klammer_decorator

@klammer("<",">",)   # is allowed
#@klammer("<",">",,) # is allowed according to the syntax - but is not accepted
def get_text(name):
    return "Hallo " + name
print(get_text("Uli")) 

@klammer(*("<",">"))   # is allowed
#@klammer(*("<",">"),) # is allowed according to the syntax - but is not accepted
def get_text(name):
    return "Hallo " + name
print(get_text("Uli"))

# I guess the decorator rule might be changed to: 
# decorator      ::=  "@" dotted_name ["(" [parameter_list      ] ")"] NEWLINE
# The other appearences of parameter_list have no optional comma.

----------
assignee: docs at python
components: Documentation
messages: 231680
nosy: docs at python, jordan
priority: normal
severity: normal
status: open
title: Language Reference - optional comma
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22942>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:15:37 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Nov 2014 20:15:37 +0000
Subject: [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1416946537.28.0.604186569832.issue22942@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22942>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:41:55 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2014 20:41:55 +0000
Subject: [issue22518] integer overflow in encoding unicode
In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za>
Message-ID: <1416948115.23.0.379871860501.issue22518@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I wouldn't object if you had a patch.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22518>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:51:23 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 20:51:23 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1416940312.61.0.358583690279.issue22524@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYuAeS0HGh+E7cJxPVzbLqMZkU9KJjEkQzR1RF5CkAj8A@mail.gmail.com>


STINNER Victor added the comment:

> scandir is slower on my machine:

Please share more information about your config: OS, disk type (hard
drive, SSD, something else), filesystem, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:51:44 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 25 Nov 2014 20:51:44 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416948704.2.0.842310663359.issue22898@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The attached script raises the PyExc_RecursionErrorInst singleton and reproduces the issue.
The attached patch fixes the issue by ignoring the warning when clearing PyExc_RecursionErrorInst and clearing the frames associated with its traceback, in _PyExc_Fini().

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file37278/runtimerror_singleton_2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:51:56 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 25 Nov 2014 20:51:56 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416948716.96.0.610244304269.issue22898@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


Added file: http://bugs.python.org/file37279/warn_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Tue Nov 25 21:54:01 2014
From: report at bugs.python.org (Ben Hoyt)
Date: Tue, 25 Nov 2014 20:54:01 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1416948841.17.0.950266993784.issue22524@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Akira, note the "Using slower ctypes version of scandir" -- this is the older, ctypes implementation of scandir. On Linux, depending on file system etc, that can often be slower. You need to at least be using the "fast C version" in _scandir.c, which is then half C, half Python. But ideally you'd use the all-C version that I've provided as a CPython 3.5 patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:01:55 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 21:01:55 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416949315.29.0.131684978781.issue22685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

You can workaround the issue by setting manually the transport on the StreamReader objects. Tell me if you need help to write the workaround if you cannot wait for a release containing the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Tue Nov 25 22:04:00 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 25 Nov 2014 21:04:00 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1416949440.08.0.499068787973.issue22898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+    /* during Python finalization, warnings may be emited after interp->sysdict
+       is cleared: see issue #22898 */

I would prefer to see this comment in the else block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:36:39 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 25 Nov 2014 23:36:39 +0000
Subject: [issue22943] bsddb: test_queue fails on Windows
Message-ID: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

One gets this on the Windows bots:

======================================================================
FAIL: test01_basic (bsddb.test.test_queue.SimpleQueueTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\bsddb\test\test_queue.py", line 49, in test01_basic
    self.assertEqual(len(d), len(string.letters)+3)
AssertionError: 125 != 128

======================================================================
FAIL: test02_basicPost32 (bsddb.test.test_queue.SimpleQueueTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\bsddb\test\test_queue.py", line 120, in test02_basicPost32
    self.assertEqual(len(d), len(string.letters)+3)
AssertionError: 125 != 128

----------------------------------------------------------------------

(See http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2925/steps/test/logs/stdio)

This has been going on for a long time. I doubt anyone cares. I'm just going to disable the test.

----------
components: Extension Modules
messages: 231687
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: bsddb: test_queue fails on Windows
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22943>
_______________________________________

From report at bugs.python.org  Wed Nov 26 00:37:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Nov 2014 23:37:34 +0000
Subject: [issue22943] bsddb: test_queue fails on Windows
In-Reply-To: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za>
Message-ID: <20141125233719.116308.97511@psf.io>


Roundup Robot added the comment:

New changeset e5ed983bc784 by Benjamin Peterson in branch '2.7':
disable tests that always fail on windows (#22943)
https://hg.python.org/cpython/rev/e5ed983bc784

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22943>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:02:11 2014
From: report at bugs.python.org (Simon Zack)
Date: Wed, 26 Nov 2014 04:02:11 +0000
Subject: [issue22944] Python argument tuple unpacking
Message-ID: <1416974531.76.0.408873524447.issue22944@psf.upfronthosting.co.za>


New submission from Simon Zack:

Python already has tuple unpacking in many places, I wonder if this has been considered for arguments yet, it seems rather convenient and a natural extension to me.

Here's what I mean:

def func((a, b, c)):
    print(a, b, c)

func((1, 2, 3))

should print "1 2 3"

----------
components: Interpreter Core
messages: 231689
nosy: simonzack
priority: normal
severity: normal
status: open
title: Python argument tuple unpacking

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22944>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:03:48 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2014 04:03:48 +0000
Subject: [issue22944] Python argument tuple unpacking
In-Reply-To: <1416974531.76.0.408873524447.issue22944@psf.upfronthosting.co.za>
Message-ID: <1416974628.61.0.786502965903.issue22944@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Python 2 has it. It was removed in Python 3. See https://www.python.org/dev/peps/pep-3113/

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22944>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:08:07 2014
From: report at bugs.python.org (koobs)
Date: Wed, 26 Nov 2014 04:08:07 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416974887.42.0.967004776961.issue22685@psf.upfronthosting.co.za>


koobs added the comment:

Buildbot failures observed on koobs-freebsd9 and koobs-freebsd10 for 3.x and 3.4, respectively.

Both logs are attached, inlined failure below:

======================================================================
FAIL: test_pause_reading (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.4.koobs-freebsd10/build/Lib/test/test_asyncio/test_subprocess.py", line 194, in test_pause_reading
    self.assertTrue(called)
AssertionError: False is not true

======================================================================

----------
nosy: +koobs
status: closed -> open
Added file: http://bugs.python.org/file37280/koobs-freebsd9-python3x-build-2405.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:08:31 2014
From: report at bugs.python.org (koobs)
Date: Wed, 26 Nov 2014 04:08:31 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416974911.07.0.449753566981.issue22685@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


Added file: http://bugs.python.org/file37281/koobs-freebsd10-python34-build-598.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:46:50 2014
From: report at bugs.python.org (Daniel Standage)
Date: Wed, 26 Nov 2014 04:46:50 +0000
Subject: [issue22945] Ctypes inconsistent between Linux and OS X
Message-ID: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za>


New submission from Daniel Standage:

The ctypes documentation describes the '._as_parameter_' attribute, which simplifies using Python objects to encapsulate C objects. If a ctypes object with the '._as_parameter_' attribute defined is passed as a parameter to a C function, the value of '._as_parameter_' is supplied to the C function instead of a pointer to the Python project.

At least that's how it's advertised to work. And it does indeed work as advertised on Linux, but on Mac OS X the mechanism doesn't appear to work correctly. I have created a small dummy example demonstrating this at https://github.com/standage/ctypes-demo.

----------
components: ctypes
hgrepos: 281
messages: 231692
nosy: Daniel.Standage
priority: normal
severity: normal
status: open
title: Ctypes inconsistent between Linux and OS X
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22945>
_______________________________________

From report at bugs.python.org  Wed Nov 26 05:47:11 2014
From: report at bugs.python.org (Daniel Standage)
Date: Wed, 26 Nov 2014 04:47:11 +0000
Subject: [issue22945] Ctypes inconsistent between Linux and OS X
In-Reply-To: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za>
Message-ID: <1416977231.44.0.223764254246.issue22945@psf.upfronthosting.co.za>


Changes by Daniel Standage <daniel.standage at gmail.com>:


----------
hgrepos:  -281

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22945>
_______________________________________

From report at bugs.python.org  Wed Nov 26 07:16:51 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Nov 2014 06:16:51 +0000
Subject: [issue22945] Ctypes inconsistent between Linux and OS X
In-Reply-To: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za>
Message-ID: <1416982611.19.0.664527511586.issue22945@psf.upfronthosting.co.za>


Ned Deily added the comment:

FWIW, your test does seem to run if the C test program is instead built in 32-bit mode (modifying CFLAGS to include "-arch i386"). For example, with the Apple OS X 10.10 system Python:

DYLD_LIBRARY_PATH=.. arch -i386 /usr/bin/python2.7 test.py
Gizmo 1: 15
Gizmo 2: 20
Empty data

----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22945>
_______________________________________

From report at bugs.python.org  Wed Nov 26 07:51:55 2014
From: report at bugs.python.org (Vandana Rao)
Date: Wed, 26 Nov 2014 06:51:55 +0000
Subject: [issue22804] Can't run Idle in Windows 8 or windows 64
In-Reply-To: <1415268649.04.0.373697042917.issue22804@psf.upfronthosting.co.za>
Message-ID: <1416984715.55.0.761416540276.issue22804@psf.upfronthosting.co.za>


Vandana Rao added the comment:

Try uninstalling IDLE and install it once again.I had this situation previously where the command prompt opens and gets closed within fraction of seconds. Uninstall it completely and try once again.I hope this would work.

----------
nosy: +Vandana.Rao

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22804>
_______________________________________

From report at bugs.python.org  Wed Nov 26 08:48:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 07:48:17 +0000
Subject: [issue20204] pydocs fails for some C implemented classes
In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>
Message-ID: <1416988097.53.0.34896941492.issue20204@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

_tkinter.TkappType.__flags__ is different.

In 3.3: 0b1000001000000000000
In 3.4: 0b1000001001000000000

The difference is Py_TPFLAGS_HEAPTYPE. This is the consequence of the change made in issue15721.

----------
components: +Interpreter Core, Tkinter
nosy: +Robin.Schreiber, amaury.forgeotdarc, asvetlov, loewis, ned.deily, pitrou
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20204>
_______________________________________

From report at bugs.python.org  Wed Nov 26 08:48:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 07:48:36 +0000
Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module
In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za>
Message-ID: <1416988115.99.0.101107435368.issue15721@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

_tkinter classes are now heap types and they no longer have the __module__ attribute.

>>> import _tkinter
>>> _tkinter.TkappType.__module__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __module__

See issue20204.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15721>
_______________________________________

From report at bugs.python.org  Wed Nov 26 09:13:35 2014
From: report at bugs.python.org (eryksun)
Date: Wed, 26 Nov 2014 08:13:35 +0000
Subject: [issue22945] Ctypes inconsistent between Linux and OS X
In-Reply-To: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za>
Message-ID: <1416989615.78.0.175218210771.issue22945@psf.upfronthosting.co.za>


eryksun added the comment:

c_void_p's getfunc returns the address as an integer. In turn, an integer argument gets converted to a C int. This mean you need to a create a new c_void_p from the address for _as_parameter_, e.g.

    self._as_parameter_ = c_void_p(self.g)

Or set restype to a subclass of c_void_p. ctypes won't call the getfunc in this case, e.g. 

    class my_void_p(c_void_p):
        pass

    mylib.my_gizmo_create.restype = my_void_p

ConvParam
https://hg.python.org/cpython/file/ee879c0ffa11/Modules/_ctypes/callproc.c#l613

GetResult
https://hg.python.org/cpython/file/ee879c0ffa11/Modules/_ctypes/callproc.c#l903

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22945>
_______________________________________

From report at bugs.python.org  Wed Nov 26 09:30:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 08:30:26 +0000
Subject: [issue22943] bsddb: test_queue fails on Windows
In-Reply-To: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za>
Message-ID: <1416990626.88.0.557570358091.issue22943@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This test is locale-depending. string.letters is the collection of 8-bit characters for which islower() or isupper() is true. On most Unixes the locale is either UTF-8 or ASCII and string.letters contains only ASCII letters. On most Windows it contains characters from extended ASCII, and the length of string.letters can be larger than 75 (minimal non-replacement index used in tests).

There is two simple way to fix this issue.
1) increase test indices to be larger than 255.
2) use string.ascii_letters instead of string.letters.

Here is the patch which uses the second approach (because string.letters is used in other tests).

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37282/bsddbtests_ascii_letters.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22943>
_______________________________________

From report at bugs.python.org  Wed Nov 26 09:36:41 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Nov 2014 08:36:41 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <1416991001.77.0.664241611067.issue22685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Buildbot failures observed on koobs-freebsd9 and koobs-freebsd10 for 3.x and 3.4, respectively.

I'm unable to reproduce the failure with "./python -m test -F test_asyncio" or "./python -m test -F -m test_pause_reading test_asyncio" on my FreeBSD 9.1 VM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:14:01 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Nov 2014 10:14:01 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <20141126101353.69783.41406@psf.io>


Roundup Robot added the comment:

New changeset 21d1571c0533 by Serhiy Storchaka in branch 'default':
Issue #19676: Fixed integer overflow issue in "namereplace" error handler.
https://hg.python.org/cpython/rev/21d1571c0533

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:14:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 10:14:28 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1416996868.77.0.742671938868.issue19676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Berker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:37:27 2014
From: report at bugs.python.org (John McKay)
Date: Wed, 26 Nov 2014 10:37:27 +0000
Subject: [issue22946] urllib gives incorrect url after open when using HTTPS
Message-ID: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za>


New submission from John McKay:

After getting a sucessfull response, _open_generic_http will overwrite the the start of the url to be http: regardless of if it was called from open_http() or open_https(). This causes it to appear as if you were redirected to a non-secure site if you check the url properly after an open request. This is especially problematic after being redirected; it appears you were redirected to an insecure version of the site.

Attached is a patch to resolve this. It uses the type, which should be correctly set to http or https based on the calling context.

----------
components: Library (Lib)
files: urllib.patch
keywords: patch
messages: 231702
nosy: John.McKay
priority: normal
severity: normal
status: open
title: urllib gives incorrect url after open when using HTTPS
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37283/urllib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22946>
_______________________________________

From report at bugs.python.org  Wed Nov 26 11:59:02 2014
From: report at bugs.python.org (Akira Li)
Date: Wed, 26 Nov 2014 10:59:02 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1416999542.78.0.615275701284.issue22524@psf.upfronthosting.co.za>


Akira Li added the comment:

> STINNER Victor added the comment:
>
>> scandir is slower on my machine:
>
> Please share more information about your config: OS, disk type (hard
> drive, SSD, something else), filesystem, etc.
>
Ubuntu 14.04, SSD, ext4 filesystem. Results for different python
versions are the same (scandir on pypy is even slower due to ctype
usage).

What other information could be useful?

> Ben Hoyt added the comment:
>
> Akira, note the "Using slower ctypes version of scandir" -- this is
> the older, ctypes implementation of scandir. On Linux, depending on
> file system etc, that can often be slower. You need to at least be
> using the "fast C version" in _scandir.c, which is then half C, half
> Python. But ideally you'd use the all-C version that I've provided as
> a CPython 3.5 patch.

Yes. I've noticed it, that is why I asked :) *"What commands should I
run to benchmark the attached patch (scandir-2.patch)?"*

I've read benchmark.py's source; It happens that it already supports
benchmarking of os.scandir. In my python checkout:

  cpython$ hg import --no-commit https://bugs.python.org/file36963/scandir-2.patch
  cpython$ make && cd ../scandir/
  scandir$ ../cpython/python benchmark.py -s /usr/
  Using Python 3.5's builtin os.scandir()
  Comparing against builtin version of os.walk()
  Priming the system's cache...
  Benchmarking walks on /usr/, repeat 1/3...
  Benchmarking walks on /usr/, repeat 2/3...
  Benchmarking walks on /usr/, repeat 3/3...
  os.walk size 7925376343, scandir.walk size 5534939617 -- NOT EQUAL!
  os.walk took 13.552s, scandir.walk took 6.032s -- 2.2x as fast

It seems os.walk and scandir.walk do a different work here.

I've written get_tree_size_listdir_fd() that mimics get_tree_size() 
(see get_tree_size_listdir.diff patch) to get the same size:

  scandir$ ../cpython/python benchmark.py -s /usr
  Using Python 3.5's builtin os.scandir()
  Comparing against builtin version of os.walk()
  Comparing against get_tree_size_listdir_fd
  Priming the system's cache...
  Benchmarking walks on /usr, repeat 1/3...
  Benchmarking walks on /usr, repeat 2/3...
  Benchmarking walks on /usr, repeat 3/3...
  os.walk size 5534939617, scandir.walk size 5534939617 -- equal
  os.walk took 5.697s, scandir.walk took 5.621s -- 1.0x as fast

scandir is not noticeably faster but scandir-based code is much nicer here.

----------
Added file: http://bugs.python.org/file37284/get_tree_size_listdir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Wed Nov 26 12:27:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 11:27:28 +0000
Subject: [issue22518] integer overflow in encoding unicode
In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za>
Message-ID: <1417001248.43.0.28274177522.issue22518@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Integer overflow errors were fixed in 4 error handlers: surrogatepass, backslashreplace, namereplace, and xmlcharrefreplace. Is is hard to write general robust tests. In worst cases they requires more than sys.maxsize or even sys.maxsize*2 memory and for sure fail with MemoryError. It is possible to write a test for xmlcharrefreplace, but it will not robust, after changes of implementation details it could raise MemoryError instead of OverflowError after consuming all address space.

So I suggest close this issue without tests. Such tests are useless.

----------
keywords: +patch
Added file: http://bugs.python.org/file37285/codecs_error_handlers_overflow_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22518>
_______________________________________

From report at bugs.python.org  Wed Nov 26 12:33:08 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 26 Nov 2014 11:33:08 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417001588.26.0.404249346749.issue22898@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> +    /* during Python finalization, warnings may be emited after interp->sysdict
> +       is cleared: see issue #22898 */
>
> I would prefer to see this comment in the else block.

Indeed.
New updated patch attached.

----------
Added file: http://bugs.python.org/file37286/warn_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 12:53:21 2014
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 26 Nov 2014 11:53:21 +0000
Subject: [issue20899] Nested namespace imports do not work inside zip archives
In-Reply-To: <1394656225.26.0.176386437395.issue20899@psf.upfronthosting.co.za>
Message-ID: <1417002801.95.0.672710994096.issue20899@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20899>
_______________________________________

From report at bugs.python.org  Wed Nov 26 13:08:19 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 12:08:19 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417003699.43.0.631150332703.issue22898@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why recursion limit is restored? Couldn't the test be simpler without it?

%a should be used instead of '%s' (file path can contain backslashes).

And it would be more robust to open file in binary mode (may be even in non-buffered). It can contain non-ascii characters.

May be the test should be marked as CPython only.

To check that script is executed at all we should print something from it and than test the out. Otherwise syntax error in script will make all test passed.

----------
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 13:18:31 2014
From: report at bugs.python.org (pankaj.s01)
Date: Wed, 26 Nov 2014 12:18:31 +0000
Subject: [issue22947] Enable 'imageop' - "Multimedia Srvices Feature module"
 for 64-bit platform
Message-ID: <1417004311.93.0.975050094816.issue22947@psf.upfronthosting.co.za>


New submission from pankaj.s01:

Hi,
'imageop' is default disable in Python-2.7.8 for 64-bit platform.
i have enable and test on x_86 64-bit architecture. it's working fine.and it's unit test is also ok.

The respective patch has been attached and test log as shown 
below . 

output: for test_imageop.py
****************************
$]./python2.7  ../lib/python2.7/test/test_imageop.py
test_input_validation (__main__.InputValidationTests) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.047s

OK

--
Thanks & Regards,

 Pankaj Sharma
(pankaj.s01 at samsung.com)

----------
components: Library (Lib)
files: Python-2.7.8-imageop.patch
keywords: patch
messages: 231707
nosy: pankaj.s01
priority: normal
severity: normal
status: open
title: Enable 'imageop' - "Multimedia Srvices Feature module" for 64-bit platform
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file37287/Python-2.7.8-imageop.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22947>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:34:48 2014
From: report at bugs.python.org (bru)
Date: Wed, 26 Nov 2014 13:34:48 +0000
Subject: [issue22901] test.test_uuid.test_find_mac fails because of `ifconfig`
 deprecation
In-Reply-To: <1416409225.2.0.632210039959.issue22901@psf.upfronthosting.co.za>
Message-ID: <1417008888.13.0.570293566436.issue22901@psf.upfronthosting.co.za>


bru added the comment:

Closed the issue since it's already been fixed.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22901>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:41:51 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 26 Nov 2014 13:41:51 +0000
Subject: [issue4887] environment inspection and manipulation API is buggy,
 inconsistent with "Python philosophy" for wrapping native APIs
In-Reply-To: <1231452487.08.0.408278867366.issue4887@psf.upfronthosting.co.za>
Message-ID: <1417009311.86.0.620350392147.issue4887@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Agreed. environ.pop() was fixed a long time ago with issue1287.
It seems that all mutable methods of the environ pseudo-dict are now correctly reflected to the platform environ.

The other direction (updates from C code should be reflected in os.environ) is tracked by issue1159.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> os.getenv() not updated after external module uses C putenv()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4887>
_______________________________________

From report at bugs.python.org  Wed Nov 26 14:57:53 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 26 Nov 2014 13:57:53 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417010273.4.0.40458762253.issue22898@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Why recursion limit is restored? Couldn't the test be simpler without it?

For the sake of explicitness, so that the interpreter will not raise a RuntimeError during finalization when checking for the recursion limit after g.throw(MyException) has raised PyExc_RecursionErrorInst.


> %a should be used instead of '%s' (file path can contain backslashes).
> And it would be more robust to open file in binary mode (may be even in non-buffered). It can contain non-ascii characters.
> May be the test should be marked as CPython only.
> To check that script is executed at all we should print something from it and than test the out. Otherwise syntax error in script will make all test passed.

Thanks.
New patch attached.

The reason why the PyExc_RecursionErrorInst singleton keeps the frames alive longer than expected is that the reference count of the PyExc_RecursionErrorInst static variable never reaches zero until _PyExc_Fini().  So decrementing the reference count of this exception after the traceback has been printed in PyErr_PrintEx() does not decrement the reference count of its traceback attribute (as it is the case with the other exceptions) and the traceback is not freed. The following patch to PyErr_PrintEx() does that.  With this new patch and without the changes made by warn_4.patch, the interpreter does not crash with the runtimerror_singleton_2.py reproducer and the ResourceWarning is now printed instead of being ignored as with the warn_4.patch:

diff --git a/Python/pythonrun.c b/Python/pythonrun.c
--- a/Python/pythonrun.c
+++ b/Python/pythonrun.c
@@ -1876,6 +1876,8 @@
         PyErr_Display(exception, v, tb);
     }
     Py_XDECREF(exception);
+    if (v == PyExc_RecursionErrorInst)
+        Py_CLEAR(((PyBaseExceptionObject *)v)->traceback);
     Py_XDECREF(v);
     Py_XDECREF(tb);
 }

If both patches were to be included, the test case in warn_4.patch would test the above patch and not the changes made in Python/_warnings.c.

----------
Added file: http://bugs.python.org/file37288/warn_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 15:32:25 2014
From: report at bugs.python.org (Sascha Falk)
Date: Wed, 26 Nov 2014 14:32:25 +0000
Subject: [issue22948] Integer type and __add__
Message-ID: <1417012345.4.0.50245289459.issue22948@psf.upfronthosting.co.za>


New submission from Sascha Falk:

The following statement makes python report a syntactic error:
1.__add__(2)

The following works:
(1).__add__(2)

----------
components: Interpreter Core
messages: 231711
nosy: sfalk
priority: normal
severity: normal
status: open
title: Integer type and __add__
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22948>
_______________________________________

From report at bugs.python.org  Wed Nov 26 15:34:48 2014
From: report at bugs.python.org (mstol)
Date: Wed, 26 Nov 2014 14:34:48 +0000
Subject: [issue22949] fnmatch.translate doesn't add ^ at the beginning
Message-ID: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>


New submission from mstol:

I'm not sure if this is real bug, but the documentation of fnmatch.translate states:

fnmatch.translate(pattern)

    Return the shell-style pattern converted to a regular expression.



My intuition about shell-style pattern is that for example, pattern:t3
should match only t3, and not ost3 or xxxxxt3, but what I receive from fnmatch is:
In [2]: fnmatch.translate("t3")
Out[2]: 't3\\Z(?ms)'

so using for example re.search will match not only on t3, but also on xxxt3 (in shell-like pattern is *t3). So... I  believe it should be changed or at least the documentation should be more specific about what "shell-style pattern" mean.

----------
components: Regular Expressions
messages: 231712
nosy: ezio.melotti, mrabarnett, mstol
priority: normal
severity: normal
status: open
title: fnmatch.translate doesn't add ^ at the beginning
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22949>
_______________________________________

From report at bugs.python.org  Wed Nov 26 15:38:02 2014
From: report at bugs.python.org (mstol)
Date: Wed, 26 Nov 2014 14:38:02 +0000
Subject: [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417012682.69.0.309395771021.issue22949@psf.upfronthosting.co.za>


mstol added the comment:

it can be changed easyly with changing the return statement in 
fnmatch.py function translate 

from:
    return res + '\Z(?ms)'

to:
    return '^' + res + '\Z(?ms)'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22949>
_______________________________________

From report at bugs.python.org  Wed Nov 26 15:46:46 2014
From: report at bugs.python.org (Flavio Grossi)
Date: Wed, 26 Nov 2014 14:46:46 +0000
Subject: [issue22666] email.Header no encoding of unicode strings containing
 newlines
In-Reply-To: <1413637685.41.0.262065905558.issue22666@psf.upfronthosting.co.za>
Message-ID: <1417013206.18.0.310295324087.issue22666@psf.upfronthosting.co.za>


Flavio Grossi added the comment:

any news?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22666>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:34:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 15:34:22 +0000
Subject: [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417016062.57.0.835146997216.issue22949@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The result of fnmatch.translate() is used with re.match(). It could be even simplified if use it with re.fullmatch(), but I afraid such change can break user code.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22949>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:49:51 2014
From: report at bugs.python.org (mstol)
Date: Wed, 26 Nov 2014 15:49:51 +0000
Subject: [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417016991.47.0.564222411563.issue22949@psf.upfronthosting.co.za>


mstol added the comment:

So you suggest that this output should not be used with re.search ? Why?

I think it should be documented, or maybe it is?

I know that this is not possible to introduce such a change to the currently used versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22949>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:50:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 15:50:51 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417017051.66.0.238037604809.issue22898@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

out can be b'Done.\r\n'. Use self.assertIn.

> If both patches were to be included, the test case in warn_4.patch would test the above patch and not the changes made in Python/_warnings.c.

You can test err for warning message.

The traceback should be cleared before decrementing the reference count. And only if Py_REFCNT(v) is 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:54:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 15:54:15 +0000
Subject: [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417017255.81.0.950981932251.issue22949@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it should be documented.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
priority: normal -> low
stage:  -> needs patch
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22949>
_______________________________________

From report at bugs.python.org  Wed Nov 26 17:01:08 2014
From: report at bugs.python.org (Jordan)
Date: Wed, 26 Nov 2014 16:01:08 +0000
Subject: [issue22948] Integer type and __add__
In-Reply-To: <1417012345.4.0.50245289459.issue22948@psf.upfronthosting.co.za>
Message-ID: <1417017668.17.0.810994118741.issue22948@psf.upfronthosting.co.za>


Jordan added the comment:

>1.< is lexed as a float constant 

>>> 1.
1.0
>>> 1.0.__add__(2)
3.0
>>> 1     .__add__(2)
3

Not sure how to procede

----------
nosy: +jordan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22948>
_______________________________________

From report at bugs.python.org  Wed Nov 26 17:11:11 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Nov 2014 16:11:11 +0000
Subject: [issue22946] urllib gives incorrect url after open when using HTTPS
In-Reply-To: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za>
Message-ID: <1417018271.06.0.0584513406518.issue22946@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Thank you for the patch. It would be nice to have a test, too.

----------
nosy: +benjamin.peterson
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22946>
_______________________________________

From report at bugs.python.org  Wed Nov 26 17:43:11 2014
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Wed, 26 Nov 2014 16:43:11 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417020191.35.0.935353979886.issue22898@psf.upfronthosting.co.za>


A. Jesse Jiryu Davis added the comment:

With warn_4.patch applied I can no longer reproduce my original segfault, looks like the fix works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 18:59:38 2014
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 26 Nov 2014 17:59:38 +0000
Subject: [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417024778.95.0.763632507504.issue22949@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I notice that it puts the inline flags at the end. It would be better to put them at the start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22949>
_______________________________________

From report at bugs.python.org  Wed Nov 26 19:48:03 2014
From: report at bugs.python.org (Friedrich Spee von Langenfeld)
Date: Wed, 26 Nov 2014 18:48:03 +0000
Subject: [issue22950] ASLR and DEP protection
Message-ID: <1417027683.15.0.168800959084.issue22950@psf.upfronthosting.co.za>


New submission from Friedrich Spee von Langenfeld:

Are all binary files of a Python installation protected with techniques like Adress Space Layout Randomization and Data Execution Prevention? How can someone check this with an PE Editor or something similar? I know that this seems not to be a matter of great interest, but it would set an example to other programmers: Security is not an optional feature, but a necessity. Many thanks in advance.

----------
components: Build
messages: 231723
nosy: Friedrich.Spee.von.Langenfeld
priority: normal
severity: normal
status: open
title: ASLR and DEP protection
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22950>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:47:16 2014
From: report at bugs.python.org (jaebae17)
Date: Wed, 26 Nov 2014 19:47:16 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
Message-ID: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>


New submission from jaebae17:

The help page for the built-in repr() states ''' For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval()...'''

This holds true for non-inf/nan values of float():
>>> eval(repr(float('0.0')))
0.0

But for inf, -inf, and nan it does not:
>>> eval(repr(float('inf')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'inf' is not defined

Expected return from repr(float('inf')) was "float('inf')", but perhaps 'inf' response has too much history at this point to be changed.

----------
messages: 231724
nosy: jaebae17
priority: normal
severity: normal
status: open
title: unexpected return from float.__repr__() for inf, -inf, nan
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22951>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:52:19 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Nov 2014 19:52:19 +0000
Subject: [issue22950] ASLR and DEP protection
In-Reply-To: <1417027683.15.0.168800959084.issue22950@psf.upfronthosting.co.za>
Message-ID: <1417031539.32.0.742872322216.issue22950@psf.upfronthosting.co.za>


Ned Deily added the comment:

Python is supported on many platforms and the techniques and support for address layout randomization and similar techniques vary greatly.  Also, in many cases, Python is being used from a distribution built by a third-party, such as an operating system vendor or a third-party package manager, using their own preferred tooling and configurations.  In the specific case of Windows builds downloadable from python.org, it appears that ASLR and DEP have been enabled as of Python 3.4 (see Issue16632).

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22950>
_______________________________________

From report at bugs.python.org  Wed Nov 26 20:58:42 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Nov 2014 19:58:42 +0000
Subject: [issue22940] readline does not offer partial saves
In-Reply-To: <1416925857.17.0.992509064643.issue22940@psf.upfronthosting.co.za>
Message-ID: <20141126195834.116322.61872@psf.io>


Roundup Robot added the comment:

New changeset ff00588791be by Benjamin Peterson in branch 'default':
add readline.append_history_file (closes #22940)
https://hg.python.org/cpython/rev/ff00588791be

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22940>
_______________________________________

From report at bugs.python.org  Wed Nov 26 21:08:52 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Nov 2014 20:08:52 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1417032532.08.0.866688386798.issue19676@psf.upfronthosting.co.za>


Ned Deily added the comment:

../../source/Python/codecs.c:1022:16: error: use of undeclared identifier 'out'; did you
      mean 'outp'?
        assert(out == start + ressize);
               ^~~
               outp

----------
nosy: +ned.deily
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Wed Nov 26 21:25:37 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 26 Nov 2014 20:25:37 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
In-Reply-To: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>
Message-ID: <1417033537.57.0.936185489135.issue22951@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/issue22951>
_______________________________________

From report at bugs.python.org  Wed Nov 26 21:27:44 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Nov 2014 20:27:44 +0000
Subject: [issue19676] Add the "namereplace" error handler
In-Reply-To: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>
Message-ID: <1417033664.59.0.729722428092.issue19676@psf.upfronthosting.co.za>


Ned Deily added the comment:

Fixed in ce8a8531d29a

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19676>
_______________________________________

From report at bugs.python.org  Wed Nov 26 21:55:18 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 26 Nov 2014 20:55:18 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417035318.69.0.936446386249.issue22898@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> out can be b'Done.\r\n'. Use self.assertIn.

Ok, new patch attached.


>> If both patches were to be included, the test case in warn_4.patch would test the above patch and not the changes made in Python/_warnings.c.
> You can test err for warning message.

In the case where PyExc_RecursionErrorInst would not leak frames, the code path followed by the test case would not run any of the changes made in _warnings.c.


> The traceback should be cleared before decrementing the reference count. And only if Py_REFCNT(v) is 2.

I believe that attempting to fix the frames leak by clearing the traceback implies the following changes:
    * The previous patch to PyErr_PrintEx()
    * v->context and v->cause should also be tested against equality with PyExc_RecursionErrorInst.
    * In PyErr_PrintEx() the variable v2 may also be PyExc_RecursionErrorInst.
    * The sames change should also be done when freeing the exception value at least:
        in PyErr_WriteUnraisable() called when an exception occurs during finalization
        in PyErr_Restore()
        [1] when sys.last_value is cleared in PyImport_Cleanup()
And that would miss the case [1] where sys.last_value is set to None by some python user code.

Note [1]:
Unless it is acceptable to clear the PyExc_RecursionErrorInst traceback even when sys.last_value has been set (then Py_REFCNT(v) is 3 instead of 2).

Not sure if this is worth the trouble.

----------
Added file: http://bugs.python.org/file37289/warn_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Wed Nov 26 22:03:20 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Nov 2014 21:03:20 +0000
Subject: [issue22940] readline does not offer partial saves
In-Reply-To: <1416925857.17.0.992509064643.issue22940@psf.upfronthosting.co.za>
Message-ID: <20141126210305.55101.97798@psf.io>


Roundup Robot added the comment:

New changeset c8bcede1b37a by Ned Deily in branch 'default':
Issue 22940: fixes to editline support
https://hg.python.org/cpython/rev/c8bcede1b37a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22940>
_______________________________________

From report at bugs.python.org  Wed Nov 26 22:35:09 2014
From: report at bugs.python.org (Davin Potts)
Date: Wed, 26 Nov 2014 21:35:09 +0000
Subject: [issue22952] multiprocessing doc introduction not in affirmative tone
Message-ID: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>


New submission from Davin Potts:

The introduction section of the multiprocessing module's documentation does not adhere to the python dev guidelines for keeping things in the affirmative tone.

Problem description:
Specifically, the intro section contains a warning block that, while conveying something important, both 1) potentially creates worry/concern in the mind of the reader new to this module, and 2) ideally belongs somewhere more relevant/appropriate than the intro section.  Also, the intro section contains an example code block that does not attempt to provide a simple example to advance understanding and boost the reader's confidence through trying this example -- instead it demonstrates what not to do and the consequences of doing so in an attempt to drive home one key point with the reader.

Suggested changes:
* The warning text block can be moved to a section discussing synchronization without losing the important information being shared or sharing it too late to be useful.
* To make the key point to the reader in the intro about the availability/importability of functions, etc. to child processes, the affirmative tone can be used in describing the good pattern/practice being employed in a usable/valid/working example.


Further comment:  Similar issues could be raised with other parts of the multiprocessing docs but this issue is concerned only with the intro section.

----------
assignee: docs at python
components: Documentation
messages: 231731
nosy: davin, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing doc introduction not in affirmative tone
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22952>
_______________________________________

From report at bugs.python.org  Wed Nov 26 22:45:08 2014
From: report at bugs.python.org (Davin Potts)
Date: Wed, 26 Nov 2014 21:45:08 +0000
Subject: [issue22952] multiprocessing doc introduction not in affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417038308.85.0.925512024605.issue22952@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attached is a proposed patch for the 2.7 branch.

It provides 2 changes to the documentation:
1) Moves the warning text block regarding synchronization functionality not necessarily being available on all systems to the "Synchronization between processes" section (Section 16.6.1.3 in the 2.7 docs).
2) Adds a paragraph introducing (in the affirmative tone) a good/common practice as shown in a working example to drive home the key point about importability by subprocesses.  The original example of what not to do has been preserved by moving it to the "Using a pool of workers" section (Section 16.6.1.5 in the 2.7 docs).

Note that this patch does not attempt to resolve the issue of :class:`Pool` not being resolved by Sphinx to properly point at the multiprocessing.pool.Pool class description.  This issue appears addressed in the 3.4 docs but not in some other branches.

----------
keywords: +patch
Added file: http://bugs.python.org/file37290/multiprocessing_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22952>
_______________________________________

From report at bugs.python.org  Thu Nov 27 00:36:12 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 26 Nov 2014 23:36:12 +0000
Subject: [issue22948] Integer type and __add__
In-Reply-To: <1417012345.4.0.50245289459.issue22948@psf.upfronthosting.co.za>
Message-ID: <1417044972.11.0.676991504833.issue22948@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

This is a duplicate of #20692.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22948>
_______________________________________

From report at bugs.python.org  Thu Nov 27 00:52:14 2014
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 26 Nov 2014 23:52:14 +0000
Subject: [issue22953] Windows installer configures system PATH also when
 installing only for current user
Message-ID: <1417045934.78.0.497938457178.issue22953@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck:

To reproduce:
1) Download and run Python 2.7.9rc1 Windows installer.
2) Select "Install just for me."
3) Enable "Add python.exe to Path."
=>
Expected: Current user PATH edited.
Actual: System PATH edited.

----------
components: Installation
messages: 231734
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Windows installer configures system PATH also when installing only for current user
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22953>
_______________________________________

From report at bugs.python.org  Thu Nov 27 00:56:11 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Nov 2014 23:56:11 +0000
Subject: [issue22937] unittest errors can't show locals
In-Reply-To: <1416881182.95.0.816242293699.issue22937@psf.upfronthosting.co.za>
Message-ID: <1417046171.77.0.12047633805.issue22937@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Note that IIRC py.test (a 3rd party module) will show you additional information in the traceback. SO it is definitely possible.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22937>
_______________________________________

From report at bugs.python.org  Thu Nov 27 00:57:05 2014
From: report at bugs.python.org (Tom Tanner)
Date: Wed, 26 Nov 2014 23:57:05 +0000
Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers
 correctly
In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za>
Message-ID: <1417046225.75.0.585204364172.issue21114@psf.upfronthosting.co.za>


Tom Tanner added the comment:

I confirm this fixes a bug.
To reproduce it just add, e.g.

X-Multline-Header: foo
 bar

to your request.
 
It has been fixed in Python 3 with
https://github.com/python/cpython/commit/67dcb80f6e102622e4aa888930d3017fed9834de

----------
nosy: +tanner

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21114>
_______________________________________

From report at bugs.python.org  Thu Nov 27 00:57:11 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 26 Nov 2014 23:57:11 +0000
Subject: [issue22948] Integer type and __add__
In-Reply-To: <1417012345.4.0.50245289459.issue22948@psf.upfronthosting.co.za>
Message-ID: <1417046231.41.0.55650090374.issue22948@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Tutorial and  FAQ: how to call a method on an int

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22948>
_______________________________________

From report at bugs.python.org  Thu Nov 27 01:03:13 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Nov 2014 00:03:13 +0000
Subject: [issue22937] unittest errors can't show locals
In-Reply-To: <1416881182.95.0.816242293699.issue22937@psf.upfronthosting.co.za>
Message-ID: <1417046593.08.0.048054277059.issue22937@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sorry, I missed the part where you said "we can't depend on PyPI".

There already is something in the stdlib that may be close enough to what you're looking for -- checkout cgitb.py.  The following might even work:

import cgitb
cgitb.enable(format='text')

That code is very old and primarily meant for CGI scripts (that shows how old it is!) but it still works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22937>
_______________________________________

From report at bugs.python.org  Thu Nov 27 01:03:34 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Nov 2014 00:03:34 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1417046614.04.0.670384484075.issue22936@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Check out the cgitb stdlib module.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Thu Nov 27 01:05:00 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Nov 2014 00:05:00 +0000
Subject: [issue22953] Windows installer configures system PATH also when
 installing only for current user
In-Reply-To: <1417045934.78.0.497938457178.issue22953@psf.upfronthosting.co.za>
Message-ID: <1417046700.16.0.632237417214.issue22953@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22953>
_______________________________________

From report at bugs.python.org  Thu Nov 27 01:34:40 2014
From: report at bugs.python.org (Steve Dower)
Date: Thu, 27 Nov 2014 00:34:40 +0000
Subject: [issue22953] Windows installer configures system PATH also when
 installing only for current user
In-Reply-To: <1417045934.78.0.497938457178.issue22953@psf.upfronthosting.co.za>
Message-ID: <1417048480.56.0.0931277157038.issue22953@psf.upfronthosting.co.za>


Steve Dower added the comment:

The "just for me" option isn't actually a per-user install, it actually just restricts use of the core Python DLL to Python itself and not any other applications that may want to use it (by putting the DLL in the Python folder instead of the system folder). Basically everything else about this option is a bug that I consider it of scope for 2.7 at this point. If someone else figures out how to fix it, I can try and review the patch, but I'm not intending to figure out the install script well enough to fix it.

For what it's worth, the Python 3.5 installer will have a true per-user option (no admin privileges, no shared files with other users, per-user environment and file associations, etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22953>
_______________________________________

From report at bugs.python.org  Thu Nov 27 01:47:54 2014
From: report at bugs.python.org (James Burke)
Date: Thu, 27 Nov 2014 00:47:54 +0000
Subject: [issue21614] Case sensitivity problem in multiprocessing.
In-Reply-To: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za>
Message-ID: <1417049274.12.0.690249792075.issue21614@psf.upfronthosting.co.za>


James Burke added the comment:

I'm also getting this error.

It appears to me to be caused by the length of the module name rather than case.
mp_bug.py will run fine for me, but if I change it to mp_bug_longname.py then I will get this error.

import multiprocessing
import time

class MP_Bug(multiprocessing.Process):
    def __init__(self):
        multiprocessing.Process.__init__(self)
    def run(test):
        for x in range(1, 10):
            print x
            time.sleep(1)

if __name__ == '__main__':
    p = MP_Bug()
    p.start()

----------
nosy: +James.Burke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21614>
_______________________________________

From report at bugs.python.org  Thu Nov 27 02:36:17 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Nov 2014 01:36:17 +0000
Subject: [issue21614] Case sensitivity problem in multiprocessing.
In-Reply-To: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za>
Message-ID: <1417052177.68.0.033520295524.issue21614@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(Adding Richard as the multiprocessing maintainer, and Christian as the creator of the backport to 2.4/2.5)

Note that on a case-insensitive filesystem, the fopen() call is likely succeeding, and it's the subsequent case_ok() check that's failing. The assumption of case sensitivity is embedded fairly deeply in the import system, as otherwise it makes it pretty easy to accidentally import the same module multiple times under different names.

However, if importing the same module multiple times under different names isn't a concern, then setting PYTHONCASEOK should allow multiprocessing to import the module using the incorrect capitalisation.

More significant changes to the way the standard library's multiprocessing module starts subprocesses on Windows won't be implemented for Python 2.7 - actually fixing the subprocess spawning to work as intended in all cases (as was done in Python 3.4) relies on the import system changes defined in PEP 451. 

In theory, I expect a multiprocessing2 backport could be written that depends on importib2 (to enable Python 3.4+ import semantics in Python 2.7), but I'm not aware of anyone currently working on such a project.

James's comment sounds like a potentially different problem (e.g. there are some hardcoded platform dependent limits on absolute path lengths for module filenames - 255 in the case of Windows)

----------
nosy: +christian.heimes, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21614>
_______________________________________

From report at bugs.python.org  Thu Nov 27 02:37:58 2014
From: report at bugs.python.org (Davin Potts)
Date: Thu, 27 Nov 2014 01:37:58 +0000
Subject: [issue22952] multiprocessing doc introduction not in affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417052278.73.0.61884021565.issue22952@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attached is a proposed patch for the 3.4 branch.

The same modifications are made in this patch as in the patch for the 2.7 branch, with two minor tweaks:
1) The affirmative tone example uses Pool in a with statement as is supported since 3.3.
2) References in the added/moved text are properly resolving (in Sphinx) to the class definition for Pool.


This patch should also work against the 3.3 branch (though should not be applied to 3.2 as the context manager behavior had not yet been added to Pool in 3.2 -- the example in the intro would need changing for this to be applied to 3.2 is all).

----------
Added file: http://bugs.python.org/file37291/multiprocessing_34.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22952>
_______________________________________

From report at bugs.python.org  Thu Nov 27 02:51:45 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Nov 2014 01:51:45 +0000
Subject: [issue22952] multiprocessing doc introduction not in affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417053105.61.0.947731483805.issue22952@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +sbt
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.5 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22952>
_______________________________________

From report at bugs.python.org  Thu Nov 27 03:34:16 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Nov 2014 02:34:16 +0000
Subject: [issue21614] Case sensitivity problem in multiprocessing.
In-Reply-To: <1401479749.7.0.550679517464.issue21614@psf.upfronthosting.co.za>
Message-ID: <1417055656.74.0.814496515402.issue21614@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21614>
_______________________________________

From report at bugs.python.org  Thu Nov 27 03:47:50 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 27 Nov 2014 02:47:50 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1417056470.66.0.199085476172.issue17911@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Belatedly looking at this again: one thing I noticed is that the summary currently loses info if __cause__ is set.

It would be better to follow the PEP 409/415 model and report the "__suppress_context__" flag as part of the summary, rather than dropping the context information.

That allows the decision on whether or not to show the context information to be deferred to display time, rather than discarding it eagerly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Thu Nov 27 04:13:10 2014
From: report at bugs.python.org (Davin Potts)
Date: Thu, 27 Nov 2014 03:13:10 +0000
Subject: [issue22952] multiprocessing doc introduction not in affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417057990.93.0.876510056687.issue22952@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22952>
_______________________________________

From report at bugs.python.org  Thu Nov 27 05:17:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 04:17:18 +0000
Subject: [issue22952] multiprocessing doc introduction not in affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417061838.31.0.794024134213.issue22952@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 It looks like the relevant information has been preserved while adding an example where the module is being used as designed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22952>
_______________________________________

From report at bugs.python.org  Thu Nov 27 05:31:13 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 27 Nov 2014 04:31:13 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1417062673.14.0.908320154024.issue22524@psf.upfronthosting.co.za>


Akira Li added the comment:

To see what happens at syscall level, I've run various implementations
of get_tree_size() functions (see get_tree_size_listdir.diff) with
strace:

get_tree_size_listdir_fd   -- os.listdir(fd) + os.lstat
get_tree_size              -- os.scandir(path) + entry.lstat
get_tree_size_listdir_stat -- os.listdir(path) + os.lstat
get_tree_size_listdir      -- os.listdir(path) + os.path.isdir + os.lstat

Summary: 

- os.listdir() and os.scandir()-based variants use the same number of getdents() syscalls
- and the number of openat, lstat (newfstatat) syscalls is also comparable
  (except for the variant that uses os.path.isdir)

Log:

scandir$ /usr/bin/time strace -fco py.strace ../cpython/python -c 'from benchmark import get_tree_size_listdir_fd as f; import os; print(f(os.open("/usr/", os.O_RDONLY)))' && head -7 py.strace
5535240217
11.29user 8.14system 0:17.78elapsed 109%CPU (0avgtext+0avgdata 13460maxresident)k
0inputs+8outputs (0major+6781minor)pagefaults 0swaps
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 46.51    0.075252           0    264839           newfstatat
 16.88    0.027315           1     50460           getdents
 11.53    0.018660           0     75621           fcntl
  9.74    0.015758           0     50531           close
  6.87    0.011116           0     25214           openat
scandir$ /usr/bin/time strace -fco py.strace ../cpython/python -c 'from benchmark import get_tree_size as f; print(f("/usr/"))' && head -7 py.strace
5535240217
22.56user 8.47system 0:29.77elapsed 104%CPU (0avgtext+0avgdata 13280maxresident)k
0inputs+8outputs (0major+6306minor)pagefaults 0swaps
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 62.00    0.032822           0    239644           lstat
 19.97    0.010570           0     50460           getdents
  8.52    0.004510           0     25215           openat
  6.09    0.003224           0     25326           close
  0.55    0.000292           3        95           mmap
scandir$ /usr/bin/time strace -fco py.strace ../cpython/python -c 'from benchmark import get_tree_size_listdir_stat as f; print(f("/usr/"))' && head -7 py.strace
5535240217
13.70user 6.30system 0:18.84elapsed 106%CPU (0avgtext+0avgdata 13456maxresident)k
0inputs+8outputs (0major+6769minor)pagefaults 0swaps
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 64.79    0.050217           0    264849           lstat
 19.37    0.015011           0     50460           getdents
  8.22    0.006367           0     25215           openat
  5.76    0.004465           0     25326           close
  0.32    0.000247           2       114           mmap
scandir$ /usr/bin/time strace -fco py.strace ../cpython/python -c 'from benchmark import get_tree_size_listdir as f; print(f("/usr/"))' && head -7 py.strace
5535240217
19.53user 10.61system 0:28.16elapsed 107%CPU (0avgtext+0avgdata 13452maxresident)k
0inputs+8outputs (0major+6733minor)pagefaults 0swaps
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.04    0.063050           0    265195     37259 stat
 37.40    0.056086           0    265381           lstat
 11.46    0.017187           0     50460           getdents
  4.82    0.007232           0     25215           openat
  3.43    0.005139           0     25326           close

----------
Added file: http://bugs.python.org/file37292/get_tree_size_listdir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Thu Nov 27 05:31:21 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 27 Nov 2014 04:31:21 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1417062681.05.0.188393864302.issue22524@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Removed file: http://bugs.python.org/file37284/get_tree_size_listdir.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Thu Nov 27 05:59:46 2014
From: report at bugs.python.org (pankaj.s01)
Date: Thu, 27 Nov 2014 04:59:46 +0000
Subject: [issue22954] Logically Dead Code
Message-ID: <1417064386.3.0.793786383436.issue22954@psf.upfronthosting.co.za>


New submission from pankaj.s01:

Hi,
In Python-3.4.2 (latest version), there is logically dead code in function static tp_new_wrapper().

The respective patch has been attached for 
"Python-3.4.2/Objects/typeobject.c"

Thanks $ Regards,
 Pankaj Sharma
(Pankaj.s01 at samsung.com)

----------
files: Python-3.4.2-typeobject.patch
keywords: patch
messages: 231746
nosy: pankaj.s01
priority: normal
severity: normal
status: open
title: Logically Dead Code
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37293/Python-3.4.2-typeobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22954>
_______________________________________

From report at bugs.python.org  Thu Nov 27 06:06:11 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 05:06:11 +0000
Subject: [issue22954] Logically Dead Code
In-Reply-To: <1417064386.3.0.793786383436.issue22954@psf.upfronthosting.co.za>
Message-ID: <20141127050606.84291.15262@psf.io>


Roundup Robot added the comment:

New changeset a498e599ce6a by Benjamin Peterson in branch '3.4':
remove tautological condition (closes #22954)
https://hg.python.org/cpython/rev/a498e599ce6a

New changeset d502b5d60e00 by Benjamin Peterson in branch 'default':
merge 3.4 (#22954)
https://hg.python.org/cpython/rev/d502b5d60e00

New changeset ec21b41e588b by Benjamin Peterson in branch '2.7':
remove tautological condition (closes #22954)
https://hg.python.org/cpython/rev/ec21b41e588b

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22954>
_______________________________________

From report at bugs.python.org  Thu Nov 27 06:18:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 05:18:16 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <20141127051810.55125.96054@psf.io>


Roundup Robot added the comment:

New changeset ebb8865dcf54 by Ethan Furman in branch '3.4':
(3.4) Issue22780: reword NotImplemented docs to emphasise should
https://hg.python.org/cpython/rev/ebb8865dcf54

New changeset b6ee02acaae9 by Ethan Furman in branch 'default':
Issue22780: reword NotImplemented docs to emphasise should
https://hg.python.org/cpython/rev/b6ee02acaae9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22780>
_______________________________________

From report at bugs.python.org  Thu Nov 27 06:20:44 2014
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 27 Nov 2014 05:20:44 +0000
Subject: [issue22780] NotImplemented doc section needs update
In-Reply-To: <1414797071.1.0.897757965412.issue22780@psf.upfronthosting.co.za>
Message-ID: <1417065644.15.0.505609579094.issue22780@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thank you, Berker.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22780>
_______________________________________

From report at bugs.python.org  Thu Nov 27 07:00:27 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 06:00:27 +0000
Subject: [issue22924] Use of deprecated cgi.escape
In-Reply-To: <1416737175.16.0.367831967609.issue22924@psf.upfronthosting.co.za>
Message-ID: <1417068027.97.0.225118192914.issue22924@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If this looks right to you, please go ahead an apply.

----------
assignee: rhettinger -> serhiy.storchaka
keywords: +patch
Added file: http://bugs.python.org/file37294/cgi2html.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22924>
_______________________________________

From report at bugs.python.org  Thu Nov 27 07:10:31 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 06:10:31 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417068631.91.0.789603487732.issue21514@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, can you take this one.  The patch passes both mine and Bob's review; however, it doesn't apply cleanly to 2.7 and 3.4.  I haven't had the time to do the needed backports.

----------
assignee: rhettinger -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21514>
_______________________________________

From report at bugs.python.org  Thu Nov 27 07:33:03 2014
From: report at bugs.python.org (Antony Lee)
Date: Thu, 27 Nov 2014 06:33:03 +0000
Subject: [issue22955] Pickling of methodcaller and attrgetter
Message-ID: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>


New submission from Antony Lee:

methodcaller and attrgetter objects seem to be picklable, but in fact the pickling is erroneous:

>>> import operator, pickle
>>> pickle.loads(pickle.dumps(operator.methodcaller("foo")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: methodcaller needs at least one argument, the method name
>>> pickle.loads(pickle.dumps(operator.attrgetter("foo")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: attrgetter expected 1 arguments, got 0

When looking at the pickle disassembly, it seems that the argument to the constructor is indeed not pickled.

>>> import pickletools; pickletools.dis(pickle.dumps(operator.methodcaller("foo")))
    0: \x80 PROTO      3
    2: c    GLOBAL     'operator methodcaller'
   25: q    BINPUT     0
   27: )    EMPTY_TUPLE
   28: \x81 NEWOBJ
   29: q    BINPUT     1
   31: .    STOP
highest protocol among opcodes = 2

----------
components: Library (Lib)
messages: 231752
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Pickling of methodcaller and attrgetter
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Thu Nov 27 07:43:37 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 06:43:37 +0000
Subject: [issue22955] Pickling of methodcaller and attrgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417070617.69.0.348781354183.issue22955@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Thu Nov 27 07:47:59 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 06:47:59 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1417070879.19.0.905811894019.issue22609@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This looks good.  Go ahead and apply the first version of the patch.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Thu Nov 27 11:03:24 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 27 Nov 2014 10:03:24 +0000
Subject: [issue22799] wrong time.timezone
In-Reply-To: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za>
Message-ID: <1417082604.66.0.91891756594.issue22799@psf.upfronthosting.co.za>


Akira Li added the comment:

This issue could be fixed using sync-time-timezone-attr-with-c.diff patch from http://bugs.python.org/issue22798

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22799>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:01:44 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Nov 2014 12:01:44 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
In-Reply-To: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>
Message-ID: <1417089704.11.0.816284404735.issue22951@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Previously discussed here: http://bugs.python.org/issue1732212

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22951>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:07:26 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 27 Nov 2014 12:07:26 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
In-Reply-To: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>
Message-ID: <1417090046.66.0.00276638349757.issue22951@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

A couple of points against this change:

1. If repr(float('inf')) became "float('inf')", we'd lose the invariant that float(repr(x)) recovers x for all floats (including infinities and nans).

2. Since repr and str are currently identical for floats, this change would either end up modifying str too, or making str and repr different;  neither option is particularly palatable.  While I can see a case for the repr returning something eval-able, I think the str of an infinity should remain as "inf" or "-inf".

3. For consistency, you'd need to change the complex and Decimal outputs, too.

4. The current output of repr and str is directly parseable by most other languages.

So -1 from me.

(Changing type to 'enhancement'; we use 'behaviour' for bugs, and this isn't one. :-)

----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22951>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:19:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 12:19:09 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
In-Reply-To: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>
Message-ID: <1417090749.5.0.142668658648.issue22951@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Workaround:

>>> eval('inf', {'inf': float('inf')})
inf

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22951>
_______________________________________

From report at bugs.python.org  Thu Nov 27 13:33:21 2014
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 27 Nov 2014 12:33:21 +0000
Subject: [issue20530] Change the text signature format (again) to be more
 robust
In-Reply-To: <1391695750.05.0.146053236138.issue20530@psf.upfronthosting.co.za>
Message-ID: <1417091601.01.0.446849044717.issue20530@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Actually this is the wrong issue for that observation.  You want the issue where yselivanov added emitting the "/" to pydoc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20530>
_______________________________________

From report at bugs.python.org  Thu Nov 27 14:38:39 2014
From: report at bugs.python.org (Markus Elfring)
Date: Thu, 27 Nov 2014 13:38:39 +0000
Subject: [issue22956] Improved support for prepared SQL statements
Message-ID: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za>


New submission from Markus Elfring:

An interface for parameterised SQL statements (working with placeholders) is provided by the execute() method from the Cursor class at the moment.
https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor.execute

I assume that the "SQL Statement Object" from the SQLite C interface is reused there already.
http://sqlite.org/c3ref/stmt.html

I imagine that it will be more efficient occasionally to offer also a base class like "prepared_statement" so that the parameter specification does not need to be parsed for every passed command.
I suggest to improve corresponding preparation and compilation possibilities.

----------
components: Extension Modules
messages: 231759
nosy: elfring
priority: normal
severity: normal
status: open
title: Improved support for prepared SQL statements

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22956>
_______________________________________

From report at bugs.python.org  Thu Nov 27 14:38:47 2014
From: report at bugs.python.org (Bruno Cauet)
Date: Thu, 27 Nov 2014 13:38:47 +0000
Subject: [issue18032] Optimization for set/frozenset.issubset()
In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za>
Message-ID: <1417095527.36.0.696431757909.issue18032@psf.upfronthosting.co.za>


Bruno Cauet added the comment:

Here is an updated patch based on Dustin's work with Josh's comments. I also added a test which takes forever on an unpatched python interpreter.

Since it's a performance issue, I've benchmarked the results. They don't change for the most part (argument is a set or a dict) but they're way better for iterables.
For every type of argument I test 1 case where "set.issubset" returns True and 1 case where it returns False.


(a) simple argument (results unchanged)

$ ./python -m timeit -s "s1 = set(range(1000)); s2 = set(range(1000))" "s1.issubset(s2)"
Unpatched: 10000 loops, best of 3: 63.7 usec per loop
Patched:   10000 loops, best of 3: 63.5 usec per loop

$ ./python -m timeit -s "s1 = set(range(1000)); s2 = set(range(1, 1000))" "s1.issubset(s2)"
Unpatched: 1000000 loops, best of 3: 0.248 usec per loop
Patched:   1000000 loops, best of 3: 0.25 usec per loop

$ ./python -m timeit -s "s1 = set(range(1000)); s2 = dict(enumerate(range(1000)))" "s1.issubset(s2)"
Unpatched: 10000 loops, best of 3: 107 usec per loop
Patched: 10000 loops, best of 3: 108 usec per loop

$ ./python -m timeit -s "s1 = set(range(1000)); s2 = dict(enumerate(range(1, 1000)))" "s1.issubset(s2)"
Unpatched: 10000 loops, best of 3: 43.5 usec per loop
Patched:   10000 loops, best of 3: 42.6 usec per loop


(b) iterable argument (speed improvement)

1) no improvements/slight degradation when everything must be consumed

$ ./python -m timeit -s "s1 = set(range(1000))" "s1.issubset(range(1000))"
Unpatched: 1000 loops, best of 3: 263 usec per loop
Patched:   1000 loops, best of 3: 263 usec per loop

$ ./python -m timeit -s "s1 = set(range(1000))" "s1.issubset(range(1, 1000))"
Unpatched: 10000 loops, best of 3: 201 usec per loop
Patched:   1000 loops, best of 3: 259 usec per loop

$ ./python -m timeit -s "s1 = set(range(100))" "s1.issubset(range(1, 1000))"
Unpatched: 1000 loops, best of 3: 198 usec per loop
Patched:   1000 loops, best of 3: 218 usec per loop

2) tremendous improvements when it can return early

$ ./python -m timeit -s "s1 = set(range(100))" "s1.issubset(range(1000))"
Unpatched: 1000 loops, best of 3: 209 usec per loop
Patched:   100000 loops, best of 3: 12.1 usec per loop

$ ./python -m timeit -s "s1 = set('a'); s2 = ['a'] + ['b'] * 10000" "s1.issubset(s2)"
Unpatched: 1000 loops, best of 3: 368 usec per loop
Patched:   1000000 loops, best of 3: 0.934 usec per loop

$ ./python -m timeit -s "s1 = set('a'); from itertools import repeat" "s1.issubset(repeat('a'))"
Unpatched: NEVER FINISHES
Patched:   1000000 loops, best of 3: 1.33 usec per loop

----------
nosy: +bru, haypo
Added file: http://bugs.python.org/file37295/0001-Improve-set.issubset-performance-on-iterables.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18032>
_______________________________________

From report at bugs.python.org  Thu Nov 27 14:50:39 2014
From: report at bugs.python.org (Markus Elfring)
Date: Thu, 27 Nov 2014 13:50:39 +0000
Subject: [issue22957] Multi-index Containers Library
Message-ID: <1417096239.96.0.247692729349.issue22957@psf.upfronthosting.co.za>


New submission from Markus Elfring:

I find a data structure like it is provided by the "Boost Multi-index Containers Library" interesting for efficient data processing.
http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/index.html

How are the chances to integrate a class library with similar functionality into the Python software infrastructure?

----------
components: Extension Modules
messages: 231761
nosy: elfring
priority: normal
severity: normal
status: open
title: Multi-index Containers Library
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22957>
_______________________________________

From report at bugs.python.org  Thu Nov 27 14:52:21 2014
From: report at bugs.python.org (Markus Elfring)
Date: Thu, 27 Nov 2014 13:52:21 +0000
Subject: [issue22956] Improved support for prepared SQL statements
In-Reply-To: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za>
Message-ID: <1417096341.22.0.0583467404695.issue22956@psf.upfronthosting.co.za>


Changes by Markus Elfring <elfring at users.sourceforge.net>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22956>
_______________________________________

From report at bugs.python.org  Thu Nov 27 14:59:36 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Nov 2014 13:59:36 +0000
Subject: [issue22955] Pickling of methodcaller and attrgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417096776.25.0.5169861819.issue22955@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou, serhiy.storchaka
type:  -> enhancement
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Thu Nov 27 15:00:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 14:00:06 +0000
Subject: [issue22924] Use of deprecated cgi.escape
In-Reply-To: <1416737175.16.0.367831967609.issue22924@psf.upfronthosting.co.za>
Message-ID: <1417096806.53.0.146150446844.issue22924@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

highlight.py contains a code to support Python 2:

try:
    import builtins
except ImportError:
    import __builtin__ as builtins

If Python 2 should be supported, there is no the html module in Python 2. Otherwise this workaround can be dropped.

----------
Added file: http://bugs.python.org/file37296/cgi2html2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22924>
_______________________________________

From report at bugs.python.org  Thu Nov 27 15:54:56 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 14:54:56 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <20141127145451.55115.84753@psf.io>


Roundup Robot added the comment:

New changeset 816c15fe5812 by Serhiy Storchaka in branch '3.4':
Issue #22609: Constructors and update methods of mapping classes in the
https://hg.python.org/cpython/rev/816c15fe5812

New changeset 88ab046fdd8a by Serhiy Storchaka in branch 'default':
Issue #22609: Constructors and update methods of mapping classes in the
https://hg.python.org/cpython/rev/88ab046fdd8a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Thu Nov 27 16:41:47 2014
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 27 Nov 2014 15:41:47 +0000
Subject: [issue22957] Multi-index Containers Library
In-Reply-To: <1417096239.96.0.247692729349.issue22957@psf.upfronthosting.co.za>
Message-ID: <1417102907.0.0.0818325638252.issue22957@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

You should discuss this on the python-ideas mailing list. Then if there's traction there, we'll re-open this issue. Please reference this issue number when starting the discussion on python-ideas so we can find it later.

----------
nosy: +eric.smith
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22957>
_______________________________________

From report at bugs.python.org  Thu Nov 27 16:51:03 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 15:51:03 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <20141127155047.126772.76436@psf.io>


Roundup Robot added the comment:

New changeset cd1ead4feddf by Serhiy Storchaka in branch '3.4':
Issue #22609: Revert changes in UserDict. They conflicted with existing tests.
https://hg.python.org/cpython/rev/cd1ead4feddf

New changeset 167d51a54de2 by Serhiy Storchaka in branch 'default':
Issue #22609: Revert changes in UserDict. They conflicted with existing tests.
https://hg.python.org/cpython/rev/167d51a54de2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Thu Nov 27 17:00:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 16:00:51 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1417104051.23.0.758106135693.issue22609@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately there is existing test for current behavior of UserDict:

    self.assertEqual(collections.UserDict(dict=[('one',1), ('two',2)]), d2)

This looks wrong to me and I think we should break compatibility here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Thu Nov 27 17:13:23 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 16:13:23 +0000
Subject: [issue22958] Constructors of weakref mapping classes don't accept
 "self" and "dict" keyword arguments
Message-ID: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Dict-like types in the weakref module (WeakValueDictionary and WeakKeyDictionary) don't allow to specify key-value pair as keyword arguments if key is "self" or "dict".

>>> import weakref
>>> class A: pass
... 
>>> a = A()
>>> d = weakref.WeakValueDictionary(spam=a)
>>> list(d.items())
[('spam', <__main__.A object at 0xb6f3f88c>)]
>>> weakref.WeakValueDictionary(self=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got multiple values for argument 'self'
>>> weakref.WeakValueDictionary(dict=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/weakref.py", line 114, in __init__
    self.update(*args, **kw)
  File "/home/serhiy/py/cpython/Lib/weakref.py", line 261, in update
    dict = type({})(dict)
TypeError: 'A' object is not iterable
>>> d = weakref.WeakValueDictionary()
>>> d.update(spam=a)
>>> list(d.items())
[('spam', <__main__.A object at 0xb6f3f88c>)]
>>> d.update(self=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: update() got multiple values for argument 'self'
>>> d.update(dict=a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/weakref.py", line 261, in update
    dict = type({})(dict)
TypeError: 'A' object is not iterable

Related issue for the collections module is issue22609. I think weakref mapping classes should be fixed in the same manner.

----------
components: Library (Lib)
messages: 231767
nosy: fdrake, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Constructors of weakref mapping classes don't accept "self" and "dict" keyword arguments
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22958>
_______________________________________

From report at bugs.python.org  Thu Nov 27 17:19:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 16:19:51 +0000
Subject: [issue22955] Pickling of methodcaller and attrgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417105191.16.0.353421373257.issue22955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this issue needs different solutions for 3.5 and maintained releases. We can implement the pickling of methodcaller, attrgetter and itemgetter in 3.5 (I agree this is good idea). And it would be good if pickling of these types will raise an exception in maintained releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:05:38 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 17:05:38 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <20141127170510.69779.80489@psf.io>


Roundup Robot added the comment:

New changeset 3dfe4f0c626b by Serhiy Storchaka in branch '2.7':
Issue #22609: Constructors and update methods of mapping classes in the
https://hg.python.org/cpython/rev/3dfe4f0c626b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Thu Nov 27 18:51:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 17:51:16 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <20141127175112.116318.70029@psf.io>


Roundup Robot added the comment:

New changeset 7e534e18a99a by Serhiy Storchaka in branch '2.7':
Issue #21514: The documentation of the json module now refers to new JSON RFC
https://hg.python.org/cpython/rev/7e534e18a99a

New changeset 89bb4384f1e1 by Serhiy Storchaka in branch '3.4':
Issue #21514: The documentation of the json module now refers to new JSON RFC
https://hg.python.org/cpython/rev/89bb4384f1e1

New changeset aced2548345a by Serhiy Storchaka in branch 'default':
Issue #21514: The documentation of the json module now refers to new JSON RFC
https://hg.python.org/cpython/rev/aced2548345a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21514>
_______________________________________

From report at bugs.python.org  Thu Nov 27 19:11:06 2014
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 27 Nov 2014 18:11:06 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417111866.74.0.37847609521.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Thanks Serhiy!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21514>
_______________________________________

From report at bugs.python.org  Thu Nov 27 19:22:25 2014
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 27 Nov 2014 18:22:25 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1417112545.26.0.372764864494.issue13212@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Ping!
Seems like this should be closed since the new RFC explicitly legalizes the feature in question and since the docs explicitly warn about the interoperability of the feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:08:19 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Nov 2014 19:08:19 +0000
Subject: [issue22666] email.Header no encoding of unicode strings containing
 newlines
In-Reply-To: <1413637685.41.0.262065905558.issue22666@psf.upfronthosting.co.za>
Message-ID: <1417115299.53.0.300294560165.issue22666@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'd have to double check, but I think having /r /n etc encoded in an encopded string is illegal per the rfcs.  It should be, anyway.  So IMO the bug is encoding them at all, but at this point we probably can't fix it for bacward compatibility reasons.

I'm leaving this issue open for the moment because I do want to check the rfc, and also double check what the new API does in this situation (and make sure there are tests).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22666>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:29:04 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Nov 2014 19:29:04 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417116544.14.0.455698191064.issue21514@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21514>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:31:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 19:31:05 +0000
Subject: [issue21514] update json module docs in light of RFC 7159 & ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417116665.4.0.0703604941148.issue21514@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Chris for your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21514>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:31:46 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 19:31:46 +0000
Subject: [issue22955] Pickling of methodcaller and attrgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417116706.68.0.848898981415.issue22955@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/issue22955>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:34:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 19:34:05 +0000
Subject: [issue13212] json library is decoding/encoding when it should not
In-Reply-To: <1318960832.41.0.586770861075.issue13212@psf.upfronthosting.co.za>
Message-ID: <1417116845.25.0.914166119443.issue13212@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13212>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:42:39 2014
From: report at bugs.python.org (zodalahtathi)
Date: Thu, 27 Nov 2014 19:42:39 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
Message-ID: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>


New submission from zodalahtathi:

http.client.HTTPSConnection has both a check_hostname parameter, and a context parameter to pass an already setup SSL context.
When check_hostname is not set and thus is None, and when passing a SSL context set to NOT check hostnames, ie:

import http.client
import ssl

ssl_context = ssl.create_default_context() 
ssl_context.check_hostname = False
https = http.client.HTTPSConnection(..., context=ssl_context)

The https object WILL check hostname.

In my opinion the line :
https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1207
            will_verify = context.verify_mode != ssl.CERT_NONE

Should be changed to:
            will_verify = (context.verify_mode != ssl.CERT_NONE) and (context.check_hostname)

----------
components: Library (Lib)
messages: 231775
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:46:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 19:46:14 +0000
Subject: [issue22819] Python3.4: xml.sax.saxutils.XMLGenerator.__init__ fails
 with pythonw.exe
In-Reply-To: <1415445430.26.0.203405541468.issue22819@psf.upfronthosting.co.za>
Message-ID: <1417117574.55.0.254572558666.issue22819@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/issue22819>
_______________________________________

From report at bugs.python.org  Thu Nov 27 20:50:11 2014
From: report at bugs.python.org (Flavio Grossi)
Date: Thu, 27 Nov 2014 19:50:11 +0000
Subject: [issue22666] email.Header no encoding of unicode strings containing
 newlines
In-Reply-To: <1413637685.41.0.262065905558.issue22666@psf.upfronthosting.co.za>
Message-ID: <1417117811.17.0.838110994858.issue22666@psf.upfronthosting.co.za>


Flavio Grossi added the comment:

Hi, and thank you for your answer.

However this is not strictly related to the newline, but also to some small idiosyncrasies and different behavior among py2 and py3 (and even in py2 using Header() or Charset()):

# py2.7, non-unicode str
>>> H('test', 'utf-8').encode()
'=?utf-8?q?test?='

>>> Charset('utf-8').header_encode('test')
'=?utf-8?q?test?='


# py2.7, unicode str
>>> H(u'test', 'utf-8').encode()   # this is the only different result
'test'

>>> Charset('utf-8').header_encode(u'test')
u'=?utf-8?q?test?='



# py3.4, unicode
>>> H('test', 'utf-8').encode()                                            
'=?utf-8?q?test?='                                                      
                
# py3.4, bytes                                                                
>>> H(b'test', 'utf-8').encode()                                             
'=?utf-8?q?test?='


As you can see, the only when using unicode strings in py2.7 no header encoding is done if the unicode string contains only ascii chars.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22666>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:17:05 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 20:17:05 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <20141127201659.69777.19095@psf.io>


Roundup Robot added the comment:

New changeset 27ae1a476ef7 by Serhiy Storchaka in branch '3.4':
Issue #22915: SAX parser now supports files opened with file descriptor or
https://hg.python.org/cpython/rev/27ae1a476ef7

New changeset ce9881eecfb4 by Serhiy Storchaka in branch 'default':
Issue #22915: SAX parser now supports files opened with file descriptor or
https://hg.python.org/cpython/rev/ce9881eecfb4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:23:06 2014
From: report at bugs.python.org (zodalahtathi)
Date: Thu, 27 Nov 2014 20:23:06 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
Message-ID: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>


New submission from zodalahtathi:

When using xmlrpc.server it is possible (despite being intrusive) to use a custom SSL context, ie:

import ssl
import xmlrpc.server

rpc_server = xmlrpc.server.SimpleXMLRPCServer(...)
ssl_context = ssl.SSLContext()
# setup the context ...
rpc_server.socket = ssl_context.wrap_socket(rpc_server.socket, ...)

However it is not possible (unless using some ugly monkey patching, which I am ashamed of writing) to do the same for xmlrpc.client.

xmlrpc.client.ServerProxy() could accept a context constructor, and pass it to the SafeTransport instance, and then to the http.client.HTTPSConnection instance (https://hg.python.org/cpython/file/3.4/Lib/xmlrpc/client.py#l1338).

I would allow passing a SSL context more secure than the default one, and thus improve security.

----------
components: Library (Lib)
messages: 231778
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: xmlrpc.client.ServerProxy() should accept a custom SSL context parameter
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:30:59 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 27 Nov 2014 20:30:59 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <1417120259.56.0.233297442185.issue22960@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:50:52 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Nov 2014 20:50:52 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417121452.82.0.649073275386.issue22906@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a doc patch for itertools.

----------
Added file: http://bugs.python.org/file37297/itertoolsdoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:53:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 20:53:22 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1417121602.2.0.380461954212.issue22915@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Jocelyn, in both cases the argument of parse() is a file object with integer name. Tests use one of simplest way to create such object.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Thu Nov 27 21:59:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 20:59:24 +0000
Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...)
In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za>
Message-ID: <1417121964.0.0.604572037133.issue10590@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There was no significant motion in the direction of fixing XML security issues. May be resolve issue2175 first?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10590>
_______________________________________

From report at bugs.python.org  Thu Nov 27 22:10:16 2014
From: report at bugs.python.org (Jocelyn)
Date: Thu, 27 Nov 2014 21:10:16 +0000
Subject: [issue22915] sax.parser cannot get xml data from a subprocess pipe
In-Reply-To: <1416614051.05.0.415744285702.issue22915@psf.upfronthosting.co.za>
Message-ID: <1417122616.45.0.108154301564.issue22915@psf.upfronthosting.co.za>


Jocelyn added the comment:

Ok, I understand your tests now.

Thanks for the fixes !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22915>
_______________________________________

From report at bugs.python.org  Thu Nov 27 22:57:27 2014
From: report at bugs.python.org (Christian Boos)
Date: Thu, 27 Nov 2014 21:57:27 +0000
Subject: [issue16561] bdist_wininst installers don't use UAC, then crash
In-Reply-To: <1353960153.53.0.844150162265.issue16561@psf.upfronthosting.co.za>
Message-ID: <1417125447.69.0.894120879728.issue16561@psf.upfronthosting.co.za>


Christian Boos added the comment:

Ping. Probably too late for 2.7.9, but the patch is about adding a check a null pointer dereference and the follow-up crash, so someone might be interested to commit it, or a similar fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16561>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:15:52 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 22:15:52 +0000
Subject: [issue18905] pydoc -p 0 says the server is available at localhost:0
In-Reply-To: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>
Message-ID: <20141127221543.69795.83507@psf.io>


Roundup Robot added the comment:

New changeset ac7f3161aa53 by Serhiy Storchaka in branch '2.7':
Issue #18905: "pydoc -p 0" now outputs actually used port.  Based on patch by
https://hg.python.org/cpython/rev/ac7f3161aa53

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18905>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:15:52 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 22:15:52 +0000
Subject: [issue22314] pydoc.py: TypeError with a $LINES defined to anything
In-Reply-To: <1409491027.45.0.991041704506.issue22314@psf.upfronthosting.co.za>
Message-ID: <20141127221543.69795.83897@psf.io>


Roundup Robot added the comment:

New changeset 50808dffd0bb by Serhiy Storchaka in branch '2.7':
Issue #22314: pydoc now works when the LINES environment variable is set.
https://hg.python.org/cpython/rev/50808dffd0bb

New changeset c6182a7e75fa by Serhiy Storchaka in branch '3.4':
Issue #22314: pydoc now works when the LINES environment variable is set.
https://hg.python.org/cpython/rev/c6182a7e75fa

New changeset c8adee8a0ccb by Serhiy Storchaka in branch 'default':
Issue #22314: pydoc now works when the LINES environment variable is set.
https://hg.python.org/cpython/rev/c8adee8a0ccb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22314>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:52:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 22:52:52 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>
Message-ID: <1417128772.87.0.272257019864.issue17293@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/issue17293>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:53:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 22:53:12 +0000
Subject: [issue21280] shutil.make_archive() with default "root_dir" parameter
 raises FileNotFoundError: [Errno 2] No such file or directory: ''
In-Reply-To: <1397722199.92.0.999945404475.issue21280@psf.upfronthosting.co.za>
Message-ID: <20141127225310.126780.22381@psf.io>


Roundup Robot added the comment:

New changeset 8fa9097eadcb by Serhiy Storchaka in branch '3.4':
Issue #21280: Fixed a bug in shutil.make_archive() when create an archive of
https://hg.python.org/cpython/rev/8fa9097eadcb

New changeset c605dcf9786f by Serhiy Storchaka in branch 'default':
Issue #21280: Fixed a bug in shutil.make_archive() when create an archive of
https://hg.python.org/cpython/rev/c605dcf9786f

New changeset c7d45da654ee by Serhiy Storchaka in branch '2.7':
Issue #21280: Fixed a bug in shutil.make_archive() when create an archive of
https://hg.python.org/cpython/rev/c7d45da654ee

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21280>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:54:18 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 22:54:18 +0000
Subject: [issue18905] pydoc -p 0 says the server is available at localhost:0
In-Reply-To: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>
Message-ID: <1417128858.49.0.595847819715.issue18905@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your patch Wieland.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18905>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:54:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 22:54:39 +0000
Subject: [issue18905] pydoc -p 0 says the server is available at localhost:0
In-Reply-To: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>
Message-ID: <1417128879.29.0.919028006313.issue18905@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/issue18905>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:55:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 22:55:06 +0000
Subject: [issue22314] pydoc.py: TypeError with a $LINES defined to anything
In-Reply-To: <1409491027.45.0.991041704506.issue22314@psf.upfronthosting.co.za>
Message-ID: <1417128906.0.0.701655466143.issue22314@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/issue22314>
_______________________________________

From report at bugs.python.org  Thu Nov 27 23:56:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 22:56:34 +0000
Subject: [issue21280] shutil.make_archive() with default "root_dir" parameter
 raises FileNotFoundError: [Errno 2] No such file or directory: ''
In-Reply-To: <1397722199.92.0.999945404475.issue21280@psf.upfronthosting.co.za>
Message-ID: <1417128994.31.0.262482537043.issue21280@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/issue21280>
_______________________________________

From report at bugs.python.org  Fri Nov 28 00:01:18 2014
From: report at bugs.python.org (Torsten Landschoff)
Date: Thu, 27 Nov 2014 23:01:18 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za>
Message-ID: <1417129278.29.0.87686564756.issue22922@psf.upfronthosting.co.za>


Torsten Landschoff added the comment:

If anybody cares, here is a small patch to implement this. I ran the test suite and nothing else fails because of this change.

However I wonder if this is a slippery slope to go: If call_soon raises after the event loop is closed than everything else that registers an action with the loop should raise as well.

So for consistency this patch should grow quite a bit (unless create_connection, add_reader etc. already raise in this case).

If the decision is to go this path I would also suggest to add a new exception type for "Event loop is closed" so that it can be caught in client code.

YMMV

----------
keywords: +patch
nosy: +torsten
Added file: http://bugs.python.org/file37298/call_soon_after_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Fri Nov 28 00:29:04 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 27 Nov 2014 23:29:04 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417130944.97.0.583876679836.issue22959@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alex, christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Fri Nov 28 00:42:10 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Nov 2014 23:42:10 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
In-Reply-To: <1417129278.29.0.87686564756.issue22922@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa6rExgTm_woQha_2sLLVNhNS2Pzipn0=8stJ18p7huFg@mail.gmail.com>


STINNER Victor added the comment:

> If the decision is to go this path I would also suggest to add a new exception type for "Event loop is closed" so that it can be caught in client code.

I don't see the purpose of handling such exception. It's an obvious
bug, you must not handle bugs :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Fri Nov 28 00:44:57 2014
From: report at bugs.python.org (Torsten Landschoff)
Date: Thu, 27 Nov 2014 23:44:57 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za>
Message-ID: <1417131897.68.0.591250833031.issue22922@psf.upfronthosting.co.za>


Torsten Landschoff added the comment:

> > If the decision is to go this path I would also suggest to add a new exception type for "Event loop is closed" so that it can be caught in client code.

> I don't see the purpose of handling such exception. It's an obvious
bug, you must not handle bugs :)

Unless you can't directly fix them. They might be inside a library and triggered during application shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Fri Nov 28 00:47:35 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 27 Nov 2014 23:47:35 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
In-Reply-To: <1417131897.68.0.591250833031.issue22922@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbdWRyvrRiAgOmeD0+a6sfO32s+vc00Agx4Ex5vJonVkw@mail.gmail.com>


STINNER Victor added the comment:

> They might be inside a library and triggered during application shutdown.

In this case, fix the library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Fri Nov 28 01:56:20 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 28 Nov 2014 00:56:20 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1417136180.47.0.800236398821.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

I'll put something together.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Fri Nov 28 02:54:24 2014
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Nov 2014 01:54:24 +0000
Subject: [issue16561] bdist_wininst installers don't use UAC, then crash
In-Reply-To: <1353960153.53.0.844150162265.issue16561@psf.upfronthosting.co.za>
Message-ID: <1417139664.87.0.675153796282.issue16561@psf.upfronthosting.co.za>


Steve Dower added the comment:

The patch looks safe enough to me, if Benjamin is willing to consider it for 2.7.9?

Seems fine for 3.4 and 3.5 too, if nobody is opposed (or wants to argue over the wording of the message).

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16561>
_______________________________________

From report at bugs.python.org  Fri Nov 28 03:41:23 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Nov 2014 02:41:23 +0000
Subject: [issue16561] bdist_wininst installers don't use UAC, then crash
In-Reply-To: <1353960153.53.0.844150162265.issue16561@psf.upfronthosting.co.za>
Message-ID: <1417142483.28.0.308248911804.issue16561@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I'm okay with it if Steve is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16561>
_______________________________________

From report at bugs.python.org  Fri Nov 28 03:41:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 02:41:57 +0000
Subject: [issue16561] bdist_wininst installers don't use UAC, then crash
In-Reply-To: <1353960153.53.0.844150162265.issue16561@psf.upfronthosting.co.za>
Message-ID: <20141128024150.84285.61849@psf.io>


Roundup Robot added the comment:

New changeset 1ac5aec658f6 by Benjamin Peterson in branch '2.7':
give a nice message when installer is launched w/o admin rights (closes #16561)
https://hg.python.org/cpython/rev/1ac5aec658f6

New changeset caee1eabba1e by Benjamin Peterson in branch '3.4':
give a nice message when installer is launched w/o admin rights (closes #16561)
https://hg.python.org/cpython/rev/caee1eabba1e

New changeset ef5bbdc81796 by Benjamin Peterson in branch 'default':
merge 3.4 (#16561)
https://hg.python.org/cpython/rev/ef5bbdc81796

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16561>
_______________________________________

From report at bugs.python.org  Fri Nov 28 07:37:34 2014
From: report at bugs.python.org (Simon Zack)
Date: Fri, 28 Nov 2014 06:37:34 +0000
Subject: [issue22961] ctypes.WinError & OSError
Message-ID: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>


New submission from Simon Zack:

The ctypes.WinError function returns:

    OSError(None, descr, None, code)

However OSError does not appear to allow None as a first argument, and converts it to 22 which is the EINVAL "Invalid Argument" error. This is rather confusing as there was no invalid argument errors in the code.

I think the behaviour for one of WinError and OSError should be modified so that the handling of errno is more compatible.

----------
messages: 231796
nosy: simonzack
priority: normal
severity: normal
status: open
title: ctypes.WinError & OSError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22961>
_______________________________________

From report at bugs.python.org  Fri Nov 28 07:37:43 2014
From: report at bugs.python.org (Simon Zack)
Date: Fri, 28 Nov 2014 06:37:43 +0000
Subject: [issue22961] ctypes.WinError & OSError
In-Reply-To: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>
Message-ID: <1417156663.82.0.484152838618.issue22961@psf.upfronthosting.co.za>


Changes by Simon Zack <simonzack at gmail.com>:


----------
components: +ctypes
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22961>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:15:37 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Nov 2014 08:15:37 +0000
Subject: [issue22961] ctypes.WinError & OSError
In-Reply-To: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>
Message-ID: <1417162537.74.0.211611775586.issue22961@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22961>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:25:07 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Nov 2014 08:25:07 +0000
Subject: [issue22947] Enable 'imageop' - "Multimedia Srvices Feature module"
 for 64-bit platform
In-Reply-To: <1417004311.93.0.975050094816.issue22947@psf.upfronthosting.co.za>
Message-ID: <1417163107.91.0.678365760932.issue22947@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22947>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:46:49 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 08:46:49 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417164409.29.0.690287185437.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

When configure is called with correct LDFLAGS and CPPFLAGS for LibreSSL these patches to configure, Modules/_ssl.c and Lib/_ssl.py will detect not having RAND_egd support in OpenSSL and make the build succeed.

----------
Added file: http://bugs.python.org/file37299/patch-configure.ac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:47:09 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 08:47:09 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417164429.65.0.670580352134.issue21356@psf.upfronthosting.co.za>


Changes by Bernard Spil <python at bachfreund.nl>:


Removed file: http://bugs.python.org/file37242/patch-Modules__ssl.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:47:34 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 08:47:34 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417164454.75.0.332951114699.issue21356@psf.upfronthosting.co.za>


Changes by Bernard Spil <python at bachfreund.nl>:


Added file: http://bugs.python.org/file37300/patch-Lib_ssl.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:47:46 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 08:47:46 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417164466.9.0.581172473346.issue21356@psf.upfronthosting.co.za>


Changes by Bernard Spil <python at bachfreund.nl>:


Added file: http://bugs.python.org/file37301/patch-Modules__ssl.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:49:02 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 08:49:02 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417164542.71.0.676325279948.issue21356@psf.upfronthosting.co.za>


STINNER Victor added the comment:

patch-configure.ac:
-AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features])

Why do you remove this define?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:52:29 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Nov 2014 08:52:29 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417164749.72.0.767450517562.issue21356@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I thikn RAND_egd() should probably raise NotImplementedError if the function isn't exposed by the ssl library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 09:54:06 2014
From: report at bugs.python.org (Gary van der Merwe)
Date: Fri, 28 Nov 2014 08:54:06 +0000
Subject: [issue22962] ipaddress: Add optional prefixlen argument to
 ip_interface and ip_network
Message-ID: <1417164846.5.0.804919214198.issue22962@psf.upfronthosting.co.za>


New submission from Gary van der Merwe:

Currently if one has an ip address in int or IPv4Address/IPv6Address form, it is not possilbe to create a ip_interface or ip_network from that with specific prefix length, without first converting the address into string form, and then appending the prefixlen 

Please could an optional prefixlen argument to ip_interface and ip_network (and the __init__ functions for their backing classes) so that one can do this.

e.g: it should work like this:

>>> ipaddress.ip_interface(167772161, prefixlen=24)
IPv4Interface('10.0.0.1/24')

I would like to do a patch for this. I would just first like some feedback as to whether a patch for this would accepted.

----------
components: Library (Lib)
messages: 231800
nosy: Gary.van.der.Merwe
priority: normal
severity: normal
status: open
title: ipaddress: Add optional prefixlen argument to ip_interface and ip_network
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22962>
_______________________________________

From report at bugs.python.org  Fri Nov 28 10:50:46 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 09:50:46 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417168246.39.0.439158395331.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

Victor: That is a change that has been implemented in the downstream port to fix wxPython, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 this ended up in this patch as my primary objective was to fix it for the FreeBSD port.

Antoine: Sorry, I'm not a python dev... I'm willing to do the work if you can provide the guidance... This was merely a "works-for-me(TM)" patch. Since nothing actually uses egd any longer I would not spend to much effort on it. The odds of anyone requiring EGD support _and_ using LibreSSL are negligable. EGD is last centuries technology, there's no sense in mixing that with current tech.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 10:52:30 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 09:52:30 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417168350.08.0.519902408549.issue21356@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Victor: That is a change that has been implemented in the downstream port to fix wxPython, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 this ended up in this patch as my primary objective was to fix it for the FreeBSD port.

It looks unrelated to LibreSSL, please split your patch in two parts and open a new issue for the wxPython fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 10:56:48 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 09:56:48 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417168608.21.0.0361180351579.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

Remove https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192365 patch from this patch-set

----------
Added file: http://bugs.python.org/file37302/patch-configure.ac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 10:56:57 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 09:56:57 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417168617.76.0.47555823176.issue21356@psf.upfronthosting.co.za>


Changes by Bernard Spil <python at bachfreund.nl>:


Removed file: http://bugs.python.org/file37299/patch-configure.ac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:04:43 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 11:04:43 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417172683.95.0.740828057435.issue21356@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I thikn RAND_egd() should probably raise NotImplementedError if the function isn't exposed by the ssl library.

I would prefer to follow the model of the os module: don't declare a function if it is not supported by the OS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:06:43 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 28 Nov 2014 11:06:43 +0000
Subject: [issue22961] ctypes.WinError & OSError
In-Reply-To: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>
Message-ID: <1417172803.3.0.775064461993.issue22961@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

No, OSError.errno is converted from the Windows error code.

There is a translation map (see PC/errmap.h, built with the _dosmaperr() function) and the default value is EINVAL.

It's working as intended. What was the winerror code? do you think it should be mapped to another errno?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22961>
_______________________________________

From report at bugs.python.org  Fri Nov 28 12:28:22 2014
From: report at bugs.python.org (Simon Zack)
Date: Fri, 28 Nov 2014 11:28:22 +0000
Subject: [issue22961] ctypes.WinError & OSError
In-Reply-To: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>
Message-ID: <1417174102.59.0.315030606272.issue22961@psf.upfronthosting.co.za>


Simon Zack added the comment:

Ok, my bad, I was creating my own OSErrors so I was just testing it out. I just found the default to be rather confusing as I thought None would not be mapped to anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22961>
_______________________________________

From report at bugs.python.org  Fri Nov 28 13:04:10 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Nov 2014 12:04:10 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417176250.6.0.208063784211.issue21356@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I would prefer to follow the model of the os module: don't declare a function if it is not supported by the OS.

I don't have any strong feelings, so let's do it like that. RAND_egd() isn't useful anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 13:31:13 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 12:31:13 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <20141128123102.126770.85485@psf.io>


Roundup Robot added the comment:

New changeset 6f23bc5d480e by Victor Stinner in branch 'default':
Issue #21356: Make ssl.RAND_egd() optional to support LibreSSL. The
https://hg.python.org/cpython/rev/6f23bc5d480e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 13:36:06 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 12:36:06 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417178166.56.0.594554228268.issue21356@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, here is a first commit to try to support LibreSSL in Python 3.5.

Can someone please test to compile Python 3.5 with LibreSSL and run the test suite (at least test_ssl) to check that everything is fine? If you confirm that the change is correct, I will backport it to Python 2.7 and 3.4. Please mention your version of LibreSSL, OS and OS version in your feedback. LibreSSL has different releases: 2.0 to 2.1.1. Which one was embeded in OpenBSD 5.6?
http://www.libressl.org/

Bernard Spil's patches don't apply on Python 3.5, I guess that they were written for Python 2.7. I also fixed test_ssl.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 13:48:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 12:48:44 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za>
Message-ID: <1417178924.08.0.875675983374.issue22922@psf.upfronthosting.co.za>


STINNER Victor added the comment:

call_soon_after_close.diff looks good but also incomplete: call_later, call_at and run_in_executor should also raise an exception if the event loop is closed.

You should also add call_soon_threadsafe to the test.

> So for consistency this patch should grow quite a bit (unless create_connection, add_reader etc. already raise in this case).

Yes, add_reader raises an exception and there is an unit test to ensure that.

create_task() is a little bit special, it does not schedule immediatly a coroutine. IMO it makes sense to fail if the loop was closed, I don't see how the task can be executed if the loop was executed, so calling create_task() on a closed loop looks like a bug.

I suggest to modify the following methods:
- call_soon, call_soon_threadsafe
- call_at, call_later
- run_in_executor
- create_task
- add_signal_handler
- subprocess_exec, subprocess_shell

Did I miss something?

I'm not sure that *all* asyncio methods should must call _check_closed(), it may make the code harder to read. If the basic functions like call_soon and add_reader already handle the closed status, I guess that all other methods will fail loudly, so they don't need to be modified.

For example, stop() calls call_soon() and so will also raises an exception if the loop is closed.

Maybe we should add almost all methods to the test checking that calling these methods on a closed loop fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Fri Nov 28 14:11:47 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 13:11:47 +0000
Subject: [issue22926] asyncio: raise an exception when called from the wrong
 thread
In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za>
Message-ID: <1417180307.83.0.275846599928.issue22926@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a patch without unit:

- modify get_event_loop() to always raise a RuntimeError if the thread has no event loop. Before an AssertionError was not raised if python runs with -O option
- modify BaseEventLoop._assert_is_current_event_loop() to fail if the thread has an event loop
- modify tests to set the event loop to the newly created event loop, instead of setting it to None

----------
keywords: +patch
Added file: http://bugs.python.org/file37303/asyncio_thread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22926>
_______________________________________

From report at bugs.python.org  Fri Nov 28 14:29:26 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 13:29:26 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417181366.25.0.420643669556.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

FAILED (failures=2, errors=2, skipped=5)
That is OK, as these 2 tests should fail with LibreSSL since SSLv2 and SSLv3 support has been removed from LibreSSL.

ERROR: test_protocol_sslv23 (__main__.ThreadedTests)
ERROR: test_protocol_sslv3 (__main__.ThreadedTests)

----------
Added file: http://bugs.python.org/file37304/test_ssl.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 14:32:13 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 13:32:13 +0000
Subject: [issue22935] Disabling SSLv3 support
In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>
Message-ID: <1417181533.94.0.0394259819791.issue22935@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI LibreSSL also disabled SSLv2 and SSLv3.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Fri Nov 28 14:33:05 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 13:33:05 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417181585.39.0.0478897557836.issue21356@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> That is OK, as these 2 tests should fail with LibreSSL since SSLv2 and SSLv3 support has been removed from LibreSSL.

See the issue #22935.

I prefer to wait until this issue is fixed in Python 3.5, and that test_ssl pass on your PC, before backporting this change into Python 2.7 & 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Fri Nov 28 14:39:53 2014
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 28 Nov 2014 13:39:53 +0000
Subject: [issue22935] Disabling SSLv3 support
In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za>
Message-ID: <1417181993.04.0.673153848697.issue22935@psf.upfronthosting.co.za>


Matthias Klose added the comment:

maybe it's time to generalise this one, still found on all branches:

# Issue #9415: Ubuntu hijacks their OpenSSL and forcefully disables SSLv2
def skip_if_broken_ubuntu_ssl(func):

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22935>
_______________________________________

From report at bugs.python.org  Fri Nov 28 16:42:39 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Nov 2014 15:42:39 +0000
Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO
In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za>
Message-ID: <1417189359.65.0.179280154941.issue22914@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I addressed Serhiy's comments and added in some bits that I initially took off (-bb, -3, str.__mod__, io.open). Also clarified a couple of things.

----------
Added file: http://bugs.python.org/file37305/pyporting.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22914>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:18:04 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Nov 2014 16:18:04 +0000
Subject: [issue22896] Don't use PyObject_As*Buffer() functions
In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za>
Message-ID: <1417191484.36.0.0980904019243.issue22896@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22896>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:18:31 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 28 Nov 2014 16:18:31 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417191511.16.0.765699514857.issue22906@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:46:37 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 16:46:37 +0000
Subject: [issue22348] Documentation of asyncio.StreamWriter.drain()
In-Reply-To: <1410008027.32.0.320660376013.issue22348@psf.upfronthosting.co.za>
Message-ID: <20141128164616.55123.17561@psf.io>


Roundup Robot added the comment:

New changeset 8224253ef4b7 by Victor Stinner in branch '3.4':
Closes #22348: Rephrase asyncio.StreamWriter.drain() documentation
https://hg.python.org/cpython/rev/8224253ef4b7

New changeset 1cad9e4bba40 by Victor Stinner in branch 'default':
(Merge 3.4) Closes #22348: Rephrase asyncio.StreamWriter.drain() documentation
https://hg.python.org/cpython/rev/1cad9e4bba40

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22348>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:47:04 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 16:47:04 +0000
Subject: [issue22348] Documentation of asyncio.StreamWriter.drain()
In-Reply-To: <1410008027.32.0.320660376013.issue22348@psf.upfronthosting.co.za>
Message-ID: <1417193224.19.0.102229310548.issue22348@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry for the delay, I pushed asyncio-streams-drain-doc-water-limits.patch, thanks for your contribution Martin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22348>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:51:51 2014
From: report at bugs.python.org (Martin Richard)
Date: Fri, 28 Nov 2014 16:51:51 +0000
Subject: [issue21998] asyncio: a new self-pipe should be created in the child
 process after fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1417193511.2.0.567945104199.issue21998@psf.upfronthosting.co.za>


Martin Richard added the comment:

Hi,

Actually, closing and creating a new loop in the child doesn't work either, at least on Linux.

When, in the child, we call loop.close(), it performs:
self.remove_reader(self._ssock)
(in selector_events.py, _close_self_pipe() around line 85)

Both the parent and the child still refer to the same underlying epoll structure, at that moment, and calling remove_reader() has an effect on the parent process too (which will never watch the self-pipe again).

I attached a test case that demonstrates the issue (and the workaround, commented).

----------
nosy: +martius
Added file: http://bugs.python.org/file37306/test2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21998>
_______________________________________

From report at bugs.python.org  Fri Nov 28 17:56:06 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Nov 2014 16:56:06 +0000
Subject: [issue22394] Update documentation building to use venv and pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1417193766.41.0.810736838275.issue22394@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Attached is a patch against Doc/Makefile to add a venv command to create a venv that can be used to build the documentation. Georg, can you give me an LGTM so I can commit this?

----------
assignee: brett.cannon -> georg.brandl
keywords: +patch
nosy: +georg.brandl
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37307/doc_venv.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22394>
_______________________________________

From report at bugs.python.org  Fri Nov 28 18:03:11 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 17:03:11 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <20141128170259.69787.33337@psf.io>


Roundup Robot added the comment:

New changeset 737355f61ba2 by Victor Stinner in branch '3.4':
Issue #22685: Debug test_pause_reading() on FreeBSD
https://hg.python.org/cpython/rev/737355f61ba2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Fri Nov 28 18:55:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 28 Nov 2014 17:55:27 +0000
Subject: [issue22394] Update documentation building to use venv and pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1417197327.92.0.550735508494.issue22394@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Sure.  (The PyPI name is uppercased, but I guess it doesn't matter.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22394>
_______________________________________

From report at bugs.python.org  Fri Nov 28 19:07:22 2014
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 28 Nov 2014 18:07:22 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1417198042.39.0.154144104415.issue22936@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Fri Nov 28 19:12:51 2014
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 28 Nov 2014 18:12:51 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
In-Reply-To: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>
Message-ID: <1417198371.77.0.734020349047.issue22951@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22951>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:09:41 2014
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 28 Nov 2014 19:09:41 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1417201781.42.0.41473248744.issue22931@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:10:02 2014
From: report at bugs.python.org (eryksun)
Date: Fri, 28 Nov 2014 19:10:02 +0000
Subject: [issue22961] ctypes.WinError & OSError
In-Reply-To: <1417156654.51.0.229780672791.issue22961@psf.upfronthosting.co.za>
Message-ID: <1417201802.06.0.105752365932.issue22961@psf.upfronthosting.co.za>


eryksun added the comment:

> the default value is EINVAL.

Should that be specified in the docs? Currently it states that "[t]he errno attribute is then an approximate translation, in POSIX terms, of that native error code".

https://docs.python.org/3/library/exceptions.html#OSError

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22961>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:38:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Nov 2014 19:38:51 +0000
Subject: [issue19105] pprint doesn't use all width
In-Reply-To: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za>
Message-ID: <1417203531.09.0.327152317385.issue19105@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Antoine for your review.

But first variant of the patch doesn't affect an example at the top of this issue, it doesn't change string formatting. The second variant makes string formatting use all free space at the right. With the patch:

>>> import pprint
>>> print('='*80)  # a rule
================================================================================
>>> pprint.pprint([' '.join(str(i) for i in range(30))]*2)
['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 '
 '29',
 '0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 '
 '29']
>>> pprint.pprint([[[[[[[[[[[[' '.join(str(i) for i in range(30))]]]]]]]]]]]]*2)
[[[[[[[[[[[['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 '
            '25 26 27 28 29']]]]]]]]]]],
 [[[[[[[[[[['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 '
            '25 26 27 28 29']]]]]]]]]]]]

Could you please make a review of new patch?

----------
Added file: http://bugs.python.org/file37308/pprint_all_width_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19105>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:49:04 2014
From: report at bugs.python.org (Harsh Gupta)
Date: Fri, 28 Nov 2014 19:49:04 +0000
Subject: [issue22963] type in PEP 102
Message-ID: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za>


New submission from Harsh Gupta:

In PEP 102 [1], the link to PEP 101 is broken.

[1]: https://www.python.org/dev/peps/pep-0102/

----------
components: Devguide
messages: 231825
nosy: ezio.melotti, hargup
priority: normal
severity: normal
status: open
title: type in PEP 102
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22963>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:49:14 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Nov 2014 19:49:14 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417204154.56.0.358057102121.issue22906@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FYI:  I applied these two changes right after Guido pronounced on PEP 479:

https://mail.python.org/pipermail/python-checkins/2014-November/133252.html

https://mail.python.org/pipermail/python-checkins/2014-November/133253.html

Also, I'm submitting a patch to fix the code in Django that will be broken by PEP 479.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:50:28 2014
From: report at bugs.python.org (Harsh Gupta)
Date: Fri, 28 Nov 2014 19:50:28 +0000
Subject: [issue22963] broken link in PEP 102
In-Reply-To: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za>
Message-ID: <1417204228.49.0.767725131485.issue22963@psf.upfronthosting.co.za>


Changes by Harsh Gupta <gupta.harsh96 at gmail.com>:


----------
title: type in PEP 102 -> broken link in PEP 102

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22963>
_______________________________________

From report at bugs.python.org  Fri Nov 28 20:57:44 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 28 Nov 2014 19:57:44 +0000
Subject: [issue22963] broken link in PEP 102
In-Reply-To: <1417204144.27.0.6150414989.issue22963@psf.upfronthosting.co.za>
Message-ID: <1417204664.93.0.981825890301.issue22963@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. This has already been reported at https://github.com/python/pythondotorg/issues/510.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22963>
_______________________________________

From report at bugs.python.org  Fri Nov 28 21:50:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 20:50:33 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417207833.0.0.308662008349.issue22906@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> FYI:  I applied these two changes right after Guido pronounced on PEP 479:

Extract of emails:

changeset:   93542:9eb0d0eb0992
parent:      93540:23f8a511050a
user:        Raymond Hettinger <python at rcn.com>
date:        Sat Nov 22 21:56:23 2014 -0800

PEP 479:  Don't let StopIteration bubble out of calls to next() inside a generator.


changeset:   93543:e8b3083bb148
user:        Raymond Hettinger <python at rcn.com>
date:        Sat Nov 22 22:14:41 2014 -0800

PEP 479:  Use the return-keyword instead of raising StopIteration inside a generators.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:01:23 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 28 Nov 2014 21:01:23 +0000
Subject: [issue22962] ipaddress: Add optional prefixlen argument to
 ip_interface and ip_network
In-Reply-To: <1417164846.5.0.804919214198.issue22962@psf.upfronthosting.co.za>
Message-ID: <1417208483.81.0.979236334079.issue22962@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +ncoghlan, pmoody
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22962>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:08:32 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 21:08:32 +0000
Subject: [issue22676] _pickle's whichmodule() is slow
In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>
Message-ID: <1417208912.04.0.993328930454.issue22676@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On Windows with Visual Studio, I got a compiler warning. In whichmodule(), get_dotted_path() is called with module whereas module is not initialiazed:

    dotted_path = get_dotted_path(module, global_name, allow_qualname);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22676>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:27:35 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 21:27:35 +0000
Subject: [issue22389] Add contextlib.redirect_stderr()
In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za>
Message-ID: <20141128212731.126786.89558@psf.io>


Roundup Robot added the comment:

New changeset 7f12c9c09fb6 by Berker Peksag in branch 'default':
Issue #22389: Add contextlib.redirect_stderr().
https://hg.python.org/cpython/rev/7f12c9c09fb6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22389>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:29:02 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 28 Nov 2014 21:29:02 +0000
Subject: [issue22389] Add contextlib.redirect_stderr()
In-Reply-To: <1410445513.66.0.871890162607.issue22389@psf.upfronthosting.co.za>
Message-ID: <1417210142.38.0.881629055859.issue22389@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: rhettinger -> berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22389>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:33:51 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 28 Nov 2014 21:33:51 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417210431.23.0.867525129825.issue22955@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Note that pickling of the pure Python version of methodcaller works as expected:

Python 3.4.2 (default, Nov 20 2014, 12:40:10) 
[GCC 4.8.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_operator'] = None
>>> import operator
>>> import pickle
>>> pickle.loads(pickle.dumps(operator.methodcaller('foo')))
<operator.methodcaller object at 0x7ff869945898>

The pure Python attrgetter and itemgetter don't work due to using functions defined in __init__().

2.7 already raises TypeError on attempts to pickle any of the three.

----------
nosy: +zach.ware
title: Pickling of methodcaller and attrgetter -> Pickling of methodcaller, attrgetter, and itemgetter
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:40:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 21:40:12 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <20141128214007.69787.46788@psf.io>


Roundup Robot added the comment:

New changeset 0dd91298eb17 by Victor Stinner in branch 'default':
Issue #22685, asyncio: mock also resume_reading in test_pause_reading()
https://hg.python.org/cpython/rev/0dd91298eb17

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Fri Nov 28 22:42:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 21:42:18 +0000
Subject: [issue22685] memory leak: no transport for pipes by
 create_subprocess_exec/shell
In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>
Message-ID: <20141128214213.126788.68152@psf.io>


Roundup Robot added the comment:

New changeset 276515d2ceed by Victor Stinner in branch 'default':
Issue #22685, asyncio: resume_reading() must also be called in test_pause_reading()
https://hg.python.org/cpython/rev/276515d2ceed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22685>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:37:01 2014
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 28 Nov 2014 22:37:01 +0000
Subject: [issue22095] Use of set_tunnel with default port results in incorrect
 post value in host header
In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za>
Message-ID: <1417214221.48.0.738551100139.issue22095@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file37309/issue22095_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22095>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:37:40 2014
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 28 Nov 2014 22:37:40 +0000
Subject: [issue22095] Use of set_tunnel with default port results in incorrect
 post value in host header
In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za>
Message-ID: <1417214260.18.0.5519529178.issue22095@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Thanks Serhiy, new patch addresses your comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22095>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:42:31 2014
From: report at bugs.python.org (Antony Lee)
Date: Fri, 28 Nov 2014 22:42:31 +0000
Subject: [issue22964] dbm.open(..., "x")
Message-ID: <1417214551.97.0.349316203885.issue22964@psf.upfronthosting.co.za>


New submission from Antony Lee:

It would be nice if dbm.open() supported the "x" flag that open() now supports (create a new db, failing if it already exists).

----------
components: Library (Lib)
messages: 231835
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: dbm.open(..., "x")
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22964>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:50:04 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Nov 2014 22:50:04 +0000
Subject: [issue22676] _pickle's whichmodule() is slow
In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>
Message-ID: <1417215004.21.0.897351549268.issue22676@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

----------
Added file: http://bugs.python.org/file37310/whichmodule_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22676>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:53:18 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 28 Nov 2014 22:53:18 +0000
Subject: [issue22964] dbm.open(..., "x")
In-Reply-To: <1417214551.97.0.349316203885.issue22964@psf.upfronthosting.co.za>
Message-ID: <1417215198.44.0.922390175588.issue22964@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22964>
_______________________________________

From report at bugs.python.org  Fri Nov 28 23:59:29 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 22:59:29 +0000
Subject: [issue22585] os.urandom() should use getentropy() of OpenBSD 5.6
In-Reply-To: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za>
Message-ID: <1417215569.61.0.596966951325.issue22585@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a patch using getentropy() if available. I tested it on OpenBSD 5.6 (the only OS implementing this function...).

The patch prepares also random.c to support Linux getrandom(): issue #22181.

----------
keywords: +patch
Added file: http://bugs.python.org/file37311/getentropy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22585>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:22:50 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Nov 2014 23:22:50 +0000
Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <20141128232237.69789.92072@psf.io>


Roundup Robot added the comment:

New changeset 21257f916668 by Ned Deily in branch '3.4':
Issue #16113: Also remove test_case_sha3_224_huge
https://hg.python.org/cpython/rev/21257f916668

New changeset bd97eab25c70 by Ned Deily in branch 'default':
Issue #16113: Also remove test_case_sha3_224_huge
https://hg.python.org/cpython/rev/bd97eab25c70

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:26:06 2014
From: report at bugs.python.org (Bernard Spil)
Date: Fri, 28 Nov 2014 23:26:06 +0000
Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd
 optional
In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za>
Message-ID: <1417217166.23.0.437180826313.issue21356@psf.upfronthosting.co.za>


Bernard Spil added the comment:

Merged the patch from haypo back into the FreeBSD port for 2.7 at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192511
In the process I discovered during test_ssl that I had to patch Lib/socket.py as well to make RAND_egd conditional

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21356>
_______________________________________

From report at bugs.python.org  Sat Nov 29 00:30:12 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Nov 2014 23:30:12 +0000
Subject: [issue22429] asyncio: pending call to loop.stop() if a coroutine
 raises a BaseException
In-Reply-To: <1410954714.23.0.464914894828.issue22429@psf.upfronthosting.co.za>
Message-ID: <1417217412.34.0.546297132785.issue22429@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a simple patch which fixes this specific issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file37312/run_until_complete_baseexception.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22429>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:12:43 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Nov 2014 00:12:43 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417219963.11.0.822602474166.issue22955@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for adding pickling support to Python 3.5.

I don't see much of a need for any revision to 3.4.

----------
nosy: +rhettinger
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:20:58 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2014 00:20:58 +0000
Subject: [issue22912] urlretreive locks up in 2.7.8
In-Reply-To: <1416599758.35.0.866747041142.issue22912@psf.upfronthosting.co.za>
Message-ID: <1417220458.89.0.412798070437.issue22912@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I altered the code to print the return value and ran from Idle 2.7.8 on Win7. It takes about a minute and prints ('chromedriver_win32.zip', <httplib.HTTPMessage instance at 0x0000000002E3FE08>).  When I tried to end the pause with ^C, it was ignored and several seconds later got the above again.  So, for me, un-iterruptable delay yes (possibly in remote server), crash no.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22912>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:25:50 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2014 00:25:50 +0000
Subject: [issue22918] Doc for __iter__ makes inexact comment about
 dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1417220750.55.0.199733641342.issue22918@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Since .iterkeys is gone, I thing the ', and' part should just be dropped.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22918>
_______________________________________

From report at bugs.python.org  Sat Nov 29 01:33:46 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2014 00:33:46 +0000
Subject: [issue22922] asyncio: call_soon() should raise an exception if the
 event loop is closed
In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za>
Message-ID: <1417221226.37.0.132966658956.issue22922@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Adding minimal code checks to make multiple tests pass sounds good to me.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22922>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:12:50 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 29 Nov 2014 01:12:50 +0000
Subject: [issue21998] asyncio: a new self-pipe should be created in the child
 process after fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1417223570.5.0.521514329742.issue21998@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Martin, what is the magic call to make in the child (or in the parent pre-fork???) to disable the epoll object in the child without disabling it in the parent?

(Perhaps just closing the selector and letting the unregister calls fail would work?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21998>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:18:01 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2014 01:18:01 +0000
Subject: [issue22951] unexpected return from float.__repr__() for inf, -inf,
 nan
In-Reply-To: <1417031236.3.0.00389201998154.issue22951@psf.upfronthosting.co.za>
Message-ID: <1417223881.21.0.172519131155.issue22951@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Enhancements are only possible in 3.5 or beyond.  I agree with Mark. There is no compelling reason to break code with this change.  Hence it should be rejected.

Float is an odd duck.  All ints and all non-recursive lists, for instance, have a literal representation, and repr used that.  No range objects, for instance, have a literal representation, so repr uses a evaluable 'range(start, stop[, step])'  All float objects except 3 have a literal representation.

Int and float are both unusual builtins in parsing a string input to produce a non-string object.  For int, eval(repr(i)) == int(repr(i)) == i for all ints i.  Similarly, eval(repr(f)) == float(repr(f)) == f for all float objects f *except* for the same 3 special objects.  For those 3, a choice was make and we should stick with it.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
versions: +Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22951>
_______________________________________

From report at bugs.python.org  Sat Nov 29 02:32:20 2014
From: report at bugs.python.org (Demian Brecht)
Date: Sat, 29 Nov 2014 01:32:20 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1417224740.6.0.47518286045.issue22931@psf.upfronthosting.co.za>


Demian Brecht added the comment:

There could be some history behind this that I'm unaware of that I'm not familiar with.

>From what I can tell, this issue is simply due to the "[" character not being in _LegalCharsPatt (http/cookies.py). _LegalCharsPatt actually seems quite a bit more restrictive than it really should be. It's set to r"[\w\d!#%&'~_`><@,:/\$\*\+\-\.\^\|\)\(\?\}\{\=]", where RFC 6265 specifies:

cookie-pair       = cookie-name "=" cookie-value
cookie-name       = token
cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash
token             = <token, defined in [RFC2616], Section 2.2>

_LegalCharsPatt is used for regex matching on the cookie value, not the key (there is a distinction made between the two).

The omission of those characters is correct for the cookie keys, but not the values (RFC 2965 is a little less verbose, but nothing ruling out those characters for values).

----------
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Sat Nov 29 03:57:36 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 29 Nov 2014 02:57:36 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417229856.03.0.888394795645.issue22955@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I've made a patch that I believe should cover all three cases, including tests.

In addition to the pickling behavior, I've made two other changes:

1. methodcaller verifies during construction that the name is a string (PyUnicode), and interns it; attrgetter did this already, and I tweaked methodcaller to match for correctness and performance reasons
2. I added proper repr functionality to all three objects. Partially this is just to make it look nicer, but it was also a decent way to spot verify that the pickle/unpickle sequence behaved correctly

Anyone care to review?

----------
keywords: +patch
nosy: +josh.r
versions: +Python 3.4
Added file: http://bugs.python.org/file37313/pickle_getter_and_caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 03:58:34 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 29 Nov 2014 02:58:34 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417229914.03.0.0457894886498.issue22955@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 04:26:12 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 29 Nov 2014 03:26:12 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417231572.48.0.760481943383.issue22955@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Don't bother reviewing just yet. There is an issue with attrgetter's pickling (which the unit tests caught), and I need to update the pure Python modules to match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 05:06:30 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 29 Nov 2014 04:06:30 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417233990.44.0.135609904282.issue22955@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Okay, this one passes the tests for the built-in module. I'm not sure what's going wrong with the pure Python module. I'm getting the error:

    _pickle.PicklingError: Can't pickle <class 'operator.attrgetter'>: it's not the same object as operator.attrgetter

once for each of the three objects. Anyone recognize this? Is this some weird artifact of the multiple imports required to test both pure Python and C versions of the module that I need to work around, or did I make a mistake somewhere else?

----------
Added file: http://bugs.python.org/file37314/pickle_getter_and_caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 05:06:52 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 29 Nov 2014 04:06:52 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417234012.39.0.854654837967.issue22955@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


Removed file: http://bugs.python.org/file37313/pickle_getter_and_caller.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 05:32:35 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 29 Nov 2014 04:32:35 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417235555.51.0.0486255152441.issue22955@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Ah, solved it (I think). The bootstrapper used to import the Python and C versions of the module leaves sys.modules unpopulated (Does pickle itself may populate it when it finds no module of that name?). I added a setUp method to the unittest class for operator that explicitly sets sys.modules['operator'] to whichever version is being tested at the time so pickle's lookup works as expected. Is that the right solution? New patch uploaded with that change.

----------
Added file: http://bugs.python.org/file37315/pickle_getter_and_caller2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 09:17:24 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 29 Nov 2014 08:17:24 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417249044.51.0.129824816768.issue22906@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Regarding the patch below, isn't most of this redundant? ISTM that simply calling PyErr_SetString(...) should do all of this, including the exception chaining.


diff -r 23ab1197df0b Objects/genobject.c
--- a/Objects/genobject.c	Wed Nov 19 13:21:40 2014 +0200
+++ b/Objects/genobject.c	Thu Nov 20 16:47:59 2014 +1100
@@ -130,6 +130,23 @@
         }
         Py_CLEAR(result);
     }
+    else if (!result)
+    {
+        if (PyErr_ExceptionMatches(PyExc_StopIteration))
+        {
+            PyObject *exc, *val, *val2, *tb;
+            PyErr_Fetch(&exc, &val, &tb);
+            PyErr_NormalizeException(&exc, &val, &tb);
+            Py_DECREF(exc);
+            Py_XDECREF(tb);
+            PyErr_SetString(PyExc_RuntimeError,
+                "generator raised StopIteration");
+            PyErr_Fetch(&exc, &val2, &tb);
+            PyErr_NormalizeException(&exc, &val2, &tb);
+            PyException_SetContext(val2, val);
+            PyErr_Restore(exc, val2, tb);
+        }
+    }
 
     if (!result || f->f_stacktop == NULL) {
         /* generator can't be rerun, so release the frame */

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Sat Nov 29 09:38:37 2014
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 29 Nov 2014 08:38:37 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417250317.44.0.762347284903.issue22906@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Stefan, I'm not sure - I don't know the details of the C API here. But I tried commenting out everything but that one line, and while it does result in RuntimeError, it doesn't do the exception chaining. Currently, I believe the exception isn't being caught at all; but I don't know what it would take to do the full catching properly. The current patch doesn't always have a traceback on the original StopIteration, either, so it's definitely not quite right yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Sat Nov 29 09:57:52 2014
From: report at bugs.python.org (mattes)
Date: Sat, 29 Nov 2014 08:57:52 +0000
Subject: [issue22965] smtplib.py: senderrs[each] -> TypeError: unhashable
 instance
Message-ID: <1417251472.86.0.2977752969.issue22965@psf.upfronthosting.co.za>


New submission from mattes:

I get the following error:

File "/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/smtplib.py", line 731, in sendmail
    senderrs[each] = (code, resp)
TypeError: unhashable instance

senderrs[str(each)] = (code, resp) fixes it. Not sure if that is the best fix though.

See also http://stackoverflow.com/questions/27195432/google-app-engine-mail-send-returns-typeerror-unhashable-instance-in-python2

----------
components: Library (Lib), email
messages: 231854
nosy: barry, mattes, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib.py: senderrs[each] -> TypeError: unhashable instance
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22965>
_______________________________________

From report at bugs.python.org  Sat Nov 29 09:59:59 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 29 Nov 2014 08:59:59 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417251599.76.0.91840106708.issue22906@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Ah, right - chaining only happens automatically when the exception has already been caught and moved to sys.exc_info.

There's a _PyErr_ChainExceptions(), though, which does it for you. You should be able to say

    PyErr_Fetch(&x,&y,&z)
    PyErr_SetString()
    _PyErr_ChainExceptions(x,y,z)

(does pretty much what your code does as well)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Sat Nov 29 10:02:03 2014
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 29 Nov 2014 09:02:03 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417251723.75.0.805188886873.issue22906@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Yeah, I saw that. Since that function begins with an underscore, I thought it best to replicate its behaviour rather than to call it. Either way ought to work though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Sat Nov 29 10:10:23 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 29 Nov 2014 09:10:23 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417252223.27.0.713081941937.issue22906@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Public underscore C functions are there for exactly the purpose of not duplicating functionality across *internal* core runtime code, without making them an official part of the C-API for *external* code. (I understand that it's a POC patch, though, so whoever applies that change eventually will rework it anyway.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Sat Nov 29 10:27:13 2014
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 29 Nov 2014 09:27:13 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1417253233.9.0.0714989279064.issue22906@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

FYI, here's the set of tests that I've written for my implementation in Cython:

https://github.com/cython/cython/blob/b4383a540a790a5553f19438b3fc22b11858d665/tests/run/generators_pep479.pyx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Sat Nov 29 11:16:42 2014
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Sat, 29 Nov 2014 10:16:42 +0000
Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?=
 =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?=
Message-ID: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>


New submission from Piotr O?arowski:

when py_compile module is asked to create .pyc file for file with invalid name, it doesn't fail or ignore such request - it creates/overwrites .pyc file for sane file name (i.e. ignores everything after dot)

$ touch foo.bar.py
$ python3.4 -m py_compile foo.bar.py
$ ls __pycache__
foo.cpython-34.pyc

Even though foo.bar.py is not a valid file name, some programmers are using such names for plugins which leads to bugs similar to https://lists.debian.org/debian-python/2014/11/msg00061.html.

I will update my scripts to not feed py_compile module with file names containing dot (and remove already generated .pyc files if such files are detected), but please do not generate them or generate .pyc files with invalid file names as well.

----------
messages: 231859
nosy: piotr
priority: normal
severity: normal
status: open
title: py_compile: foo.bar.py ? __pycache__/foo.cpython-34.pyc
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22966>
_______________________________________

From report at bugs.python.org  Sat Nov 29 14:44:54 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 29 Nov 2014 13:44:54 +0000
Subject: [issue22898] segfault during shutdown attempting to log
 ResourceWarning
In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za>
Message-ID: <1417268694.68.0.794110494209.issue22898@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Out of curiosity I have tried to figure out how to build another test case using the model provided by runtimerror_singleton.py. This cannot be done, and for the following reasons:

The infinite recursion of PyErr_NormalizeException() is supposed to occur as follows: when a RuntimeError caused by recursion is normalized, PyErr_NormalizeException() calls the RuntimeError class to instantiate the exception, the recursion limit is reached again, triggering a new RuntimeError that needs also to be normalized causing PyErr_NormalizeException() to recurse infinitely.

But the low/high water mark level heuristic of the anti-recursion protection mechanism described in a comment of ceval.h prevents this. Let's assume the infinite recursion is possible:
* At iteration 'n' of the infinite recursion, the instantiation of the RuntimeError exception fails because of recursion with a new RuntimeError and tstate->overflowed is true: PyErr_NormalizeException() recurses.
* At iteration 'n + 1', the instantiation of this new RuntimeError is successfull because the recursion level is not checked when tstate->overflowed is true: the recursion of PyErr_NormalizeException() terminates and infinite recursion is not possible.

This explains the paradox that, if you remove entirely the check against infinite recursion in PyErr_NormalizeException(), then the runtimerror_singleton_2.py reproducer does not crash and the ResourceWarning is printed even though the recursion limit has been reached.

The attached patch implements this fix, includes the previous changes in _warning.c, and moves the test case to test_exceptions.

History (for reference):
The PyExc_RecursionErrorInst singleton was added by svn revision 58032 [1] to fix the issue titled "a bunch of infinite C recursions" [2].
In parallel, changeset cd125fe83051 [3] added the 'overflowed' member to the thread state.
Interestingly changeset cd125fe83051 was committed before revision 58032, but the whole discussion on issue [2] took place well before this commit was done, and so the fact that the infinite recursion problem of PyErr_NormalizeException() was being fixed by changeset cd125fe83051 as a side effect, went unnoticed.

[1] http://svn.python.org/view?view=revision&revision=58032
[2] http://bugs.python.org/issue1202533
[3] https://hg.python.org/cpython/rev/cd125fe83051

----------
Added file: http://bugs.python.org/file37316/remove_singleton.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22898>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:04:26 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 29 Nov 2014 14:04:26 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1417269866.13.0.295351054839.issue19858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which makes pickletools.optimize() to work with the MEMOIZE opcode.

As side effect it also renumbers memoized values, this allows to use short BINPUT and BINGET instead of LONG_BINPUT and LONG_BINGET.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.4
Added file: http://bugs.python.org/file37317/pickle_optimize_memoize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19858>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:33:15 2014
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 29 Nov 2014 14:33:15 +0000
Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?=
 =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?=
In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>
Message-ID: <1417271595.1.0.435958394332.issue22966@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: +Library (Lib)
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22966>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:33:31 2014
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 29 Nov 2014 14:33:31 +0000
Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?=
 =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?=
In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>
Message-ID: <1417271611.84.0.546724251429.issue22966@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/issue22966>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:56:49 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Nov 2014 14:56:49 +0000
Subject: [issue22462] Modules/pyexpat.c violates PEP 384
In-Reply-To: <1411401083.5.0.108064936526.issue22462@psf.upfronthosting.co.za>
Message-ID: <20141129145646.116328.97434@psf.io>


Roundup Robot added the comment:

New changeset e4b986350feb by Antoine Pitrou in branch '3.4':
Close issue #22895: fix test failure introduced by the fix for issue #22462.
https://hg.python.org/cpython/rev/e4b986350feb

New changeset 4990157343c6 by Antoine Pitrou in branch 'default':
Close issue #22895: fix test failure introduced by the fix for issue #22462.
https://hg.python.org/cpython/rev/4990157343c6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22462>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:56:49 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 29 Nov 2014 14:56:49 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <20141129145647.116328.83528@psf.io>


Roundup Robot added the comment:

New changeset e4b986350feb by Antoine Pitrou in branch '3.4':
Close issue #22895: fix test failure introduced by the fix for issue #22462.
https://hg.python.org/cpython/rev/e4b986350feb

New changeset 4990157343c6 by Antoine Pitrou in branch 'default':
Close issue #22895: fix test failure introduced by the fix for issue #22462.
https://hg.python.org/cpython/rev/4990157343c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Sat Nov 29 15:57:17 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Nov 2014 14:57:17 +0000
Subject: [issue22895] test failure introduced by the fix for issue #22462
In-Reply-To: <1416312212.42.0.987101941717.issue22895@psf.upfronthosting.co.za>
Message-ID: <1417273037.58.0.423668842475.issue22895@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This should be fixed now.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22895>
_______________________________________

From report at bugs.python.org  Sat Nov 29 16:19:55 2014
From: report at bugs.python.org (700eb415)
Date: Sat, 29 Nov 2014 15:19:55 +0000
Subject: [issue22542] Use arc4random under OpenBSD for os.urandom() if
 /dev/urandom is not present
In-Reply-To: <1412272060.2.0.302379812254.issue22542@psf.upfronthosting.co.za>
Message-ID: <1417274395.8.0.421757035339.issue22542@psf.upfronthosting.co.za>


700eb415 added the comment:

>From the OpenBSD random(4) man page:
"The arc4random(3) function in userland libraries should be used instead, as it works without the need to access these devices every time."

Theo just had a good talk on this issue here about why /dev/random needs replacing here: http://www.openbsd.org/papers/hackfest2014-arc4random/index.html . There's also a videon on YouTube.

At this point, I should probably have a patch ready sometime towards the middle of the week. I had a conversation with Ted Unangst off list, and think the best place for me to push it would first be a patch to the OpenBSD ports. After the OpenBSD guys review it, I'll then push it here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22542>
_______________________________________

From report at bugs.python.org  Sat Nov 29 18:22:30 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 29 Nov 2014 17:22:30 +0000
Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?=
 =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?=
In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>
Message-ID: <1417281750.19.0.164735200355.issue22966@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/issue22966>
_______________________________________

From report at bugs.python.org  Sat Nov 29 19:02:01 2014
From: report at bugs.python.org (=?utf-8?q?Piotr_O=C5=BCarowski?=)
Date: Sat, 29 Nov 2014 18:02:01 +0000
Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?=
 =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?=
In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>
Message-ID: <1417284121.27.0.298965918927.issue22966@psf.upfronthosting.co.za>


Piotr O?arowski added the comment:

Python 3.2 generates foo.bar.cpython-32.pyc so it's a regression

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22966>
_______________________________________

From report at bugs.python.org  Sat Nov 29 20:39:27 2014
From: report at bugs.python.org (Kyle Lahnakoski)
Date: Sat, 29 Nov 2014 19:39:27 +0000
Subject: [issue22967] tempfile.py does not work in windows8
Message-ID: <1417289966.96.0.104718230559.issue22967@psf.upfronthosting.co.za>


New submission from Kyle Lahnakoski:

I installed python 2.7.8  on Windows version 6.2 (build 9200) and get-pip.py does not run.  I traced the problem to c:\python27\lib\tempfile.py   Here is my session:

>> c:\Users\kyle\Downloads>python
>> Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit Intel)] on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import tempfile
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "c:\Python27\lib\tempfile.py", line 32, in <module>
>>     import io as _io
>>   File "io.py", line 72, in <module>
>>     import numpy as N
>> ImportError: No module named numpy

Ok, seems odd that numpy is required.  I installed numpy, and tried again:

>> >>> import tempfile
>> >>> tmpdir = tempfile.mkdtemp()
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "c:\Python27\lib\tempfile.py", line 325, in mkdtemp
>>     dir = gettempdir()
>>   File "c:\Python27\lib\tempfile.py", line 269, in gettempdir
>>     tempdir = _get_default_tempdir()
>>   File "c:\Python27\lib\tempfile.py", line 200, in _get_default_tempdir
>>     with _io.open(fd, 'wb', closefd=False) as fp:
>> AttributeError: 'module' object has no attribute 'open'

I expected that tempfile would import without issue.

----------
components: IO
messages: 231867
nosy: klahnakoski at mozilla.com
priority: normal
severity: normal
status: open
title: tempfile.py does not work in windows8
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22967>
_______________________________________

From report at bugs.python.org  Sat Nov 29 20:53:43 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Nov 2014 19:53:43 +0000
Subject: [issue22967] tempfile.py does not work in windows8
In-Reply-To: <1417289966.96.0.104718230559.issue22967@psf.upfronthosting.co.za>
Message-ID: <1417290823.68.0.430551223974.issue22967@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Try the following in Command Prompt:

cd /D C:\Users\kyle\Downloads && python -c "import io;print io.__file__"

The result should be "C:\Python27\lib\io.pyc".  If it's not, rename the file that you do get back.

----------
nosy: +zach.ware
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22967>
_______________________________________

From report at bugs.python.org  Sat Nov 29 21:11:10 2014
From: report at bugs.python.org (Kyle Lahnakoski)
Date: Sat, 29 Nov 2014 20:11:10 +0000
Subject: [issue22967] tempfile.py does not work in windows8
In-Reply-To: <1417289966.96.0.104718230559.issue22967@psf.upfronthosting.co.za>
Message-ID: <1417291870.77.0.590866434735.issue22967@psf.upfronthosting.co.za>


Kyle Lahnakoski added the comment:

Doh!  Dirty directory!

Thank you for your time!  My apologies.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22967>
_______________________________________

From report at bugs.python.org  Sat Nov 29 21:28:22 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Nov 2014 20:28:22 +0000
Subject: [issue22967] tempfile.py does not work in windows8
In-Reply-To: <1417289966.96.0.104718230559.issue22967@psf.upfronthosting.co.za>
Message-ID: <1417292902.94.0.0623633672982.issue22967@psf.upfronthosting.co.za>


Zachary Ware added the comment:

No problem, glad it was an easy one :)

----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22967>
_______________________________________

From report at bugs.python.org  Sat Nov 29 21:38:34 2014
From: report at bugs.python.org (Greg Turner)
Date: Sat, 29 Nov 2014 20:38:34 +0000
Subject: [issue22968] types._calculate_meta nit: isinstance != PyType_IsSubtype
Message-ID: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za>


New submission from Greg Turner:

Kinda trivial but...

Something like the enclosed, untested patch would seem to make new_class work a bit more like type_new.

To be explicit, the difference is whether or not to respect virtual subclasses.

So, for example, as implemented, we can implement __subclasscheck__ on a 'AtypicalMeta' metaclass to create an 'Atypical' class whose __mro__ is (ATypical, object) -- note, no 'type' -- but for which issubclass(type, ATypical) is true.

If I'm not mistaken, this disguise will suffice sneak our psuedo-metatype past new_class (but not type.__new__, so we still get the same error message, and the universe does not implode on itself as planned...)

In my case,the only sequela was that the fantasy of my very own type-orthogonal graph of "foo"-style classes in 3.x was first subtly encouraged and then dashed against the Cpython rocks... (just kidding, sort-of).

----------
components: Library (Lib)
files: fix_types_calculate_meta.patch
keywords: patch
messages: 231871
nosy: gmt
priority: normal
severity: normal
status: open
title: types._calculate_meta nit: isinstance != PyType_IsSubtype
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37318/fix_types_calculate_meta.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22968>
_______________________________________

From report at bugs.python.org  Sat Nov 29 22:52:06 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Nov 2014 21:52:06 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417297926.09.0.294241884241.issue22955@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'd prefer to just reimplement itemgetter and attrgetter to make them picklable rather than adding pickling methods to them; see attached patch.

I also posted a few comments, but I just went ahead and addressed them myself in this patch.  I'm not qualified to give the _operator.c changes a proper review, but they look good enough to me if others agree that __reduce__ is the best approach in C.

----------
Added file: http://bugs.python.org/file37319/issue22955.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:05:11 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Nov 2014 22:05:11 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417298711.39.0.776738282447.issue22955@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file37320/issue22955.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:05:20 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Nov 2014 22:05:20 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417298720.61.0.115105499588.issue22955@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Removed file: http://bugs.python.org/file37319/issue22955.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sat Nov 29 23:10:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 29 Nov 2014 22:10:38 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1417299038.16.0.363693005855.issue22955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

operator.methodcaller is similar to functools.partial which is pickleable and can be used as a sample.

In C implementation some code can be shared between __repr__ and __reduce__ methods.

As for tests, different protocols should be tested. Also should be tested compatibility between C and Python implementations, instances pickled with one implementation should be unpickleable with other implementation. Move pickle tests into new test class.

If add __repr__ methods, they need tests. The restriction of method name type should be tested too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Sun Nov 30 02:20:34 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Nov 2014 01:20:34 +0000
Subject: [issue22884] argparse.FileType.__call__ returns unwrapped sys.stdin
 and stdout
In-Reply-To: <1416149886.65.0.378402881729.issue22884@psf.upfronthosting.co.za>
Message-ID: <1417310434.85.0.609118540979.issue22884@psf.upfronthosting.co.za>


paul j3 added the comment:

Related issues are:

http://bugs.python.org/issue13824 - argparse.FileType opens a file and never closes it
http://bugs.python.org/issue14156 - argparse.FileType for '-' doesn't work for a mode of 'rb'

As discussed earlier FileType was meant as a convenience for small scripting applications, ones that don't try to close the file before exiting.

But now we are encouraged to open files in a context that guarantees closure.  In 13824 I proposed a 'FileContext', and included a dummy context like this handle stdin/out.

But I think the closefd=False approach raised in 14156 and David is probably the better way to go.

I think the main thing that is lacking is a testing mechanism.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22884>
_______________________________________

From report at bugs.python.org  Sun Nov 30 02:29:07 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 30 Nov 2014 01:29:07 +0000
Subject: [issue21236] patch to use cabinet.lib instead of fci.lib (fixes build
 with Windows SDK 8.0)
In-Reply-To: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za>
Message-ID: <1417310947.77.0.40305061368.issue21236@psf.upfronthosting.co.za>


Steve Dower added the comment:

AFAICT, cabinet.lib has been around since at least VS 2008, so 3.4 will be fine. But since it builds currently there's no point changing it. I'll just let my changes handle it for 3.5 and leave the older versions alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21236>
_______________________________________

From report at bugs.python.org  Sun Nov 30 02:32:50 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 30 Nov 2014 01:32:50 +0000
Subject: [issue22676] _pickle's whichmodule() is slow
In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>
Message-ID: <1417311170.58.0.75612423634.issue22676@psf.upfronthosting.co.za>


Steve Dower added the comment:

That patch looks good to me (better than my fix would have been :) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22676>
_______________________________________

From report at bugs.python.org  Sun Nov 30 02:45:35 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Nov 2014 01:45:35 +0000
Subject: [issue22909] [argparse] Using parse_known_args,
 unknown arg with space in value is interpreted as first positional arg
In-Reply-To: <1416518938.92.0.605418746252.issue22909@psf.upfronthosting.co.za>
Message-ID: <1417311935.14.0.716460163083.issue22909@psf.upfronthosting.co.za>


paul j3 added the comment:

This an issue for parse_args as well.  parse_args just calls parse_known_args, and raises an error if extras is not empty.

Early on in parsing, it tries to classify argument strings as either optionals (--flags) or positionals (arguments).  And there's an explicit test for spaces:

    def _parse_optional(self, arg_string):
        ...
        # if it contains a space, it was meant to be a positional
        if ' ' in arg_string:
            return None

Basically, if it can't match the string with a define optional, and it contains a space (anywhere) it is classed as positional.  That's what your example shows.

It sounds familiar, so I suspect it was raised in an earlier issue.  I'll have to look it up.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22909>
_______________________________________

From report at bugs.python.org  Sun Nov 30 03:13:17 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 30 Nov 2014 02:13:17 +0000
Subject: [issue22919] Update PCBuild for VS 2015
In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za>
Message-ID: <1417313597.58.0.281421904028.issue22919@psf.upfronthosting.co.za>


Steve Dower added the comment:

>> After a debug build with VS2015, my biggest concern is this:
>>
>>  ..\PC\bdist_wininst\install.rc(19): fatal error RC1015: cannot open 
>> include file 'afxres.h'. [P:\ath\to\cpython\PCbuild\bdist_wininst.vcxproj]
>
> I thought I had a workaround for this, but I'll have to check it out.
> Oddly enough, all of my builds have been fine (I think I'm mostly
> doing release builds - does that make a difference?)

I haven't been able to reproduce this. bdist_wininst isn't selected to build for debug in VS, but it builds fine for me anyway. Was your repo dirty? (It didn't make a difference for me, but I have had files occasionally not update properly when switching branches.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22919>
_______________________________________

From report at bugs.python.org  Sun Nov 30 03:44:38 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 30 Nov 2014 02:44:38 +0000
Subject: [issue22909] [argparse] Using parse_known_args,
 unknown arg with space in value is interpreted as first positional arg
In-Reply-To: <1416518938.92.0.605418746252.issue22909@psf.upfronthosting.co.za>
Message-ID: <1417315478.29.0.5976168583.issue22909@psf.upfronthosting.co.za>


paul j3 added the comment:

Duplicate of
http://bugs.python.org/issue22433

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22909>
_______________________________________

From report at bugs.python.org  Sun Nov 30 03:47:15 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 30 Nov 2014 02:47:15 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <1417315635.5.0.689736205319.issue22960@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Attached is a patch for 2.7

----------
keywords: +patch
Added file: http://bugs.python.org/file37321/issue22960.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 03:48:24 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 30 Nov 2014 02:48:24 +0000
Subject: [issue22909] [argparse] Using parse_known_args,
 unknown arg with space in value is interpreted as first positional arg
In-Reply-To: <1416518938.92.0.605418746252.issue22909@psf.upfronthosting.co.za>
Message-ID: <1417315704.73.0.0758624260342.issue22909@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
status: open -> closed
superseder:  -> Argparse considers unknown optional arguments with spaces as a known positional argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22909>
_______________________________________

From report at bugs.python.org  Sun Nov 30 04:03:35 2014
From: report at bugs.python.org (Travis Thieman)
Date: Sun, 30 Nov 2014 03:03:35 +0000
Subject: [issue22536] subprocess should include filename in FileNotFoundError
 exception
In-Reply-To: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>
Message-ID: <1417316615.23.0.576347664516.issue22536@psf.upfronthosting.co.za>


Travis Thieman added the comment:

Thank you all for the helpful comments. A revised attempt is attached as -2.patch, with improved behavior around using cwd if the child is never called and orig_executable if it is. I opted not to fix the issue with the redundancy in the error message as I agree that should be handled as a separate issue.

----------
Added file: http://bugs.python.org/file37322/22536-subprocess-exception-filename-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22536>
_______________________________________

From report at bugs.python.org  Sun Nov 30 04:20:53 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 03:20:53 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <1417317653.0.0.545134184488.issue22960@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I suppose I should ask you to write a test. Of course, HTTPS doesn't seem to be tested at all right now (see the attractive "FIXME: mostly untested" comment in SafeTransport.) Maybe, it's easier now, though, using the code in Lib/test/ssl_servers.py?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 04:57:24 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Nov 2014 03:57:24 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <20141130035721.69787.43886@psf.io>


Roundup Robot added the comment:

New changeset 62bd574e95d5 by Benjamin Peterson in branch '2.7':
add context parameter to xmlrpclib.ServerProxy (#22960)
https://hg.python.org/cpython/rev/62bd574e95d5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 05:08:13 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 30 Nov 2014 04:08:13 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <1417320493.01.0.451540714928.issue22960@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Attached patch fixes it for Python3.

----------
Added file: http://bugs.python.org/file37323/issue22960-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 05:34:36 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Nov 2014 04:34:36 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <20141130043434.84305.66539@psf.io>


Roundup Robot added the comment:

New changeset 4b00430388ad by Benjamin Peterson in branch '3.4':
add context parameter to xmlrpclib.ServerProxy (#22960)
https://hg.python.org/cpython/rev/4b00430388ad

New changeset 2a126ce6f83e by Benjamin Peterson in branch 'default':
merge 3.4 (#22960)
https://hg.python.org/cpython/rev/2a126ce6f83e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 05:36:53 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 04:36:53 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417322213.38.0.68372910144.issue22959@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Why do you think it still verifies the hostname? It will certainly check if the certificate has a valid trust chain, but it won't do matching on the hostname.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Sun Nov 30 05:37:20 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 04:37:20 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <1417322240.72.0.359365874364.issue22960@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 12:51:52 2014
From: report at bugs.python.org (zodalahtathi)
Date: Sun, 30 Nov 2014 11:51:52 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417348312.54.0.0783341137031.issue22959@psf.upfronthosting.co.za>


zodalahtathi added the comment:

I think it does, when passing a context with ssl_context.verify_mode != ss.CERT_NONE, and when not setting the check_hostname parameter: 
1. will_verify will be True (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1207)
2. check_hostname will be True too (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1209)
3. ssl.match_hostname will be called after the handshake in wrap_socket (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1230)

The following code shows the problem:

import http.client
import ssl

ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
ssl_context.verify_mode = ssl.CERT_REQUIRED
ssl_context.check_hostname = False
https = http.client.HTTPSConnection("localhost", context=ssl_context)
print(https._check_hostname)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Sun Nov 30 12:55:59 2014
From: report at bugs.python.org (zodalahtathi)
Date: Sun, 30 Nov 2014 11:55:59 +0000
Subject: [issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL
 context parameter
In-Reply-To: <1417119786.53.0.605275113083.issue22960@psf.upfronthosting.co.za>
Message-ID: <1417348559.46.0.752024589645.issue22960@psf.upfronthosting.co.za>


zodalahtathi added the comment:

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22960>
_______________________________________

From report at bugs.python.org  Sun Nov 30 16:30:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 15:30:57 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <1417361457.47.0.84516778483.issue9179@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The more I think about it, the more doubt. This patch added a behavior that is incompatible with the regex module. The regex module proceeds lookbehind assertions in the opposite direction, from right to left. This allows it to work with lookbehind assertions of non-fixed length. But the side effect is that in regex group reference in lookbehind assertion can refer only to a group defined right in the same lookbehind assertion (or defined left outside). In re now group reference in lookbehind assertion can refer only to a group defined left. This is likely to change in the future, which brings us to the problem of incompatibility.

There are several quick ways to resolve the problem:

1) Rollback the patch and return to the previous non-working behavior. Because of the obvious non-working the problem with changing the implementation of lookbehind assertion in the future will be weaker.

2) Rollback the patch and emit a warning or error when using any group references in lookbehind assertion. Something like patch proposed by Greg Chapman in issue814253 (but slightly more advanced).

3) Leave the patch and emit a warning or an error when using group references to the group defined in this same lookbehind assertion. Group references will work in lookbehind assertions in most cases except rare cases when current re behavior differs from regex behavior.

What is your decision Benjamin?

Here is a patch against 2.7 which implements variant 3.

----------
nosy: +benjamin.peterson, larry
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> 
status: closed -> open
Added file: http://bugs.python.org/file37324/re_forbid_some_groupref_in_lookbehind-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9179>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:15:40 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 16:15:40 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417364140.61.0.525469434695.issue22959@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

As the documentation says "If context is specified and has a verify_mode of either CERT_OPTIONAL or CERT_REQUIRED, then by default host is matched against the host name(s) allowed by the server?s certificate. If you want to change that behaviour, you can explicitly set check_hostname to False."

It is rather weird that HTTPSConnection has its own "check_hostname" parameter independent of the one on the SSL context.

Alex, what do you think of this patch?

----------
Added file: http://bugs.python.org/file37325/ch-weirdness.aptch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:17:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 16:17:31 +0000
Subject: [issue22902] Use 'ip' for uuid.getnode()
In-Reply-To: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>
Message-ID: <1417364251.79.0.720774652437.issue22902@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Bruno, could you please sign a Contributor Licensing Agreement?

http://www.python.org/psf/contrib/contrib-form/
http://www.python.org/psf/contrib/

----------
assignee:  -> serhiy.storchaka
stage:  -> commit review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22902>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:20:53 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 30 Nov 2014 16:20:53 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417364453.35.0.422816280264.issue22959@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

This will cause it to not validate in some cases where it currently is validating? That seems like a regression to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:38:40 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 16:38:40 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417364453.35.0.422816280264.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417365518.1296289.196969637.3DF5FE04@webmail.messagingengine.com>


Benjamin Peterson added the comment:

On Sun, Nov 30, 2014, at 11:20, Alex Gaynor wrote:
> 
> Alex Gaynor added the comment:
> 
> This will cause it to not validate in some cases where it currently is
> validating? That seems like a regression to me.

I suppose. Certainly, none of the "default" cases are affected. The
problem is it's impossible to have cert validation w/o hostname checking
by passing a context to some higher level API than HTTPSConnection (like
xmlrpclib) because HTTPSConnection tries to be clever. Ideally, the
check_hostname argument wouldn't exist, and everything would come from
the context.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:51:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 16:51:35 +0000
Subject: [issue22095] Use of set_tunnel with default port results in incorrect
 post value in host header
In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za>
Message-ID: <1417366295.46.0.701588457877.issue22095@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/issue22095>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:52:08 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Nov 2014 16:52:08 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <20141130165205.69797.92524@psf.io>


Roundup Robot added the comment:

New changeset d1f7c3f45ffe by Benjamin Peterson in branch '3.4':
backout 9fcf4008b626 (#9179) for further consideration
https://hg.python.org/cpython/rev/d1f7c3f45ffe

New changeset f385bc6e6e09 by Benjamin Peterson in branch 'default':
merge 3.4 (#9179)
https://hg.python.org/cpython/rev/f385bc6e6e09

New changeset 8a3807e15a1f by Benjamin Peterson in branch '2.7':
backout fac649bf2d10 (#9179) for further consideration
https://hg.python.org/cpython/rev/8a3807e15a1f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9179>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:52:43 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 16:52:43 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <1417366363.94.0.421600904948.issue9179@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I just backed out the change. Thanks for brining up the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9179>
_______________________________________

From report at bugs.python.org  Sun Nov 30 17:57:30 2014
From: report at bugs.python.org (zodalahtathi)
Date: Sun, 30 Nov 2014 16:57:30 +0000
Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL
 context has check_hostname==False
In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za>
Message-ID: <1417366650.32.0.816213076107.issue22959@psf.upfronthosting.co.za>


zodalahtathi added the comment:

I agree that changing a default to something less secure is not something to do lightly, however I think forcing a check that is explicitly disabled is a bug and can be counter productive security wise.

People who don't have time to look at the stdlib code, and file bug like this are likely to react with "fuck it, I'll use plain HTTP".

By the way, my use case is precisely xmlrpc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22959>
_______________________________________

From report at bugs.python.org  Sun Nov 30 18:55:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 17:55:22 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <1417370122.32.0.317586338599.issue9179@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What would be the best solution for 2.7?

Here is a patch which forbids any group references in lookbehind assertions (they are not work currently and users shouldn't use them).

----------
stage:  -> patch review
Added file: http://bugs.python.org/file37326/re_forbid_groupref_in_lookbehind-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9179>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:41:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Nov 2014 18:41:16 +0000
Subject: [issue22902] Use 'ip' for uuid.getnode()
In-Reply-To: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>
Message-ID: <20141130184114.116310.26790@psf.io>


Roundup Robot added the comment:

New changeset 64bb01bce12c by Serhiy Storchaka in branch 'default':
Issue #22902: The "ip" command is now used on Linux to determine MAC address
https://hg.python.org/cpython/rev/64bb01bce12c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22902>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:44:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 18:44:10 +0000
Subject: [issue22902] Use 'ip' for uuid.getnode()
In-Reply-To: <1416410194.76.0.0246920486937.issue22902@psf.upfronthosting.co.za>
Message-ID: <1417373050.55.0.0891083675923.issue22902@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Bruno.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22902>
_______________________________________

From report at bugs.python.org  Sun Nov 30 19:52:57 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 18:52:57 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1417370122.32.0.317586338599.issue9179@psf.upfronthosting.co.za>
Message-ID: <1417373575.1322130.197000393.41E5C7C2@webmail.messagingengine.com>


Benjamin Peterson added the comment:

On Sun, Nov 30, 2014, at 12:55, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> What would be the best solution for 2.7?

You can pick. I just always favor not changing things for release
candidates.

> 
> Here is a patch which forbids any group references in lookbehind
> assertions (they are not work currently and users shouldn't use them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9179>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:36:45 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 19:36:45 +0000
Subject: [issue9179] Lookback with group references incorrect (two issues?)
In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za>
Message-ID: <1417376205.4.0.326144417884.issue9179@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated documentation. If there are no objections I'll commit re_forbid_groupref_in_lookbehind-2.7_2.patch to 2.7 and 3.4. For 3.5 I prefer to add support of group references.

----------
Added file: http://bugs.python.org/file37327/re_forbid_groupref_in_lookbehind-2.7_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9179>
_______________________________________

From report at bugs.python.org  Sun Nov 30 20:50:39 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 30 Nov 2014 19:50:39 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1417377039.56.0.91552004875.issue22619@psf.upfronthosting.co.za>


Dmitry Kazakov added the comment:

Revisiting this issue, I realize that I made quite a few mistakes (because this was the first issue I submitted). The patch is definitely minor, and I'm no longer interested in it. This issue may now be closed. Cheers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:21:52 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 30 Nov 2014 20:21:52 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1417378912.52.0.0129386358286.issue22619@psf.upfronthosting.co.za>


Changes by Dmitry Kazakov <jsbfox at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:34:25 2014
From: report at bugs.python.org (Simeon Visser)
Date: Sun, 30 Nov 2014 20:34:25 +0000
Subject: [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <1417379665.32.0.132646352635.issue20467@psf.upfronthosting.co.za>


Simeon Visser added the comment:

Is it worth clarifying that __init__ can return a value but only the value None? The following won't raise a TypeError:

class O(object):
    def __init__(self):
        return None

Admittedly the "return None" is the default behaviour but people may attempt this in order to "block creation" of the instance (as __new__ is less well-known, I have seen the above attempted on Stack Overflow: http://stackoverflow.com/questions/26896941/proper-way-to-terminate-object-creation-inside-of-init/)

----------
nosy: +simeon.visser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20467>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:35:43 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 30 Nov 2014 20:35:43 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1417379743.02.0.0724564574153.issue22619@psf.upfronthosting.co.za>


Changes by Dmitry Kazakov <jsbfox at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Sun Nov 30 21:56:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 Nov 2014 20:56:39 +0000
Subject: [issue22965] smtplib.py: senderrs[each] -> TypeError: unhashable
 instance
In-Reply-To: <1417251472.86.0.2977752969.issue22965@psf.upfronthosting.co.za>
Message-ID: <1417380999.36.0.131727907381.issue22965@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not familiar with app-engine, so I don't understand the code snippet in the stackoverflow issue.  But what is happening here is that whatever it is you've supplied as the 'to' address is not a string, but sendmail expects it to be.

Now, since rcpt converts its argument to a string, you might think it would be reasonable for senderrs to do the same.  But that would not be correct, since then you would not be able to use whatever you passed in to to_addrs as the key to retrieve values from senderrs.  Even if for some reason one did not consider this important, it still couldn't be changed for backward compatibility reasons.  Basically, the fact that rcpt does the equivalent of str(addr) is an implementation detail.

I'm closing this as not a bug; that is, the values in to_addrs are required to be strings, which is how that attribute is documented.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22965>
_______________________________________

From report at bugs.python.org  Sun Nov 30 22:03:41 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 30 Nov 2014 21:03:41 +0000
Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?=
 =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?=
In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za>
Message-ID: <1417381421.03.0.957722760077.issue22966@psf.upfronthosting.co.za>


R. David Murray added the comment:

And, therefore, a missing test :(.  This probably snuck in when we refactored the CLI.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22966>
_______________________________________

From report at bugs.python.org  Sun Nov 30 22:08:54 2014
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Sun, 30 Nov 2014 21:08:54 +0000
Subject: [issue22953] Windows installer configures system PATH also when
 installing only for current user
In-Reply-To: <1417045934.78.0.497938457178.issue22953@psf.upfronthosting.co.za>
Message-ID: <1417381734.58.0.256460052054.issue22953@psf.upfronthosting.co.za>


Pekka Kl?rck added the comment:

For me this isn't too high priority. I typically install Python for all users on Windows anyway, and recommend that also for my clients. I just tested this RC to see how (ensure)pip works in practice, decided to install only for the current user, was very happy to notice that there's an option to set PATH, and then decided to submit an issue when I noticed the system PATH was updated.

Because setting PATH is opt-in, and because 2.7 installer apparently requires admin rights and thus always can updated system PATH, I doubt this problem is going to actually matter to anyone. Great to hear 3.5 will have real "only for me" option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22953>
_______________________________________

From report at bugs.python.org  Sun Nov 30 23:20:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 22:20:31 +0000
Subject: [issue19361] Specialize exceptions thrown by JSON parser
In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za>
Message-ID: <1417386031.06.0.839007251543.issue19361@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch provides JSONDecodeError without end* attributes and with changed message for "Extra data".

----------
Added file: http://bugs.python.org/file37328/json_JSONDecodeError_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19361>
_______________________________________

From report at bugs.python.org  Sun Nov 30 23:22:03 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Nov 2014 22:22:03 +0000
Subject: [issue22943] bsddb: test_queue fails on Windows
In-Reply-To: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za>
Message-ID: <1417386123.41.0.28481855838.issue22943@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does it look good to you Benjamin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22943>
_______________________________________

From report at bugs.python.org  Sun Nov 30 23:28:38 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 30 Nov 2014 22:28:38 +0000
Subject: [issue22943] bsddb: test_queue fails on Windows
In-Reply-To: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za>
Message-ID: <1417386518.89.0.0933800577371.issue22943@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yes, please apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22943>
_______________________________________