From report at bugs.python.org  Wed Oct  1 02:39:53 2014
From: report at bugs.python.org (Ryan Gonzalez)
Date: Wed, 01 Oct 2014 00:39:53 +0000
Subject: [New-bugs-announce] [issue22530] re rejects index of type long on
	2.7
Message-ID: <1412123993.9.0.244243584379.issue22530@psf.upfronthosting.co.za>


New submission from Ryan Gonzalez:

This should work (but doesn't):

Python 2.7.8+ (2.7:63dc1e32b715, Sep 30 2014, 19:24:46) 
[GCC 4.2.1 Compatible Clang 3.5.0 (207381)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.match('(foo)', 'foo').group(1L)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: no such group
>>> 

I *think* the attached patch fixes it (but I'm not quite sure).

Here's the relevant mailing list thread: https://mail.python.org/pipermail/python-ideas/2014-September/029590.html.

----------
components: Library (Lib)
files: re.patch
keywords: patch
messages: 228043
nosy: Ryan.Gonzalez
priority: normal
severity: normal
status: open
title: re rejects index of type long on 2.7
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36766/re.patch

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

From report at bugs.python.org  Wed Oct  1 11:50:23 2014
From: report at bugs.python.org (Antony Lee)
Date: Wed, 01 Oct 2014 09:50:23 +0000
Subject: [New-bugs-announce] [issue22531] Turn contextlib.{redirect_stdout,
	suppress} into ContextDecorators
Message-ID: <1412157023.88.0.686085099512.issue22531@psf.upfronthosting.co.za>


New submission from Antony Lee:

A small lib improvement suggestion could be to make contextlib.redirect_stdout and contextlib.suppress inherit from ContextDecorator.

As a side note, the source of contextlib has some classes inheriting explicitly from object while others don't, so perhaps this can be harmonized at the same time.

----------
components: Library (Lib)
messages: 228065
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Turn contextlib.{redirect_stdout,suppress} into ContextDecorators
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct  1 16:27:46 2014
From: report at bugs.python.org (Padmanabhan Tr)
Date: Wed, 01 Oct 2014 14:27:46 +0000
Subject: [New-bugs-announce] [issue22532] A suggested change
Message-ID: <1412173666.91.0.11564470623.issue22532@psf.upfronthosting.co.za>


New submission from Padmanabhan Tr:

Take a complex number n = 3+4j. n.real is taken as 3.0 & n.imag as 4.0 in Python3.  One has to use the int(0 function to get back the parts as integers.  I guess this is a compiler error?

----------
messages: 228073
nosy: Padmanabhan.Tr
priority: normal
severity: normal
status: open
title: A suggested change
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct  1 21:49:03 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 01 Oct 2014 19:49:03 +0000
Subject: [New-bugs-announce] [issue22533] Counter with no keys does not
	compare equal to Counter	with keys which zero value
Message-ID: <1412192943.35.0.438260267398.issue22533@psf.upfronthosting.co.za>


New submission from Ethan Furman:

According to the docs [1]:

> Counter objects have a dictionary interface except that they return a
> zero count for missing items instead of raising a KeyError

Which a simple test confirms:

--> Counter()['b']
0

However, if the key is present but set to zero, equality fails:

--> Counter() == Counter(b=0)
False

It is my thought that a Counter with all its keys set to zero is as empty as a Counter with no keys:

--> c1 = Counter()
--> c2 = Counter(a=0, b=0, c=0)
--> for item in c2.keys():
...   assert c2[item] == c1[item]
(no execption raised)


[1] https://docs.python.org/2/library/collections.html#collections.Counter

----------
messages: 228111
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Counter with no keys does not compare equal to Counter with keys which zero value
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct  1 23:22:51 2014
From: report at bugs.python.org (TJ)
Date: Wed, 01 Oct 2014 21:22:51 +0000
Subject: [New-bugs-announce] [issue22534] Possible Memory Leak with 'shelve'
Message-ID: <1412198571.01.0.730305442625.issue22534@psf.upfronthosting.co.za>


New submission from TJ:

The following code causes memory usage to grow excessively.

'''
import shelve

def func():
    for i in range(1000000):
        sh = shelve.open('blah')
        sh.close()

func()
'''

----------
components: Library (Lib)
messages: 228127
nosy: tjhnson
priority: normal
severity: normal
status: open
title: Possible Memory Leak with 'shelve'
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  1 23:25:24 2014
From: report at bugs.python.org (Kristian Rother)
Date: Wed, 01 Oct 2014 21:25:24 +0000
Subject: [New-bugs-announce] [issue22535] headerregistry.Address introduces
	extra quotes without	addr_spec parameter
Message-ID: <1412198724.14.0.970145330248.issue22535@psf.upfronthosting.co.za>


New submission from Kristian Rother:

I am trying to create an email address as in the Python doc example 
https://docs.python.org/3/library/email-examples.html

The example does not work as given on the page.

I tried Python 3.4rc1 and the 3.5 compiled from source on Ubuntu 12.

I found two possible reasons:

1) Python bug in headerregistry.py
The string resulting from the command below contains extra quotes:

str(Address('Foo Example', 'foo at example.com'))
--> 'Foo Example <"foo at example.com">'


2) Documentation bug

The documentation of headerregistry.Address states:

"username and domain may be specified together by using 
the addr_spec keyword *instead of* the username and domain keywords"

However, this is inconsistent with example 19.1.14.1. on
https://docs.python.org/3/library/email-examples.html

Attached are two tests that reproduce the situation.
The first test below fails but the second passes.

Conclusion:
In my opinion, it is more intuitive if the following would work as well:
Address('Foo Example', 'foo at example.com')

----------
components: email
files: test_email_address_with_quotes.py
messages: 228128
nosy: barry, krother, r.david.murray
priority: normal
severity: normal
status: open
title: headerregistry.Address introduces extra quotes without addr_spec parameter
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36769/test_email_address_with_quotes.py

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

From report at bugs.python.org  Thu Oct  2 02:49:37 2014
From: report at bugs.python.org (Michel Charpentier)
Date: Thu, 02 Oct 2014 00:49:37 +0000
Subject: [New-bugs-announce] [issue22536] Missing filename in
	FileNotFoundError
Message-ID: <1412210977.42.0.325510395327.issue22536@psf.upfronthosting.co.za>


New submission from Michel Charpentier:

FileNotFoundError should contain a 'filename' information, as per its specification.  It's 'None' after a failure to execute a subprocess.

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
files: bug.py
messages: 228147
nosy: charpov, ronaldoussoren
priority: normal
severity: normal
status: open
title: Missing filename in FileNotFoundError
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file36774/bug.py

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

From report at bugs.python.org  Thu Oct  2 05:09:34 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Oct 2014 03:09:34 +0000
Subject: [New-bugs-announce] [issue22537] Failure building 2.7 docs on
	Windows
Message-ID: <1412219374.89.0.582755946661.issue22537@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I was able to build docs of all versions with the old system.  When 3.4 was changed to the new system, 'pip install sphinx' installed everything needed so that 'sphinx-build -bhtml . build/html'  in .../Doc (Devguide 7.5.2) works for 3.4 (and 3.5).  "PYTHON=C:\programs\python27\python.exe" does not seem to matter.

After the recent conversion for 2.7, that command and 'make html' (devguide 7.5.1) do not work for 2.7. The devguide instructions are version-independent, but the reality does not seem to be.  Both commands give this.

Running Sphinx v1.2.2

Configuration error:
There is a syntax error in your configuration file: invalid syntax (patchlevel.py, line 71)
Did you change the syntax from 2.x to 3.x?

tools/patchlevel.py. line 71, is "print x'.  When I added ()s, this error goes away and I get

Running Sphinx v1.2.2

Exception occurred:
  File "F:\Python\dev\2\py27\Doc\tools\pyspecific.py", line 247, in <module>
    import suspicious
  File "F:\Python\dev\2\py27\Doc\tools\suspicious.py", line 57
    detect_all = re.compile(ur'''
    ::(?=[^=])|            # two :: (but NOT ::=)
    :[a-zA-Z][a-zA-Z0-9]+| # :foo
    `|                     # ` (seldom used by itself)
    (?<!\.)\.\.[ \t]*\w+:  # .. foo: (but NOT ... else:)
    ''', re.UNICODE | re.VERBOSE).finditer

      ^
SyntaxError: invalid syntax

I expect the problem is the 'ur' prefix, invalid in 3.4+.

I tried to install a 2.7 version of sphinx, but pip refuses.

C:\Programs\Python27>pip install sphinx
Requirement already satisfied (use --upgrade to upgrade): sphinx in c:\programs\python34\lib\site-packages

So I don't know how to sensibly proceed without disabling 3.x builds.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 228152
nosy: docs at python, ezio.melotti, georg.brandl, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Failure building 2.7 docs on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  2 05:51:11 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 02 Oct 2014 03:51:11 +0000
Subject: [New-bugs-announce] [issue22538] turtledemo two_canvases reversion
Message-ID: <1412221871.63.0.0767968395434.issue22538@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The turtledemo two-canvases was fixed a couple of months ago but subsequent patches have returned its bad behavior.  The first time selected, it runs but does not display the code.  The second time, the code is displayed.  Clicking start freezes the viewer because there is no longer a main function.  Will investigate.

----------
assignee: terry.reedy
messages: 228155
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: turtledemo two_canvases reversion
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct  2 13:38:30 2014
From: report at bugs.python.org (Artur de Sousa Rocha)
Date: Thu, 02 Oct 2014 11:38:30 +0000
Subject: [New-bugs-announce] [issue22539] Table formatting errors in pydoc
Message-ID: <1412249910.15.0.577492255731.issue22539@psf.upfronthosting.co.za>


New submission from Artur de Sousa Rocha:

Tables in pydoc are formatted incorrectly -- some lines are missing. Example in Python 3.4.1:

>>> help('TUPLES')
...
+----------------------------+----------------------------------+------------+
| Operation                  | Result                           | Notes      |
+============================+==================================+============+
| "x in s"                   | "True" if an item of *s* is      | (1)        |
+----------------------------+----------------------------------+------------+
| "x not in s"               | "False" if an item of *s* is     | (1)        |
+----------------------------+----------------------------------+------------+
| "s + t"                    | the concatenation of *s* and *t* | (6)(7)     |
+----------------------------+----------------------------------+------------+
| "s * n" or "n * s"         | *n* shallow copies of *s*        | (2)(7)     |
+----------------------------+----------------------------------+------------+
| "s[i]"                     | *i*th item of *s*, origin 0      | (3)        |
+----------------------------+----------------------------------+------------+
| "s[i:j]"                   | slice of *s* from *i* to *j*     | (3)(4)     |
+----------------------------+----------------------------------+------------+
| "s[i:j:k]"                 | slice of *s* from *i* to *j*     | (3)(5)     |
+----------------------------+----------------------------------+------------+
+----------------------------+----------------------------------+------------+
+----------------------------+----------------------------------+------------+
+----------------------------+----------------------------------+------------+
| "s.index(x[, i[, j]])"     | index of the first occurrence of | (8)        |
+----------------------------+----------------------------------+------------+
+----------------------------+----------------------------------+------------+


Older version of the same table in Python 3.2.5 in Cygwin console:

+--------------------+----------------------------------+------------+
| Operation          | Result                           | Notes      |
+====================+==================================+============+
| ``x in s``         | ``True`` if an item of *s* is    | (1)        |
|                    | equal to *x*, else ``False``     |            |
+--------------------+----------------------------------+------------+
| ``x not in s``     | ``False`` if an item of *s* is   | (1)        |
|                    | equal to *x*, else ``True``      |            |
+--------------------+----------------------------------+------------+
| ``s + t``          | the concatenation of *s* and *t* | (6)        |
+--------------------+----------------------------------+------------+
| ``s * n, n * s``   | *n* shallow copies of *s*        | (2)        |
|                    | concatenated                     |            |
+--------------------+----------------------------------+------------+
| ``s[i]``           | *i*th item of *s*, origin 0      | (3)        |
+--------------------+----------------------------------+------------+
| ``s[i:j]``         | slice of *s* from *i* to *j*     | (3)(4)     |
+--------------------+----------------------------------+------------+
| ``s[i:j:k]``       | slice of *s* from *i* to *j*     | (3)(5)     |
|                    | with step *k*                    |            |
+--------------------+----------------------------------+------------+
| ``len(s)``         | length of *s*                    |            |
+--------------------+----------------------------------+------------+
| ``min(s)``         | smallest item of *s*             |            |
+--------------------+----------------------------------+------------+
| ``max(s)``         | largest item of *s*              |            |
+--------------------+----------------------------------+------------+
| ``s.index(i)``     | index of the first occurence of  |            |
|                    | *i* in *s*                       |            |
+--------------------+----------------------------------+------------+
| ``s.count(i)``     | total number of occurences of    |            |
|                    | *i* in *s*                       |            |
+--------------------+----------------------------------+------------+

----------
assignee: docs at python
components: Documentation
messages: 228217
nosy: Artur.de.Sousa.Rocha, docs at python
priority: normal
severity: normal
status: open
title: Table formatting errors in pydoc
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct  2 13:39:12 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 02 Oct 2014 11:39:12 +0000
Subject: [New-bugs-announce] [issue22540] speed up isinstance and issubclass
	for the usual cases
Message-ID: <1412249952.63.0.934537522507.issue22540@psf.upfronthosting.co.za>


New submission from Georg Brandl:

With the introduction of ABCs, PyObject_IsInstance (and for this issue, everything is also valid for PyObject_IsSubclass) has to check for a type's __instancecheck__ before falling back to the built-in behavior.

However, the "type" type has an __instancecheck__ method (that calls the built-in behavior too), probably for consistency on the Python side.

This means that the fast path is never taken, and every isinstance() call is slowed down unnecessarily.

This patch introduces a new fast path by checking for PyType_Type exactly before looking up the __instancecheck__.

It also introduces a check for exact match in PyObject_IsSubclass() analogous to one that is already present in PyObject_IsInstance().  Note that this will break __subclasscheck__ implementations that would deny issubclass(C, C).

This patch is not only useful for speeding up isinstance() and issubclass() calls, but also has other effects such as not slowing down the improvement of issue #12029.

----------
components: Interpreter Core
files: pyobject_issubclass_isinstance_speedup.patch
keywords: patch
messages: 228218
nosy: georg.brandl, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: speed up isinstance and issubclass for the usual cases
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file36781/pyobject_issubclass_isinstance_speedup.patch

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

From report at bugs.python.org  Thu Oct  2 15:29:56 2014
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 02 Oct 2014 13:29:56 +0000
Subject: [New-bugs-announce] [issue22541] Support both side_effect and
	return_value in a more	human way
Message-ID: <1412256596.08.0.0171916837532.issue22541@psf.upfronthosting.co.za>


New submission from Dima Tisnek:

Original use case:

I want to mock something that on invocation does 2 things:
* updates database
* returns custom, unrelated value

The problem:
side_effect is a catch-all setting that is used for:
* true side-effects
* return values
* exceptions

Moreover, side_effect takes precedence over return_value, unless the earlier returns mock.DEFAULT. Very quirky.


Proposed change option 1:
Side-effect is not used as return value; explicit return value may be used for that purpose.
(probably changes a lot of tests)

Proposed change option 2:
return_value, being more specific and explicit, takes precedence over side_effect; that is side_effect is still executed but it's rv is lost if overwritten by return_value is set.
(this is unlikely to change existing tests, as it is currently very odd to use both side_effect and return_value at the same time.)


Current workaround 1:
mock.Mock(side_effect=lambda *args: [db.update(), mock.DEFAULT][-1],
          return_value=42)

Current workaround 2:
mock.Mock(side_effect=lambda *args: [db.update(), 42][-1])

----------
components: Library (Lib)
messages: 228224
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: Support both side_effect and return_value in a more human way
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct  2 19:47:40 2014
From: report at bugs.python.org (700eb415)
Date: Thu, 02 Oct 2014 17:47:40 +0000
Subject: [New-bugs-announce] [issue22542] Use syscall (eg. arc4random or
	getentropy) rather than	/dev/urandom when possible
Message-ID: <1412272060.2.0.302379812254.issue22542@psf.upfronthosting.co.za>


New submission from 700eb415:

Trying to run the python interpreter in a chroot fails if /dev/urandom is not present. Removing the "nodev" flag from the filesystem is not ideal in many situations.

Instead, we should utilize functions such as OpenBSD's arc4random(3) and the new potential getentropy() Linux syscall. Alternatively, libevent provides a portable version of arc4random(3) as a workaround.

This issue has been discussed extensively when forking LibreSSL. Since we're already providing win32 exceptions, we should at least use the syscall rather than device if it's defined.

----------
components: Build
messages: 228246
nosy: 700eb415
priority: normal
severity: normal
status: open
title: Use syscall (eg. arc4random or getentropy) rather than /dev/urandom when possible
versions: Python 3.3

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

From report at bugs.python.org  Thu Oct  2 23:32:00 2014
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=)
Date: Thu, 02 Oct 2014 21:32:00 +0000
Subject: [New-bugs-announce] [issue22543] -W option cannot use non-standard
	categories
Message-ID: <1412285520.72.0.615712160291.issue22543@psf.upfronthosting.co.za>


New submission from R?mi Rampin:

warnings._processoptions is called very early, before site-packages are enabled. Because of this, using a non-standard 'category' will almost certainly fail with the message:

    Invalid -W option ignored: invalid module name: '...'

The -W option would be a lot more useful if it could actually match non-standard categories (it does, after all, pretend to support modulename.classname).

I don't see any easy way of fixing this, other than initializing the warnings module later or matching category names with the given string (and getting rid of the import).

----------
components: Library (Lib)
messages: 228261
nosy: remram
priority: normal
severity: normal
status: open
title: -W option cannot use non-standard categories
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  3 09:18:17 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Oct 2014 07:18:17 +0000
Subject: [New-bugs-announce] [issue22544] Inconsistent cmath.log behaviour
Message-ID: <1412320697.54.0.866089400402.issue22544@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> inf = float('inf')
>>> z = complex(-0.0, -inf)
>>> cmath.log(z)
(inf-1.5707963267948966j)
>>> cmath.log10(z)
(inf-0.6821881769209206j)
>>> cmath.log(z, 10)
(inf+nan*j)

----------
components: Library (Lib)
messages: 228307
nosy: eric.smith, lemburg, mark.dickinson, pitrou, stutzbach
priority: low
severity: normal
status: open
title: Inconsistent cmath.log behaviour
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  3 10:40:44 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Oct 2014 08:40:44 +0000
Subject: [New-bugs-announce] [issue22545] incomplete complex repr() with
	negative zeroes
Message-ID: <1412325644.16.0.161101814263.issue22545@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

>>> complex(-0.0)
0j
>>> complex(-0.0).real
-0.0

----------
components: Interpreter Core
messages: 228310
nosy: eric.smith, lemburg, mark.dickinson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: incomplete complex repr() with negative zeroes
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  3 11:31:18 2014
From: report at bugs.python.org (Tommy Andersen)
Date: Fri, 03 Oct 2014 09:31:18 +0000
Subject: [New-bugs-announce] [issue22546] Wrong default precision in
	documentation for format
Message-ID: <1412328678.8.0.959126948842.issue22546@psf.upfronthosting.co.za>


New submission from Tommy Andersen:

The format documentation for the Format Specification Mini-Language for python 3.3 (perhaps newer and older as well) at: https://docs.python.org/3.3/library/string.html 

States for type '' (for floating point numbers):

    Similar to 'g', except with at least one digit past the decimal point and a default precision of 12. This is intended to match str(), except you can add the other format modifiers.

This appears not to be true, the following code example, run in Python 3.3.2:

>>> '{}'.format(3.14159265358979323846264338327950288419)
'3.141592653589793'

As it can be seen form the output the default precision appears to be 15.

----------
assignee: docs at python
components: Documentation
messages: 228318
nosy: Barium, docs at python
priority: normal
severity: normal
status: open
title: Wrong default precision in documentation for format
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct  3 15:19:59 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 03 Oct 2014 13:19:59 +0000
Subject: [New-bugs-announce] [issue22547] Implement an informative
	`BoundArguments.__repr__`
Message-ID: <1412342399.42.0.660286005018.issue22547@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
components: Library (Lib)
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement an informative `BoundArguments.__repr__`
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct  3 19:24:14 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Oct 2014 17:24:14 +0000
Subject: [New-bugs-announce] [issue22548] Bogus parsing of negative zeros in
	complex literals
Message-ID: <1412357054.52.0.79002389879.issue22548@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This may be a parser limitation...

>>> z = -0.-0.j
>>> z
(-0+0j)
>>> z.imag
0.0
>>> z = 0.-0.j
>>> z.imag
0.0

----------
components: Interpreter Core
messages: 228343
nosy: benjamin.peterson, mark.dickinson, pitrou
priority: low
severity: normal
status: open
title: Bogus parsing of negative zeros in complex literals
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct  3 19:36:30 2014
From: report at bugs.python.org (Kevin Hendricks)
Date: Fri, 03 Oct 2014 17:36:30 +0000
Subject: [New-bugs-announce] [issue22549] bug in accessing bytes,
	inconsistent with normal strings and python 2.7
Message-ID: <1412357790.8.0.103142585174.issue22549@psf.upfronthosting.co.za>


New submission from Kevin Hendricks:

Hi,

I am working on porting my ebook code from Python 2.7 to work with both Python 2.7 and Python 3.4 and have found the following inconsistency I think is a bug ...

KevinsiMac:~ kbhend$ python3
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

>>> o = '123456789'

>>> o[-3]
'7'

>>> type(o[-3])
<class 'str'>

>>> type(o)
<class 'str'>

the above is what I expected but under python 3 for bytes you get the following instead:

>>> o = b'123456789'

>>> o[-3]
55

>>> type(o[-3])
<class 'int'>

>>> type(o)
<class 'bytes'>
 


When I compare this to Python 2.7 for both bytestrings and unicode I see the expected behaviour. 

Python 2.7.7 (v2.7.7:f89216059edf, May 31 2014, 12:53:48) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.


>>> o = '123456789'

>>> o[-3]
'7'

>>> type(o[-3])
<type 'str'>

>>> type(o)
<type 'str'>


>>> o = u'123456789'

>>> o[-3]
u'7'

>>> type(o[-3])
<type 'unicode'>

>>> type(o)
<type 'unicode'>


I would consider this a bug as it makes it much harder to write python code that works on both python 2.7 and python 3.4

----------
components: Interpreter Core
messages: 228348
nosy: kevinbhendricks
priority: normal
severity: normal
status: open
title: bug in accessing bytes, inconsistent with normal strings and python 2.7
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Oct  3 20:29:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Oct 2014 18:29:35 +0000
Subject: [New-bugs-announce] [issue22550] issubclass can fail after module
	reloading
Message-ID: <1412360975.58.0.103678006739.issue22550@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Inspired by test failure in issue22540. This is still looks as a bug to me:

>>> import sys, decimal, numbers
>>> issubclass(decimal.Decimal, numbers.Number)
True
>>> del sys.modules['numbers']
>>> import numbers
>>> issubclass(decimal.Decimal, numbers.Number)
False

----------
messages: 228362
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: issubclass can fail after module reloading
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct  3 22:39:31 2014
From: report at bugs.python.org (Taylor Marks)
Date: Fri, 03 Oct 2014 20:39:31 +0000
Subject: [New-bugs-announce] [issue22551] Anything results in a SyntaxError
	after -i -u -c on	2.7.8 on Windows 7
Message-ID: <1412368771.6.0.381085911452.issue22551@psf.upfronthosting.co.za>


New submission from Taylor Marks:

On Python 2.7.8, on Windows 7, if I start up the Python interactive console using the flags -i -u -c, nothing else will be considered valid syntax from that point forward.

My understanding is:

-i tells Python to enter interactive mode after it's done running whatever else it's told to do
-u tells Python to not buffer output
-c tells Python to treat any further arguments as Python code and to run it
None of these flags should be causing the issues that I'm seeing, I don't think.

Example:

$ python -i -u -c "print('Test')"
Test
>>> print('verify')
  File "<stdin>", line 1
    print('verify')
                ^
SyntaxError: invalid syntax

This doesn't occur on my computer running OS X Mavericks (10.9.4) and Python 2.7.6 which leads me to think this may be a platform or version specific issue...

----------
components: Interpreter Core, Windows
messages: 228373
nosy: Taylor.Marks
priority: normal
severity: normal
status: open
title: Anything results in a SyntaxError after -i -u -c on 2.7.8 on Windows 7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct  4 03:54:49 2014
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 04 Oct 2014 01:54:49 +0000
Subject: [New-bugs-announce] [issue22552] ctypes.LibraryLoader returns
	singleton objects, resulting in usage conflicts
Message-ID: <1412387689.66.0.814406977046.issue22552@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

a LibraryLoader returns the same _FuncPtr object for a given function every time. This way, if two libraries set its attributes (most possibly, `argtypes') to incompatible values (both representing the same C-level entities), one of them will stop working.

I've just discovered such a problem with `pyreadline' and `colorama' which both utilize `windll.kernel32.GetConsoleScreenBufferInfo'.

One solution is to make LibraryLoader return a new object each time. Another (worse IMO) is to provide a clone function for _FuncPtr (it cannot be clones by `copy.copy()').

An example code:

>>> import pyreadline
>>> import pip._vendor.colorama
Readline internal error
Traceback (most recent call last):
  File "c:\python27\lib\site-packages\pyreadline\console\console.py", line 768,
in hook_wrapper_23
    res = ensure_str(readline_hook(prompt))
  File "c:\python27\lib\site-packages\pyreadline\rlmain.py", line 569, in readline
    self.readline_setup(prompt)
  File "c:\python27\lib\site-packages\pyreadline\rlmain.py", line 565, in readline_setup
    self._print_prompt()
  File "c:\python27\lib\site-packages\pyreadline\rlmain.py", line 466, in _print_prompt
    x, y = c.pos()
  File "c:\python27\lib\site-packages\pyreadline\console\console.py", line 261,
in pos
    self.GetConsoleScreenBufferInfo(self.hout, byref(info))
ArgumentError: argument 2: <type 'exceptions.TypeError'>: expected LP_CONSOLE_SCREEN_BUFFER_INFO instance instead of pointer to CONSOLE_SCREEN_BUFFER_INFO

(the same error is printed continuously, on Ctrl-C, the interpreter crashes)

----------
components: ctypes
messages: 228423
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: ctypes.LibraryLoader returns singleton objects, resulting in usage conflicts
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct  4 18:00:47 2014
From: report at bugs.python.org (Eric Fulton)
Date: Sat, 04 Oct 2014 16:00:47 +0000
Subject: [New-bugs-announce] [issue22553] Diagram issue
Message-ID: <1412438447.77.0.331037308598.issue22553@psf.upfronthosting.co.za>


New submission from Eric Fulton:

I believe the diagram showing how slices works from https://docs.python.org/2/tutorial/introduction.html is incorrect.  There should be no 6.  

>>> word = 'Python'
>>> word[6]
IndexError: string index out of range


Original:
 +---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
-6  -5  -4  -3  -2  -1

What it should be:
 +---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   
-6  -5  -4  -3  -2  -1


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

One way to remember how slices work is to think of the indices as pointing between characters, with the left edge of the first character numbered 0. Then the right edge of the last character of a string of n characters has index n, for example:

 +---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
-6  -5  -4  -3  -2  -1

----------
assignee: docs at python
components: Documentation
messages: 228464
nosy: Eric.Fulton, docs at python
priority: normal
severity: normal
status: open
title: Diagram issue

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

From report at bugs.python.org  Sat Oct  4 22:49:00 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Oct 2014 20:49:00 +0000
Subject: [New-bugs-announce] [issue22554] Idle: optionally auto-pop-up
	completion window for names
Message-ID: <1412455740.59.0.488205604563.issue22554@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Currently auto popup after delay only after '.' or in a string.

----------
components: IDLE
messages: 228492
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: optionally auto-pop-up completion window for names
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Oct  5 06:01:43 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Oct 2014 04:01:43 +0000
Subject: [New-bugs-announce] [issue22555] Tracking issue for adjustments to
	binary/text boundary	handling
Message-ID: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

See PEP 478 for the PEP level items targeting 3.5: http://www.python.org/dev/peps/pep-0478/

This is a tracking issue to help me keep track of some lower level items that didn't make the release PEP:

* Improved Windows console Unicode support (see
https://pypi.python.org/pypi/win_unicode_console for details)
* Changing the encoding and error handling of an existing stream
(http://bugs.python.org/issue15216)
* Allowing "backslashreplace" to be used on input (http://bugs.python.org/issue22286)
* Adding "codecs.convert_surrogates" (http://bugs.python.org/issue18814)
* Adding "wsgiref.util.dump_wsgistr" and "wsgiref.util.load_wsgistr" (http://bugs.python.org/issue22264)
* Adding "bytes.hex", "bytearray.hex" and "memoryview.hex" (http://bugs.python.org/issue9951)
* Adding a binary data formatting mini-language (depends on 9951, likely needs to be escalated to a full PEP for design discussion visibility) (http://bugs.python.org/issue22385)

Going back and updating http://www.python.org/dev/peps/pep-0467/ based on the last round of feedback is also on my personal todo list for 3.5.

----------
messages: 228536
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Tracking issue for adjustments to binary/text boundary handling

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

From report at bugs.python.org  Sun Oct  5 10:38:46 2014
From: report at bugs.python.org (Ankit Dhebar)
Date: Sun, 05 Oct 2014 08:38:46 +0000
Subject: [New-bugs-announce] [issue22556] datetime comparison with 'None'
	returning a TypeError
Message-ID: <1412498326.6.0.319786420507.issue22556@psf.upfronthosting.co.za>


New submission from Ankit Dhebar:

code snippet
student_tuple = [ ('ykjsdf', 'A', 17, datetime.date(2014,10,15)), ('accjr', 'C', 11, datetime.date(2013,05,05)), ('dgekw', 'B', 5, datetime.date(1987,03,03)) ]

Output for the above code works as expected.
o/p : [('dgekw', 'B', 5, datetime.date(1987, 3, 3)), ('accjr', 'C', 11, datetime.date(2013, 5, 5)), ('ykjsdf', 'A', 17, datetime.date(2014, 10, 15))]

but when you make one of the above datetime.date as 'None' like below

student_tuple = [ ('ykjsdf', 'A', 17, datetime.date(2014,10,15)), ('accjr', 'C', 11, None), ('dgekw', 'B', 5, datetime.date(1987,03,03)) ]
 
o/p : TypeError: can't compare datetime.date to NoneType

In my opinion, the 'NoneType' should appear either in the beginning or towards the end after sorting is done.

----------
components: Tests
files: sorting_func.py
messages: 228543
nosy: pythoner
priority: normal
severity: normal
status: open
title: datetime comparison with 'None' returning a TypeError
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file36809/sorting_func.py

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

From report at bugs.python.org  Sun Oct  5 14:29:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Oct 2014 12:29:01 +0000
Subject: [New-bugs-announce] [issue22557] Locale import is too slow
Message-ID: <1412512141.77.0.0512115045124.issue22557@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Locale import is too slow in comparison with caching module in a global or even in sys.modules.

>>> import timeit
>>> def f():
...     import locale
... 
>>> min(timeit.repeat(f, number=100000, repeat=10))
0.4501200000013341
>>> _locale = None
>>> def g():
...     global _locale
...     if _locale is None:
...         import _locale
... 
>>> min(timeit.repeat(g, number=100000, repeat=10))
0.07821200000034878
>>> import sys
>>> def h():
...     try:
...         locale = sys.modules['locale']
...     except KeyError:
...         import locale
... 
>>> min(timeit.repeat(h, number=100000, repeat=10))
0.12357599999813829

I think there is an overhead of look up __import__, packing arguments in a tuple and calling a function. This can be omitted by looking first in sys.module and calling __import__ only when nothing was found.

----------
components: Interpreter Core
messages: 228561
nosy: brett.cannon, eric.snow, ncoghlan, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Locale import is too slow
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct  5 15:05:37 2014
From: report at bugs.python.org (Friedrich Spee von Langenfeld)
Date: Sun, 05 Oct 2014 13:05:37 +0000
Subject: [New-bugs-announce] [issue22558] Missing hint to source code -
	complete
Message-ID: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>


New submission from Friedrich Spee von Langenfeld:

As mentioned in Issue22528, in some modules? documentation, the link to their source code is missing. To check the stdlib, I?ve written the script missing_hint.py.
It seems that in the following module entries, there aren?t a link to their source code (the last part of output of missing_hint.py):
https://docs.python.org/3/library/aifc.html
https://docs.python.org/3/library/base64.html
https://docs.python.org/3/library/binhex.html
https://docs.python.org/3/library/bz2.html
https://docs.python.org/3/library/cgi.html
https://docs.python.org/3/library/cgitb.html
https://docs.python.org/3/library/chunk.html
https://docs.python.org/3/library/code.html
https://docs.python.org/3/library/codecs.html
https://docs.python.org/3/library/codeop.html
https://docs.python.org/3/library/configparser.html
https://docs.python.org/3/library/copy.html
https://docs.python.org/3/library/copyreg.html
https://docs.python.org/3/library/csv.html
https://docs.python.org/3/library/datetime.html
https://docs.python.org/3/library/decimal.html
https://docs.python.org/3/library/difflib.html
https://docs.python.org/3/library/doctest.html
https://docs.python.org/3/library/fnmatch.html
https://docs.python.org/3/library/formatter.html
https://docs.python.org/3/library/ftplib.html
https://docs.python.org/3/library/getpass.html
https://docs.python.org/3/library/glob.html
https://docs.python.org/3/library/hashlib.html
https://docs.python.org/3/library/imaplib.html
https://docs.python.org/3/library/imp.html
https://docs.python.org/3/library/io.html
https://docs.python.org/3/library/locale.html
https://docs.python.org/3/library/lzma.html
https://docs.python.org/3/library/macpath.html
https://docs.python.org/3/library/mailbox.html
https://docs.python.org/3/library/mimetypes.html
https://docs.python.org/3/library/nntplib.html
https://docs.python.org/3/library/numbers.html
https://docs.python.org/3/library/os.html
https://docs.python.org/3/library/pathlib.html
https://docs.python.org/3/library/pickle.html
https://docs.python.org/3/library/plistlib.html
https://docs.python.org/3/library/poplib.html
https://docs.python.org/3/library/profile.html
https://docs.python.org/3/library/pydoc.html
https://docs.python.org/3/library/py_compile.html
https://docs.python.org/3/library/quopri.html
https://docs.python.org/3/library/re.html
https://docs.python.org/3/library/sched.html
https://docs.python.org/3/library/selectors.html
https://docs.python.org/3/library/shelve.html
https://docs.python.org/3/library/shutil.html
https://docs.python.org/3/library/smtplib.html
https://docs.python.org/3/library/sndhdr.html
https://docs.python.org/3/library/socket.html
https://docs.python.org/3/library/ssl.html
https://docs.python.org/3/library/stat.html
https://docs.python.org/3/library/stringprep.html
https://docs.python.org/3/library/struct.html
https://docs.python.org/3/library/subprocess.html
https://docs.python.org/3/library/telnetlib.html
https://docs.python.org/3/library/tempfile.html
https://docs.python.org/3/library/timeit.html
https://docs.python.org/3/library/traceback.html
https://docs.python.org/3/library/tracemalloc.html
https://docs.python.org/3/library/turtle.html
https://docs.python.org/3/library/uuid.html
https://docs.python.org/3/library/xdrlib.html

Is it possible to add the specific source code link to all of this entries?

----------
assignee: docs at python
components: Documentation
files: missing_hint.py
messages: 228563
nosy: Friedrich.Spee.von.Langenfeld, docs at python
priority: normal
severity: normal
status: open
title: Missing hint to source code - complete
Added file: http://bugs.python.org/file36812/missing_hint.py

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

From report at bugs.python.org  Sun Oct  5 22:25:56 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 05 Oct 2014 20:25:56 +0000
Subject: [New-bugs-announce] [issue22559] [backport] ssl.MemoryBIO
Message-ID: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Attached patch is a first-cut at a backport patch. Note that it is not quite a 1-1 with the original:

The SSL module backport added a new field for the Python-level "SSLSocket" reference (ssl_sock), which was a different object from the _socket.socket (PySocketObject *) object. This is all effectively supplanted by the new owner field, so this patch does that as well.

The patch looks basically complete to me, but the tests hang for some reason: in a test where the client side hangs up (test_check_hostname) the server side of the socket blocks in a call to read(). I'm not sure why.

Antoine, or anyone else who worked on the original patch, did you run into any issues like this, or have any other insights into what might be causing it?

----------
files: memory-bio.diff
keywords: patch
messages: 228618
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: [backport] ssl.MemoryBIO
versions: Python 2.7
Added file: http://bugs.python.org/file36820/memory-bio.diff

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

From report at bugs.python.org  Mon Oct  6 00:28:22 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 05 Oct 2014 22:28:22 +0000
Subject: [New-bugs-announce] [issue22560] Add loop-agnostic SSL
	implementation to asyncio
Message-ID: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Now that #21965 is implemented, it is possible to improve SSL support in asyncio by making it independent of how the underlying event loop works (e.g. whether it is a Unix-like reactor or a proactor).

----------
messages: 228628
nosy: geertj, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: Add loop-agnostic SSL implementation to asyncio
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct  6 04:58:06 2014
From: report at bugs.python.org (Jens Troeger)
Date: Mon, 06 Oct 2014 02:58:06 +0000
Subject: [New-bugs-announce] [issue22561] PyUnicode_InternInPlace crashes
Message-ID: <1412564286.37.0.93654303592.issue22561@psf.upfronthosting.co.za>


New submission from Jens Troeger:

This might be an issue with Python, or an issue with Libre/OpenOffice not setting up the UNO environment correctly.

The crash happens during "import uno" of Python 3.3 in the PyUnicode_InternInPlace function. I've done some digging and posted more information about this crash in this forum:

  http://en.libreofficeforum.org/node/9195

----------
components: Unicode
messages: 228635
nosy: _savage, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: PyUnicode_InternInPlace crashes
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Oct  6 07:06:50 2014
From: report at bugs.python.org (Leo)
Date: Mon, 06 Oct 2014 05:06:50 +0000
Subject: [New-bugs-announce] [issue22562] Singleton pattern for namedtuple
Message-ID: <1412572010.78.0.424974650415.issue22562@psf.upfronthosting.co.za>


New submission from Leo:

Each call of namedtuple will create a new class object even if an equal class, i.e. for the same fields has been created before.
Applying the singleton pattern would be more efficient at least in two respects: 
* it would reduce the number of class objects.
* checking for field names can be done by calling isinstance.

I therefore propose a new boolean keyword argument 'singleton' for the namedtuple function. It should 
default to True. If a pre-existing rather than new class object is returned, the provided class name is 
disregarded. In many cases, the caller will use a local binding anyway.
 
The singleton pattern could be implemented along the following schema:

cache = {}
if not fields in cache:
    cache[fields] = new_namedtuple
return cache[fields]

----------
components: Library (Lib)
messages: 228640
nosy: fhaxbox66 at googlemail.com
priority: normal
severity: normal
status: open
title: Singleton pattern for namedtuple
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct  6 07:10:55 2014
From: report at bugs.python.org (Leo)
Date: Mon, 06 Oct 2014 05:10:55 +0000
Subject: [New-bugs-announce] [issue22563] namedtuple: raise an exception
	when the given class name	would override an existing name
Message-ID: <1412572255.28.0.408483770969.issue22563@psf.upfronthosting.co.za>


New submission from Leo:

The nametuple function creates classes dynamically. The caller must provide the class name thus overriding any existing object name. 
An overridden object may be garbage-collected
or survive depending on its reference count.

While this behavior is not new to Python, I am unaware of a simple function with such an awkward side effect. 
One might consider this a feature rather than a bug
thus shifting responsibility for carefully passing suitable class names to nametuple. 
However, I believe nametuple should raise an exception
if the provided name would override an existing name. If needed, this behavior could be made 
customizable by a keyword argument override defaulting to False. 

Consequently, the caller would have to delete the object under that 
name explicitly before calling nametuple. This behavior would increase code clarity and eliminate? a source of subtle
errors. 


The code example given below shows the survival of 
a pre-existing class due to an instance linked to it. As a consequence, two different classes with the same name exist. Only the posterior is, 
however, bound to the
__main__ namespace. The prior is no longer known to that namespace potentially breaking
remote parts of the code.
 

In [1]: from collections import namedtuple

In [2]: AB=namedtuple('AB', ('a','b'))

In [3]: ab=AB(4,9)

In [4]: type(ab)
Out[4]: __main__.AB

In [6]: AB=namedtuple('AB', ('c','d'))

In [7]: type(ab)
Out[7]: __main__.AB

In [8]: ab2=AB(16,25)

In [9]: type(ab2)
Out[9]: __main__.AB

In [10]: type(ab)
Out[10]: __main__.AB

In [11]: ab
Out[11]: AB(a=4, b=9)

In [12]: ab2
Out[12]: AB(c=16, d=25)

----------
components: Library (Lib)
messages: 228641
nosy: fhaxbox66 at googlemail.com
priority: normal
severity: normal
status: open
title: namedtuple: raise an exception when the given class name would override an existing name
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct  6 12:14:25 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Oct 2014 10:14:25 +0000
Subject: [New-bugs-announce] [issue22564] ssl: post-commit review of the new
	memory BIO API
Message-ID: <1412590465.24.0.24710969124.issue22564@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi,

I just saw that the changeset a79003f25a41 was merged and it adds support for memory BIO to the Python ssl module, great! It's a nice addition, especially because it becomes possible to implement SSL for IOCP event loop in asyncio (#22560).

I read the changeset and I have a few comments. Sorry, I didn't have time before to review the patch. I prefer to open a new issue. I'm interested to work on patches, but I would prefer a first feedback before working on a patch.


+.. method:: SSLSocket.read(len=0, buffer=None)

Hum, I fear that some people will call read() with two parameters by mistake. I would prefer a keyword-only parameter: put a "$" in the call to PyArg_ParseTuple() in PySSL_SSLread().

The "read()" method is quite generic, many Python functions expect a "file-like" object with a read() method which only take one indexed parameter.

An alternative would be to implemented readinto() and drop the buffer parameter from read().

Same remark for SSLObject.read() and _ssl._SSLSocket.read().


+.. attribute:: SSLSocket.server_hostname
+
+   A ``bytes`` instance (...)
+
+   .. versionadded:: 3.5

Oh, I would prefer to have a Unicode string here, but I see that the attribute is *not* new, it's already present in Python 3.4.

The versionadded field is wrong. It looks like the attribute was introduced in Python 3.2:
https://docs.python.org/dev/whatsnew/3.2.html#ssl

Maybe the change is that the attribute now also exists in the _ssl module? But the _ssl module is not documented.


+.. method:: MemoryBIO.write_eof()
+
+   Write an EOF marker to the memory BIO. After this method has been called, it
+   is illegal to call :meth:`~MemoryBIO.write`.

What does it mean, "illegal"? An exception is raised? Maybe it would be more explicit to say that an exception is raised.


+- All IO on an :class:`SSLObject` is non-blocking. This means that for example
+  :meth:`~SSLSocket.read` will raise an :exc:`SSLWantReadError` if it needs
+  more data than the incoming BIO has available.

It would be nice to repeat this information in the documentation of the SSLObject.read() method.


+.. method:: SSLContext.wrap_bio(incoming, outgoing, server_side=False, \

Why not puting the documentation of this method where the SSLContext is documented?


+Some notes related to the use of :class:`SSLObject`:

I suggest to move these notes just after the documentation of the SSLObject class.


+The following methods are available from :class:`SSLSocket`:

methods and *attributes*.


+class SSLObject:
+    """This class implements an interface on top of a low-level SSL object as
+    implemented by OpenSSL. This object captures the state of an SSL connection
+    but does not provide any network IO itself. IO needs to be performed
+    through separate "BIO" objects which are OpenSSL's IO abstraction layer.
+
+    This class does not have a public constructor. Instances are returned by
+    ``SSLContext.wrap_bio``. This class is typically used by framework authors
+    that want to implement asynchronous IO for SSL through memory buffers.
+
+    When compared to ``SSLSocket``, this object lacks the following features:
+
+     * Any form of network IO incluging methods such as ``recv`` and ``send``.
+     * The ``do_handshake_on_connect`` and ``suppress_ragged_eofs`` machinery.
+    """

This documentation is useful. It should be copied in the documentation of the SSLObject class.


+.. class:: MemoryBIO
+
+   A memory buffer that can be used to pass data between Python and an SSL
+   protocol instance.
+
+.. attribute:: MemoryBIO.pending
+
+   Return the number of bytes currently in the memory buffer.

I prefer when class methods and attributes are part of the "class" block in the documentation, the documentation is rendered differently and it's more readable IMO.

Compare:
   https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
with:
   https://docs.python.org/dev/library/io.html#io.IOBase

But the choice how to document methods and attributes was not made in the memory BIO changeset, it is older. I suggest to "upgrade" to style to use the same style than the io module (put everything in the ".. class:" block).

What do you think?

----------
messages: 228653
nosy: haypo
priority: normal
severity: normal
status: open
title: ssl: post-commit review of the new memory BIO API
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct  6 12:54:22 2014
From: report at bugs.python.org (Lars Buitinck)
Date: Mon, 06 Oct 2014 10:54:22 +0000
Subject: [New-bugs-announce] [issue22565] missing const in declaration of
	PyErr_WarnEx in C-API	docs
Message-ID: <1412592862.35.0.877932125102.issue22565@psf.upfronthosting.co.za>


New submission from Lars Buitinck:

The declaration for PyErr_WarnEx in Doc/c-api/exceptions.rst is missing a const compared to Include/warnings.h.

----------
assignee: docs at python
components: Documentation
files: pyerr_warnex_const.patch
keywords: patch
messages: 228657
nosy: docs at python, larsmans
priority: normal
severity: normal
status: open
title: missing const in declaration of PyErr_WarnEx in C-API docs
versions: Python 3.5
Added file: http://bugs.python.org/file36824/pyerr_warnex_const.patch

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

From report at bugs.python.org  Mon Oct  6 13:50:43 2014
From: report at bugs.python.org (Mc128k)
Date: Mon, 06 Oct 2014 11:50:43 +0000
Subject: [New-bugs-announce] [issue22566] International keyboard makes IDLE
	crash on OSX
Message-ID: <1412596243.63.0.694179369479.issue22566@psf.upfronthosting.co.za>


New submission from Mc128k:

When using OSX 10.9 or 10.10 with the latest version of python, if I type ' or " with the international keyboard enabled (dead keys), the program crashes immediately. This can be reproduced in any occasion.

----------
messages: 228663
nosy: mc128k
priority: normal
severity: normal
status: open
title: International keyboard makes IDLE crash on OSX
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct  6 16:06:46 2014
From: report at bugs.python.org (Yoav Caspi)
Date: Mon, 06 Oct 2014 14:06:46 +0000
Subject: [New-bugs-announce] [issue22567] doctest handle ignored execption
Message-ID: <1412604406.09.0.877786474305.issue22567@psf.upfronthosting.co.za>


New submission from Yoav Caspi:

When implementing a class with a __del__ function that raise an exception the exception ignored.
is it possible to add this printed message to be tested by doc test?

something like when running this script the script will pass:
 
"""
Usage Example:
    >>> cls = Module()
    >>> del cls
    Exception Exception: Exception('oops',) in <bound method Module.__del__ of <__main__.Module object at 0x000000000XXXXXXX>> ignored
"""

class Module(object):
    def __del__(self):
        raise Exception("oops")

if __name__ == '__main__':
    from doctest import testmod
    print testmod()

----------
components: Tests
messages: 228685
nosy: Yoav.Caspi
priority: normal
severity: normal
status: open
title: doctest handle ignored execption
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct  6 16:20:05 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Mon, 06 Oct 2014 14:20:05 +0000
Subject: [New-bugs-announce] [issue22568] Use of "utime" as variable name in
	Modules/posixmodule.c	causes errors
Message-ID: <1412605205.62.0.227720568137.issue22568@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

Under certain circumstances, Modules/posixmodule.c will fail to compile due to a number of utime-related functions using a variable named "utime" when a function named "utime" already exists in the compiler's C header files.  Specifically, if the following are undefined:

HAVE_UTIMENSAT
HAVE_UTIMES

and the following are defined:

HAVE_UTIMENSAT
HAVE_LUTIMES
HAVE_UTIME_H

the compiler will fail because the UTIME_TO_UTIMBUF module attempts to access utime->now when utime is acutually a function included from utime.h.

I've attached a patch that renames the uname functions' parameter "utime" to "ut" to avoid the conflict.

This bug was encountered using Open Watcom 2.0 (owcc) under GNU/Linux 32-bit.

----------
components: Interpreter Core
files: utime-3.4.1.patch
keywords: patch
messages: 228690
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Use of "utime" as variable name in Modules/posixmodule.c causes errors
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file36825/utime-3.4.1.patch

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

From report at bugs.python.org  Mon Oct  6 16:34:28 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 06 Oct 2014 14:34:28 +0000
Subject: [New-bugs-announce] [issue22569] Add support for weakrefs to
	_socket.socket
Message-ID: <1412606068.52.0.637993896341.issue22569@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This is needed to keep the _ssl module reasonably in sync with it's Python3 counterpart.

----------
files: weakref-me-captain.diff
keywords: needs review, patch
messages: 228695
nosy: alex, benjamin.peterson
priority: normal
severity: normal
status: open
title: Add support for weakrefs to _socket.socket
versions: Python 2.7
Added file: http://bugs.python.org/file36826/weakref-me-captain.diff

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

From report at bugs.python.org  Mon Oct  6 17:33:51 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 06 Oct 2014 15:33:51 +0000
Subject: [New-bugs-announce] [issue22570] Better stdlib support for Path
	objects
Message-ID: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

pathlib is really nice, but currently it's rather inconvenient to use due to the lack of support in other parts of the stdlib for Path objects.  For historical reasons, everything accepts string paths, but few places accept Paths.  As an example: configparser.ConfigParser.read() but there are lots of others.

I'm opening this bug to start a conversation about better support for Path objects in the stdlib.  Against all hope, I wish there was a simple way to extend the compatibility, but I don't like having to sprinkle `str(some_path)` calls everywhere (kind of defeats the purpose of having the nicer pathlib API IMHO).  I suspect instead that it will be a matter of adding type tests or str() conversions to the relevant methods, but there may be other issues to discuss, like is it even a good idea to do this? ;)

----------
messages: 228704
nosy: barry
priority: normal
severity: normal
status: open
title: Better stdlib support for Path objects
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct  6 22:23:24 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Oct 2014 20:23:24 +0000
Subject: [New-bugs-announce] [issue22571] Remove import * recommendations
	and examples in doc?
Message-ID: <1412627004.13.0.564055290321.issue22571@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

PEP 8 recommends against 'from mod import *' because it makes reading harder and is bad for code analysis.  My experience with retrofitting tests to idlelib modules with tkinter * imports is that it also makes testing harder since the testing strategy depends on the specific tkinter objects actually used.  So either an explicit list ('from tkinter import x, y, z') or a searchable prefix ('tk.') makes testing easier.  

Some time ago, 'from tkinter import *' was changed to 'import tkinter as tk' in the tkinter doc examples, though *not* the text.  ##10031 changed the import section of the FAQ to "remove the advice to use "from ... import *" with some modules" (from the commit message).  Should we finish the job?  Or leave the issue to individual chapter authors?

Here is the edited result of grepping 'import *' in ...\py34\Doc\*.rst with Idle.

F:\Python\dev\4\py34\Doc\distutils\apiref.rst: 1289: This module is safe to use in ``from ... import *`` mode; it only exports
F:\Python\dev\4\py34\Doc\library\cmd.rst: 234:     from turtle import *
F:\Python\dev\4\py34\Doc\library\collections.abc.rst: 14:    from collections import *
F:\Python\dev\4\py34\Doc\library\collections.rst: 11:     from collections import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 54:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 86:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 320:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 562:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 671:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 695:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 714:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 914:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 1074:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\ctypes.rst: 1122:    >>> from ctypes import *
F:\Python\dev\4\py34\Doc\library\decimal.rst: 20:    from decimal import *
F:\Python\dev\4\py34\Doc\library\decimal.rst: 56:      >>> from decimal import *
F:\Python\dev\4\py34\Doc\library\decimal.rst: 125:    >>> from decimal import *
F:\Python\dev\4\py34\Doc\library\difflib.rst: 13:    from difflib import *
F:\Python\dev\4\py34\Doc\library\itertools.rst: 12:    from itertools import *
F:\Python\dev\4\py34\Doc\library\stat.rst: 104:    from stat import *
F:\Python\dev\4\py34\Doc\library\statistics.rst: 13:    from statistics import *
F:\Python\dev\4\py34\Doc\library\struct.rst: 313:    >>> from struct import *
F:\Python\dev\4\py34\Doc\library\tkinter.rst: 63:    from tkinter import *
F:\Python\dev\4\py34\Doc\library\tkinter.rst: 580:    from tkinter import *
F:\Python\dev\4\py34\Doc\library\tkinter.tix.rst: 60:       from tkinter.constants import *
F:\Python\dev\4\py34\Doc\library\tkinter.ttk.rst: 38:    from tkinter import *
F:\Python\dev\4\py34\Doc\library\tkinter.ttk.rst: 39:    from tkinter.ttk import *
F:\Python\dev\4\py34\Doc\library\turtle.rst: 11:    from turtle import *

F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 102:    >>> from fibo import *
F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 461: Now what happens when the user writes ``from sound.effects import *``?  Ideally,
F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 470: list of module names that should be imported when ``from package import *`` is
F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 479: This would mean that ``from sound.effects import *`` would import the three
F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 482: If ``__all__`` is not defined, the statement ``from sound.effects import *``
F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 493:    from sound.effects import *
F:\Python\dev\4\py34\Doc\tutorial\modules.rst: 501: patterns when you use ``import *``, it is still considered bad practise in
F:\Python\dev\4\py34\Doc\tutorial\stdlib2.rst: 372:    >>> from decimal import *

I removed the reference hits that simply explain.  I have not looked at whether the tutorial goes beyond explanation, but should this even be mentioned in so many places?

----------
assignee: docs at python
components: Documentation
messages: 228734
nosy: docs at python, georg.brandl, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove import * recommendations and examples in doc?
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Oct  7 00:22:22 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Oct 2014 22:22:22 +0000
Subject: [New-bugs-announce] [issue22572] NoneType object is not iterable
	error when asyncio	Server.close() called
Message-ID: <1412634142.26.0.655419754682.issue22572@psf.upfronthosting.co.za>


New submission from R. David Murray:

I'm writing a little web server using aiohttp.  I tried to write a unit test...since this is a client server situation I launched the asyncio program in a thread and did a urlopen from the main thread.  That all works fine...the problem is in the cleanup code.  When I try to stop the server I created via create_server, I get the error in the title.

I've attached a stripped down version of my attempted unit test.  It does require aiohttp...I'm not well enough versed in asyncio yet to rewrite it using more fundamental pieces.

I may be doing something stupid here, but it seems to me that even if I am close should not throw this error (the error implies that it is already shut down, so I'd think the close would be a no-op).

----------
components: asyncio
files: waiter_bug.py
messages: 228742
nosy: gvanrossum, haypo, r.david.murray, yselivanov
priority: normal
severity: normal
status: open
title: NoneType object is not iterable error when asyncio Server.close() called
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36830/waiter_bug.py

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

From report at bugs.python.org  Tue Oct  7 01:53:13 2014
From: report at bugs.python.org (dingo_dasher)
Date: Mon, 06 Oct 2014 23:53:13 +0000
Subject: [New-bugs-announce] [issue22573] AttributeErrors in long lines
	showing 'wrong' line in	error message
Message-ID: <1412639593.33.0.263693537062.issue22573@psf.upfronthosting.co.za>


New submission from dingo_dasher:

I am using Flask, and I had the following code:

        modules = models.Module.query.join(models.ModuleAccess).\
                         filter(models.Model.owner_id == current_user.id).\
                         filter(models.ModuleAccess.user_id == current_user.id).\
                         filter(models.ModuleAccess.module_id == models.Module.id).\
                         filter(models.ModuleAccess.write_access == True)

This code had a bug -> "models.Model.owner_id" in the first line. This was a typo, and Python gave me an AttributeError, just as I would expect. However, this is the error I was given:

Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1820, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1403, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python3.4/dist-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python3.4/dist-packages/flask/_compat.py", line 33, in reraise
    raise value
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.4/dist-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.4/dist-packages/flask_login.py", line 758, in decorated_view
    return func(*args, **kwargs)
  File "/home/dingo/UIM/app/views.py", line 175, in modules
    filter(models.ModuleAccess.write_access == True)
AttributeError: 'module' object has no attribute 'Model'

It shows me the last line of that long statement, "models.ModuleAccess.write_access == True" as the beginning of the trace. The trace doesn't show the models.Module.whatever line that actually caused the error.

It seems to be like Python here takes the last line of the exception-causing statement and shows that along with the "actual" error message (which was on the money): AttributeError: 'module' object has no attribute 'Model'

This seems to me slightly misleading. I submit that a better behaviour would be to show the line that caused the exception (I assume/hope that is possible since python knew it was accessing the Model attribute of the module object that caused the error).

I classified this as a behaviour bug rather than an enhancement, because I believe this would not be intended behaviour. I don't know if that's the case.

I apologise if this doesn't fit in "Intepreter core", but exceptions are builtins... I didn't know where else to put it.

----------
components: Interpreter Core
messages: 228749
nosy: dingo_dasher
priority: normal
severity: normal
status: open
title: AttributeErrors in long lines showing 'wrong' line in error message
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct  7 11:48:15 2014
From: report at bugs.python.org (Pierre-Antoine BRAMERET)
Date: Tue, 07 Oct 2014 09:48:15 +0000
Subject: [New-bugs-announce] [issue22574] super() and del in the same method
	leads to	UnboundLocalError
Message-ID: <1412675295.92.0.427134120521.issue22574@psf.upfronthosting.co.za>


New submission from Pierre-Antoine BRAMERET:

Hi,

With the following code:

class Base(object): pass

class Foo(Base):
  def __init__(self):
    super(Foo,self).__init__()
    if False:
      del Foo


I expect that Foo() would give me a Foo instance. Instead, it raises the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __init__
    super(Foo,self).__init__()
UnboundLocalError: local variable 'Foo' referenced before assignment



I first suspected the "del Foo" statement is executed before the function is executed (while parsing or something), because the error tells Foo does not exists.

Howver, the problem is deeper than that: with the following modified code:

class Foo(Base):
  def __init__(self):
    assert 'Foo' in globals()
    assert Foo
    super(Foo,self).__init__()
    if False:
      del Foo

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __init__
    super(Foo,self).__init__()
UnboundLocalError: local variable 'Foo' referenced before assignment



So: Foo IS in globals(), but cannot be accessed through Foo in the class because of the presence of 'del Foo' in the never reached part of the method.

----------
messages: 228757
nosy: Miaou
priority: normal
severity: normal
status: open
title: super() and del in the same method leads to UnboundLocalError
versions: Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Tue Oct  7 19:34:20 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Tue, 07 Oct 2014 17:34:20 +0000
Subject: [New-bugs-announce] [issue22575] bytearray documentation confuses
	string for unicode	objects
Message-ID: <1412703260.19.0.077276076378.issue22575@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The Python 2 version of the bytearray() documentation appears to be copied directly from its Python 3 counterpart and states that when passing in a string an encoding is required:

* If it is a string, you must also give the encoding (and optionally, errors) parameters; bytearray() then converts the string to bytes using str.encode().

(from https://docs.python.org/2/library/functions.html#bytearray).

This obviously doesn't apply to Python 2 str() objects, but would only apply to unicode() objects.

Can this be corrected? The current wording is confusing new users (see http://stackoverflow.com/questions/26230745/how-to-convert-python-str-to-bytearray).

----------
assignee: docs at python
components: Documentation
messages: 228771
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: bytearray documentation confuses string for unicode objects
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct  7 22:34:38 2014
From: report at bugs.python.org (Derek Kurth)
Date: Tue, 07 Oct 2014 20:34:38 +0000
Subject: [New-bugs-announce] [issue22576] ftplib documentation gives a wrong
	argument name for	storbinary
Message-ID: <1412714078.21.0.80330944433.issue22576@psf.upfronthosting.co.za>


New submission from Derek Kurth:

The Python 3 documentation for ftplib gives the storbinary method signature as:

FTP.storbinary(cmd, file, blocksize=8192, callback=None, rest=None)

However, the parameter named "file" is actually named "fp" in the code, so if you do something like this:

ftp.storbinary(cmd="RETR something.txt", file=f)

then you will get a TypeError: storbinary() got an unexpected keyword argument 'file'.  

I think the documentation should be updated to call that argument "fp" instead of "file."

----------
assignee: docs at python
components: Documentation
messages: 228773
nosy: Derek.Kurth, docs at python
priority: normal
severity: normal
status: open
title: ftplib documentation gives a wrong argument name for storbinary
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct  8 12:21:49 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 08 Oct 2014 10:21:49 +0000
Subject: [New-bugs-announce] [issue22577] local variable changes lost after
	pdb jump command
Message-ID: <1412763709.52.0.382735862315.issue22577@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

With the following pdb_jump.py script:

def foo(x):
    import pdb; pdb.set_trace()
    lineno = 3
    lineno = 4

foo(1)


The change made to 'x' is lost after a jump to line 4:

$ ./python ~/tmp/test/pdb_jump.py
> ~/tmp/test/pdb_jump.py(3)foo()
-> lineno = 3
(Pdb) x = 123
(Pdb) jump 4
> ~/tmp/test/pdb_jump.py(4)foo()
-> lineno = 4
(Pdb) x
1
(Pdb)


The problem is that the Bdb format_stack_entry() method refers to frame.f_locals and thus overwrites the changes made to the f_locals dictionary as the f_locals dictionary is updated from the actual frame locals whenever the f_locals accessor is called as stated in a comment of the Pdb setup() method.

----------
components: Library (Lib)
messages: 228783
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: local variable changes lost after pdb jump command
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct  8 14:45:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Oct 2014 12:45:10 +0000
Subject: [New-bugs-announce] [issue22578] Add addition attributes to re.error
Message-ID: <1412772310.32.0.0247834995037.issue22578@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds additional attributes to the re.error exception: msg, pattern, pos, colno, lineno. It also adds helpful information to error message.

Examples:

>>> re.compile(r"abc\u123")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/re.py", line 220, in compile
    return _compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/re.py", line 287, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 465, in compile
    p = sre_parse.parse(p, flags)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 797, in parse
    p = _parse_sub(source, pattern, 0)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 387, in _parse_sub
    itemsappend(_parse(source, state))
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 767, in _parse
    code = _escape(source, this, state)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 378, in _escape
    raise source.error("bogus escape: %s" % repr(escape), len(escape))
sre_constants.error: bogus escape: '\\u123' at position 3
>>> re.compile("""
...     (?x)
...     .++
... """)
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/home/serhiy/py/cpython/Lib/re.py", line 220, in compile
    return _compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/re.py", line 287, in _compile
    p = sre_compile.compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 465, in compile
    p = sre_parse.parse(p, flags)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 797, in parse
    p = _parse_sub(source, pattern, 0)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 387, in _parse_sub
    itemsappend(_parse(source, state))
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 602, in _parse
    source.tell() - here + len(this))
sre_constants.error: multiple repeat at position 16 (line 3, column 7)

See also PEP 473, issue19361 and issue22364.

----------
files: re_error_attrs.patch
keywords: patch
messages: 228787
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add addition attributes to re.error
Added file: http://bugs.python.org/file36834/re_error_attrs.patch

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

From report at bugs.python.org  Wed Oct  8 15:26:55 2014
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Wed, 08 Oct 2014 13:26:55 +0000
Subject: [New-bugs-announce] [issue22579] Posix module init function name
	should not be	compiler-dependent
Message-ID: <1412774815.08.0.905106017715.issue22579@psf.upfronthosting.co.za>


New submission from Jeffrey Armstrong:

The determination of the name of the posix module's initialization function (at Modules/posixmodule.c:12055)  is currently dependent on the compiler being used.  For MSVC, Watcom, or Borland, the name is defined as "PyInit_nt."  However, both Open Watcom and Borland have shipped compilers for GNU/Linux (and other platforms), making determining the posix module initialization function based on compiler incorrect.

Most other places in Modules/posixmodule.c correctly use the "MS_WINDOWS" preprocessor definition to determine if Windows routines should be used.  Naming the intialization function for the posix module should be dependent on this as well rather than compiler identifiers.  

Linking the interpreter natively with Open Watcom fails under GNU/Linux due to "PyInit_posix" being undefined.  This occurs because of the reasons described above.  The patch included corrects the issue.

----------
components: Interpreter Core
files: posix_init.patch
keywords: patch
messages: 228789
nosy: Jeffrey.Armstrong
priority: normal
severity: normal
status: open
title: Posix module init function name should not be compiler-dependent
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file36835/posix_init.patch

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

From report at bugs.python.org  Wed Oct  8 17:11:59 2014
From: report at bugs.python.org (Josh Ayers)
Date: Wed, 08 Oct 2014 15:11:59 +0000
Subject: [New-bugs-announce] [issue22580] PyUnicode_Tailmatch documentation
	does not match	signature
Message-ID: <1412781119.96.0.100711584071.issue22580@psf.upfronthosting.co.za>


New submission from Josh Ayers:

The documentation for PyUnicode_Tailmatch says it returns an int:
https://docs.python.org/3/c-api/unicode.html?highlight=pyunicode_tailmatch#c.PyUnicode_Tailmatch


However, the include file shows it returns Py_ssize_t:
https://hg.python.org/cpython/file/f21f0de30544/Include/unicodeobject.h#l1952

----------
components: Unicode
messages: 228797
nosy: Josh.Ayers, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: PyUnicode_Tailmatch documentation does not match signature
versions: Python 3.3

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

From report at bugs.python.org  Wed Oct  8 18:18:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Oct 2014 16:18:20 +0000
Subject: [New-bugs-announce] [issue22581] Other mentions of the buffer
	protocol
Message-ID: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In addition to issue16518. There are other non-fixed messages (may be introduced after 3.3):

>>> b''.join([''])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sequence item 0: expected bytes, bytearray, or an object with the buffer interface, str found
>>> str(42, 'utf8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercing to str: need bytes, bytearray or buffer-like object, int found
>>> import array; array.array('B').frombytes(array.array('I'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string/buffer of bytes required.
>>> import socket; print(socket.socket.sendmsg.__doc__)
sendmsg(buffers[, ancdata[, flags[, address]]]) -> count

Send normal and ancillary data to the socket, gathering the
non-ancillary data from a series of buffers and concatenating it into
a single message.  The buffers argument specifies the non-ancillary
data as an iterable of buffer-compatible objects (e.g. bytes objects).
The ancdata argument specifies the ancillary data (control messages)
as an iterable of zero or more tuples (cmsg_level, cmsg_type,
cmsg_data), where cmsg_level and cmsg_type are integers specifying the
protocol level and protocol-specific type respectively, and cmsg_data
is a buffer-compatible object holding the associated data.  The flags
argument defaults to 0 and has the same meaning as for send().  If
address is supplied and not None, it sets a destination address for
the message.  The return value is the number of bytes of non-ancillary
data sent.

And there are several mentions of "buffer-like" or "buffer-compatible" in the documentation.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 228799
nosy: chris.jerdonek, docs at python, eric.araujo, ezio.melotti, flox, georg.brandl, pitrou, python-dev, r.david.murray, rhettinger, serhiy.storchaka, skrah, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Other mentions of the buffer protocol

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

From report at bugs.python.org  Wed Oct  8 20:27:49 2014
From: report at bugs.python.org (Kevin Dyer)
Date: Wed, 08 Oct 2014 18:27:49 +0000
Subject: [New-bugs-announce] [issue22582] Segmentation fault with string
	concatenation
Message-ID: <1412792869.08.0.101589762303.issue22582@psf.upfronthosting.co.za>


New submission from Kevin Dyer:

The following can be used to generate a file called ```mega_concat.py```:
```python
N = 2**17
my_array = []
for i in range(N):
  my_array.append("\"\"")
print '+'.join(my_array)
```

Then:

```console
$ python mega_concat.py 
Segmentation fault (core dumped)
$ python3 mega_concat.py 
RuntimeError: maximum recursion depth exceeded during compilation
```

Trying to debug this and it seems like it's a simple out-of-memory issue.

----------
components: Interpreter Core
messages: 228807
nosy: Kevin.Dyer
priority: normal
severity: normal
status: open
title: Segmentation fault with string concatenation
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct  8 20:33:29 2014
From: report at bugs.python.org (Kevin Dyer)
Date: Wed, 08 Oct 2014 18:33:29 +0000
Subject: [New-bugs-announce] [issue22583] Segmentation fault with string
	concatenation
Message-ID: <1412793209.1.0.692810866448.issue22583@psf.upfronthosting.co.za>


New submission from Kevin Dyer:

The following can be used to generate a file called mega_concat.py:

N = 2**17
my_array = []
for i in range(N):
  my_array.append("\"\"")
print '+'.join(my_array)

Then, on Ubuntu 14.04, 32-bit:

$ python mega_concat.py 
Segmentation fault (core dumped)
$ python3 mega_concat.py 
RuntimeError: maximum recursion depth exceeded during compilation

Seems like this is a simple out-of-memory issue.

----------
components: Interpreter Core
messages: 228809
nosy: Kevin.Dyer
priority: normal
severity: normal
status: open
title: Segmentation fault with string concatenation
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  9 09:43:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Oct 2014 07:43:50 +0000
Subject: [New-bugs-announce] [issue22584] Get rid of SRE character tables
Message-ID: <1412840630.55.0.708723540507.issue22584@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently the SRE regular expression engine uses internal tables to implement ASCII-only character predicates and converting. Proposed patch get rid of these tables and reuse standard Python macros Py_ISSPACE, Py_TOLOWER, etc.

----------
components: Extension Modules, Regular Expressions
files: sre_tables.patch
keywords: patch
messages: 228836
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Get rid of SRE character tables
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36841/sre_tables.patch

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

From report at bugs.python.org  Thu Oct  9 11:26:08 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Oct 2014 09:26:08 +0000
Subject: [New-bugs-announce] [issue22585] os.urandom() should use
	getentropy() of OpenBSD 5.6
Message-ID: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The future OpenBSD 5.6 (scheduled in november 2014) will have a new getentropy() syscall and a new getentropy() in their C library which avoid the need of a file descriptor:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2?query=getentropy&sec=2

Note: "The maximum buffer size permitted is 256 bytes. If buflen exceeds this, an error of EIO will be indicated."

The file descriptor of os.urandom() causes perfomance issues and surprising bugs: #18756, #21207.

For Python 2.7, see also the PEP 466 and the issue #21305.

See also issues:

- #22181: os.urandom() should use Linux 3.17 getrandom() syscall
- #22542: Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

----------
messages: 228846
nosy: haypo
priority: normal
severity: normal
status: open
title: os.urandom() should use getentropy() of OpenBSD 5.6
type: security
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct  9 18:00:33 2014
From: report at bugs.python.org (Alex Parrill)
Date: Thu, 09 Oct 2014 16:00:33 +0000
Subject: [New-bugs-announce] [issue22586] urljoin allow_fragments doesn't
	work
Message-ID: <1412870433.46.0.862767853703.issue22586@psf.upfronthosting.co.za>


New submission from Alex Parrill:

Passing False to the allow_fragments argument to urljoin doesn't remove fragments.

Is this a bug, or am I misunderstanding the allow_fragments parameter? It's not perfectly clear what "fragment identifiers are not allowed" means (strips them out? throws an error?)

I'm running this on XUbuntu 14.04.01.

$ python3
Python 3.4.0 (default, Apr 11 2014, 13:05:11) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib.parse import urljoin
>>> urljoin("http://localhost:8000/foo.html", "bar.html#baz", allow_fragments=False)
'http://localhost:8000/bar.html#baz'

----------
components: Library (Lib)
messages: 228877
nosy: ColonelThirtyTwo
priority: normal
severity: normal
status: open
title: urljoin allow_fragments doesn't work
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct  9 18:56:13 2014
From: report at bugs.python.org (Kevin Keating)
Date: Thu, 09 Oct 2014 16:56:13 +0000
Subject: [New-bugs-announce] [issue22587] os.path.abspath(None) behavior is
	inconsistent between	platforms
Message-ID: <1412873773.97.0.374832942416.issue22587@psf.upfronthosting.co.za>


New submission from Kevin Keating:

On Windows, os.path.abspath() treats None as if it were an empty string, so os.path.abspath(None) returns the current working directory.  On Linux, os.path.abspath(None) raises an AttributeError.  With macpath, abspath(None) raises a TypeError.  I've seen this behavior with Python 2.7.3, 2.7.8, 3.2.5, and 3.4.2.

Python 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ntpath, posixpath, macpath
>>> ntpath.abspath(None)
'C:\\Users\\Keating\\Documents'
>>> posixpath.abspath(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\programs\Python34\lib\posixpath.py", line 357, in abspath
    if not isabs(path):
  File "C:\programs\Python34\lib\posixpath.py", line 63, in isabs
    return s.startswith(sep)
AttributeError: 'NoneType' object has no attribute 'startswith'
>>> macpath.abspath(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\programs\Python34\lib\macpath.py", line 177, in abspath
    if not isabs(path):
  File "C:\programs\Python34\lib\macpath.py", line 49, in isabs
    return colon in s and s[:1] != colon
TypeError: argument of type 'NoneType' is not iterable

This case seems very closely related to http://bugs.python.org/issue9018, which noted a platform inconsistency in os.path.normcase.

----------
components: Library (Lib)
messages: 228883
nosy: KevKeating
priority: normal
severity: normal
status: open
title: os.path.abspath(None) behavior is inconsistent between platforms
versions: Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Thu Oct  9 20:10:59 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 09 Oct 2014 18:10:59 +0000
Subject: [New-bugs-announce] [issue22588] memory corrupted in test_capi
	refleaks test
Message-ID: <1412878259.75.0.451525975986.issue22588@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

This does not happen on tests run with '-R 22:22' or a lower run count, but occur systematically with '-R 23:23' or a greater run count.

$ ./python
Python 3.5.0a0 (default:1e1c6e306eb4, Oct  9 2014, 19:52:59)
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform; platform.uname()
uname_result(system='Linux', node='bilboquet', release='3.16.3-1-ARCH', version='#1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014', machine='x86_64', processor='')
>>> 

$ ./python -m test -R 23:23 test_capi
[1/1] test_capi
beginning 46 repetitions
1234567890123456789012345678901234567890123456
..............................................
1 test OK.
Debug memory block at address p=0x982570: API ''
    18446744073709551615 bytes originally requested
    The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb):
        at p-7: 0x00 *** OUCH
        at p-6: 0x00 *** OUCH
        at p-5: 0x00 *** OUCH
        at p-4: 0x00 *** OUCH
        at p-3: 0x00 *** OUCH
        at p-2: 0x00 *** OUCH
        at p-1: 0x00 *** OUCH
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 8 pad bytes at tail=0x98256f are not all FORBIDDENBYTE (0xfb):
        at tail+0: 0x00 *** OUCH
        at tail+1: 0x00 *** OUCH
        at tail+2: 0x00 *** OUCH
        at tail+3: 0x00 *** OUCH
        at tail+4: 0x00 *** OUCH
        at tail+5: 0x00 *** OUCH
        at tail+6: 0x00 *** OUCH
        at tail+7: 0x00 *** OUCH
    The block was made by call #0 to debug malloc/realloc.
    Data at p:
Fatal Python error: bad ID: Allocated using API '', verified using API 'o'

Current thread 0x00007f525bcf2700 (most recent call first):
Aborted (core dumped)

----------
components: Library (Lib)
messages: 228886
nosy: xdegaye
priority: normal
severity: normal
status: open
title: memory corrupted in test_capi refleaks test
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct  9 21:00:16 2014
From: report at bugs.python.org (Brian Matthews)
Date: Thu, 09 Oct 2014 19:00:16 +0000
Subject: [New-bugs-announce] [issue22589] mimetypes uses image/x-ms-bmp as
	the type for bmp files
Message-ID: <1412881216.57.0.175210358842.issue22589@psf.upfronthosting.co.za>


New submission from Brian Matthews:

In the file mimetypes.py the mime type for bmp files should be image/bmp for IE8 and later. the problem is that if the content header for 'nosniff' is set, then the bmp file fails to display due to the incorrect mime type.

----------
components: IO
messages: 228892
nosy: brma
priority: normal
severity: normal
status: open
title: mimetypes uses image/x-ms-bmp as the type for bmp files
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  9 21:19:23 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 09 Oct 2014 19:19:23 +0000
Subject: [New-bugs-announce] [issue22590] math.copysign buggy with nan under
	Windows
Message-ID: <1412882363.43.0.416785697629.issue22590@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Z:\>c:\Python27\python.exe
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 math
>>> math.copysign(0.0, float("nan"))
-0.0
>>> ^Z

Z:\>c:\Python34\python.exe
Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:24:06) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.copysign(0.0, float("nan"))
0.0
>>> ^Z

----------
components: Library (Lib), Windows
messages: 228894
nosy: mark.dickinson, pitrou, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: math.copysign buggy with nan under Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Oct  9 23:15:43 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Oct 2014 21:15:43 +0000
Subject: [New-bugs-announce] [issue22591] Drop support of MS-DOS
Message-ID: <1412889343.74.0.168731015987.issue22591@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In the C code of Python 3.5, there are still preprocessor commands checking for defines:

- __BORLANDC__: Borland C compiler
- __WATCOMC__: Watcom C compiler
- __DJGPP__: MS-DOS port of GCC

In 2014, it's time to drop this old code. OS/2 support was already removed in Python 3.4 (see the PEP 11).

I'm quite sure that Python 3.5 cannot be compiled on MS-DOS and/or will not work on MS-DOS. I don't think that anyone tried Python 3 on MS-DOS. The MS-DOS support was simply inherited from Python 2, Python 3 source code is based on Python 2.

I don't want to drop support of custom compilers, only removing code specific to MS-DOS, see:
http://bugs.python.org/issue22579#msg228908

----------
messages: 228913
nosy: haypo
priority: normal
severity: normal
status: open
title: Drop support of MS-DOS
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 10 00:00:53 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Oct 2014 22:00:53 +0000
Subject: [New-bugs-announce] [issue22592] Drop support of Borland C compiler
Message-ID: <1412892053.1.0.924294706451.issue22592@psf.upfronthosting.co.za>


New submission from STINNER Victor:

As a follow-up of the issue #22591, I propose to drop support of the Borland C compiler.

In 2000, it was nice to support Visual Studio and Borland C++ Builder, because they were the two most popular compilers on Windows. Borland C compiler could also be used on MS-DOS.

But Borland stopped the development of its C compiler, it looks like the last release is Borland C++ Builder, which was released in 2000 (I'm not sure). So this proprietary compiler is now 14 years old.

Python now focus on Visual Studio support. Microsoft gives us free licenses and a developer of Microsoft will probably build our binaries for Python 3.5. So Borland C++ Builder support is now almost useless.

On Windows, I would prefer to focus our effort on open source compilers like GCC or OpenWatcom(v2). See for example the issue #22579.

----------
messages: 228923
nosy: haypo
priority: normal
severity: normal
status: open
title: Drop support of Borland C compiler
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 10 03:11:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 10 Oct 2014 01:11:38 +0000
Subject: [New-bugs-announce] [issue22593] Automate update of doc references
	to UCD version when it	changes.
Message-ID: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>


New submission from R. David Murray:

As noted by Alexander in issue 18176, we often forget to update the UCD references in the docs when we switch to a new version.  That issue added notes to the makeunicodedata script to list the places that need to be changed; however, it would be even better if makeunicodedata could somehow do the update automatically.

One possible way to do this easily might be to leverage sphinx 'substitutions' (I couldn't make that work in a short experiment, so it might not be feasible).  If not, it should be simple enough to write something to automate the editing of the lines in the rst files (probably using a hardcoded list of locations, but possibly by grepping for the URL pattern).

Alexander also discussed the possibility of auto-generating tables to insert into the documentation, in the context of the PropList.txt file.  I don't know if this is practical or desirable.

----------
keywords: easy
messages: 228935
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Automate update of doc references to UCD version when it changes.
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 10 09:48:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Oct 2014 07:48:05 +0000
Subject: [New-bugs-announce] [issue22594] Add a link to the regex module in
	re documentation
Message-ID: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The regex module is purposed as a replacement of standard re module. Of course we fix re bugs, but for now regex is more bugfree. Even after fixing all open re bugs, regex will remain more featured. It would be good to add a link to regex in re documentation (as there are links to other GUI libraries in Tkinter documentation).

----------
assignee: docs at python
components: Documentation, Regular Expressions
keywords: easy
messages: 228961
nosy: docs at python, ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add a link to the regex module in re documentation
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct 10 09:57:02 2014
From: report at bugs.python.org (Mc128k)
Date: Fri, 10 Oct 2014 07:57:02 +0000
Subject: [New-bugs-announce] [issue22595] F5 shortcut key not working in
	IDLE for OSX
Message-ID: <1412927822.17.0.886129878448.issue22595@psf.upfronthosting.co.za>


New submission from Mc128k:

Hi
I am using the latest version of python and IDLE, and when I edit a file and I press the key F5 it runs fine in the other window, while if I do it inside the IDLE command line it just prints the character ? (which cannot be seen in the browser here). Using the menu to run works fine.

----------
components: IDLE
files: Screenshot 2014-10-10 09.56.46.png
messages: 228962
nosy: mc128k
priority: normal
severity: normal
status: open
title: F5 shortcut key not working in IDLE for OSX
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file36859/Screenshot 2014-10-10 09.56.46.png

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

From report at bugs.python.org  Fri Oct 10 12:02:10 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 10 Oct 2014 10:02:10 +0000
Subject: [New-bugs-announce] [issue22596] support.transient_internet()
	doesn't catch connection	refused errors
Message-ID: <1412935330.96.0.286342461477.issue22596@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This issue is similar to issue 22289.

======================================================================
ERROR: test_ftp (test.test_urllib2net.OtherNetworkTests) (url='ftp://ftp.debian.org/debian/README')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1399, in ftp_open
    fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1445, in connect_ftp
    dirs, timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2243, in __init__
    self.init()
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2249, in init
    self.ftp.connect(self.host, self.port, self.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/ftplib.py", line 153, in connect
    source_address=self.source_address)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 655, in create_connection
    raise err
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 646, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 226, in _test_urls
    f = urlopen(url, req, TIMEOUT)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 33, in wrapped
    return _retry_thrice(func, exc, *args, **kwargs)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 29, in _retry_thrice
    raise last_exc
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice
    return func(*args, **kwargs)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 463, in open
    response = self._open(req, data)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 481, in _open
    '_open', req)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 441, in _call_chain
    result = func(*args)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1417, in ftp_open
    raise exc.with_traceback(sys.exc_info()[2])
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1399, in ftp_open
    fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 1445, in connect_ftp
    dirs, timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2243, in __init__
    self.init()
  File "/opt/python/3.x.langa-ubuntu/build/Lib/urllib/request.py", line 2249, in init
    self.ftp.connect(self.host, self.port, self.timeout)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/ftplib.py", line 153, in connect
    source_address=self.source_address)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 655, in create_connection
    raise err
  File "/opt/python/3.x.langa-ubuntu/build/Lib/socket.py", line 646, in create_connection
    sock.connect(sa)
urllib.error.URLError: <urlopen error ftp error: ConnectionRefusedError(111, 'Connection refused')>

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/5026/steps/test/logs/stdio

----------
components: Tests
files: connection-refused.diff
keywords: patch
messages: 228977
nosy: berker.peksag, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: support.transient_internet() doesn't catch connection refused errors
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36862/connection-refused.diff

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

From report at bugs.python.org  Fri Oct 10 12:09:21 2014
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 10 Oct 2014 10:09:21 +0000
Subject: [New-bugs-announce] [issue22597] printf-style formatting allows
	mixing keyed and keyless	specifiers
Message-ID: <1412935761.9.0.479388306939.issue22597@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

>>> '%(eggs)s %s' % {'eggs': 'ham'}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not enough arguments for format string

>>> '%s %(eggs)s' % {'eggs': 'ham'}
"{'eggs': 'ham'} ham"

I would expect a raised exception also in the latter case.

----------
components: Library (Lib)
messages: 228978
nosy: jwilk
priority: normal
severity: normal
status: open
title: printf-style formatting allows mixing keyed and keyless specifiers
type: behavior

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

From report at bugs.python.org  Fri Oct 10 12:24:17 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 10 Oct 2014 10:24:17 +0000
Subject: [New-bugs-announce] [issue22598] IMAP4 UTF-7 support
Message-ID: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Looks like there is consensus to add "mUTF-7" or "imap4 UTF-7" to the codec module for Python 3.5. Details in https://mail.python.org/pipermail/python- dev/2014-October/136601.html

----------
assignee: jcea
messages: 228979
nosy: jcea
priority: normal
severity: normal
status: open
title: IMAP4 UTF-7 support
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 10 13:36:01 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Oct 2014 11:36:01 +0000
Subject: [New-bugs-announce] [issue22599] traceback: errors in the linecache
	module at exit
Message-ID: <1412940961.34.0.0781587147709.issue22599@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached destructortest.py script comes the issue #22480. It calls traceback.print_exception() at exit. The problem is that the call occurs late during Python finalization. The object was stored in the namespace of the main module. Currently, Python deletes builtin functions and then deletes modules (in a random order?).

Since the traceback module is used to display errors, it's annoying to get errors in the traceback module :-) I see two options to fix the specific issue of destructortest.py:

* Ignore exceptions while calling linecache
* Detect Python finalization and don't try to use the linecache module in this case

Attached patch implements the second option. I'm not sure that it's the best one. It includes an unit test.

Depending on the option, we can fix the issue only in Python 3.5, or fix Python 2.7, 3.4 and 3.5.

Current output:
---
Traceback (most recent call last):
Exception ignored in: <bound method PrintExceptionAtExit.__del__ of <__main__.PrintExceptionAtExit object at 0x7f70b84ac878>>
Traceback (most recent call last):
  File "destructortest.py", line 15, in __del__
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 169, in print_exception
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 153, in _format_exception_iter
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 18, in _format_list_iter
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 15, in getline
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 41, in getlines
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 126, in updatecache
  File "/home/haypo/prog/python/default/Lib/tokenize.py", line 438, in open
AttributeError: module 'builtins' has no attribute 'open'
---

Expected output:
---
Traceback (most recent call last):
  File "destructortest.py", line 7, in __init__
ZeroDivisionError: division by zero
---

----------
components: Library (Lib)
files: destructortest.py
messages: 228986
nosy: haypo
priority: normal
severity: normal
status: open
title: traceback: errors in the linecache module at exit
versions: Python 3.5
Added file: http://bugs.python.org/file36863/destructortest.py

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

From report at bugs.python.org  Fri Oct 10 13:53:13 2014
From: report at bugs.python.org (CALMET)
Date: Fri, 10 Oct 2014 11:53:13 +0000
Subject: [New-bugs-announce] [issue22600] In Multiprocessing Queue() doesn't
	work with list :	__.put(list) != __.get()
Message-ID: <1412941993.11.0.215678273609.issue22600@psf.upfronthosting.co.za>


New submission from CALMET:

Hello,
I have to find the right order of a list, for example
try = [0,1,2,3,4,5,6,7,8,9]
try = [0,1,2,3,4,5,6,7,9,8]
try = [0,1,2,3,4,5,6,8,7,9]
and so on... in this example there are factorial(10) = 3,6 million possible order to test.
The results with be all the list  'try'  that match with the test.

To go faster
- I use mutiproceesiing
- I define   rightorder = Queue() 
- I define a function test   with a line  rightorder.put(try)
- I wait for all the processes are finished  p.join()
- Then I read all the results in the main programm   rightorder.get()

The problem is that on exactly the same example
- the rightorder.put() found by the process are always good
- but the rightorder.get() in the main programm can be different (randomly).

I first believed that when 2 processes call the function  rightorder.put(try)  at the same time, the lists ares mixed together in the Queue().

But even when I force cpu_count() to 1 (mono process) I still have the problem.

To solve the problem I converted the list try=[2,3,0,4,2,9,7,8,1,5]
in a string try2="2304297815"
and since now  rightorder.put(try)  and  rightorder.get()  always give the same results.

So I suppose that in multiprocessing with a Queue() rightorder.put(try)  works if try is a number or a string
but doesn't works if try is a list.

----------
files: BisesAmouRmulti-debug.py
messages: 228993
nosy: AlainCALMET
priority: normal
severity: normal
status: open
title: In Multiprocessing Queue() doesn't work with list : __.put(list) != __.get()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file36865/BisesAmouRmulti-debug.py

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

From report at bugs.python.org  Fri Oct 10 14:07:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Oct 2014 12:07:33 +0000
Subject: [New-bugs-announce] [issue22601] asyncio: loop.run_forever() should
	consume exception of	the temporary task
Message-ID: <1412942853.71.0.75284740546.issue22601@psf.upfronthosting.co.za>


New submission from STINNER Victor:

BaseEventLoop.run_forever() creates a temporary task when it gets a coroutine object. If the coroutine raises a base exception, it is stored in the temporary task (task.set_exception(exc)). run_forever() doesn't catch the exception, which is the expected behaviour.

The problem is that the temporary task still holds the exception, whereas the caller doesn't have access to this temporary task object. As a result, a warning is logger.

I propose to simply drop the exception from the task object (consume it). The call will get it anyway, it's not catched.

Attached patch implements this idea with a unit test.

----------
components: asyncio
files: run_forever.patch
keywords: patch
messages: 228994
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: loop.run_forever() should consume exception of the temporary task
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36866/run_forever.patch

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

From report at bugs.python.org  Fri Oct 10 14:44:43 2014
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 10 Oct 2014 12:44:43 +0000
Subject: [New-bugs-announce] [issue22602] UTF-7 codec decodes ill-formed
	sequences starting with	"+"
Message-ID: <1412945083.94.0.341902119278.issue22602@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

RFC 2152 reads:

  A "+" character followed immediately by any character other than
  members of set B or "-" is an ill-formed sequence.

"@" is not a member of B, so I would expect this to raise UnicodeDecodeError:

>>> b'+@'.decode('UTF-7')
'@'

----------
components: Library (Lib)
messages: 228996
nosy: jwilk
priority: normal
severity: normal
status: open
title: UTF-7 codec decodes ill-formed sequences starting with "+"
type: behavior

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

From report at bugs.python.org  Fri Oct 10 16:20:55 2014
From: report at bugs.python.org (=?utf-8?q?Francisco_Fern=C3=A1ndez_Casta=C3=B1o?=)
Date: Fri, 10 Oct 2014 14:20:55 +0000
Subject: [New-bugs-announce] [issue22603] Fix a typo in the contextlib docs
Message-ID: <1412950855.37.0.697609134038.issue22603@psf.upfronthosting.co.za>


New submission from Francisco Fern?ndez Casta?o:

>From the code example at https://docs.python.org/3/library/contextlib.html#contextlib.ContextDecorator

"logging.info('Entering: {}'.format(name))
NameError: name 'name' is not defined"

name is referenced instead of self.name

----------
assignee: docs at python
components: Documentation
files: doctypo.patch
keywords: patch
messages: 229000
nosy: Francisco.Fern?ndez.Casta?o, docs at python
priority: normal
severity: normal
status: open
title: Fix a typo in the contextlib docs
type: crash
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36867/doctypo.patch

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

From report at bugs.python.org  Fri Oct 10 17:35:13 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Oct 2014 15:35:13 +0000
Subject: [New-bugs-announce] [issue22604] assertion error in complex division
Message-ID: <1412955313.16.0.545983222946.issue22604@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This only happens in debug mode:

>>> complex(0.0, 0.0) / complex(float('nan'), 0.0)
python: Objects/complexobject.c:98: _Py_c_quot: Assertion `b.imag != 0.0' failed.

In release mode, this gives:

>>> complex(0.0, 0.0) / complex(float('nan'), 0.0)
(nan+nanj)

(is it the right result?)

----------
components: Interpreter Core
messages: 229011
nosy: eric.smith, lemburg, mark.dickinson, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: assertion error in complex division
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct 10 21:15:10 2014
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 10 Oct 2014 19:15:10 +0000
Subject: [New-bugs-announce] [issue22605] memcpy(NULL, NULL, 0) in
Message-ID: <1412968510.44.0.374050291089.issue22605@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
components: Library (Lib)
nosy: jwilk
priority: normal
severity: normal
status: open
title: memcpy(NULL, NULL, 0) in
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 10 22:48:45 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Fri, 10 Oct 2014 20:48:45 +0000
Subject: [New-bugs-announce] [issue22606] Inconsistency between Python 2 and
	PyPy regarding future	imports
Message-ID: <1412974125.28.0.470692866106.issue22606@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi,

The following code gives similar errors for both PyPy and Python 2 when called, but totally different AST objects.

Given the following code, PyPy says that `print(4)` is an _ast.Print, while Python 2 believes that it is an _ast.Expr (which wraps a Call). This behaviour is wrong, Python 2 shouldn't extrapolate further if the __future__ is misplaced.


   from ast import parse

   bad = """
   a = 1
   from __future__ import print_function
   print(4)
   """

   x = parse(bad)
   print(x.body[2])

Brett, I added you on this as nosy, since I discovered this bug while debugging your print-statement pull request, so I thought you should know. :-)

----------
messages: 229037
nosy: Claudiu.Popa, brett.cannon
priority: normal
severity: normal
status: open
title: Inconsistency between Python 2 and PyPy regarding future imports
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 11 10:31:29 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 11 Oct 2014 08:31:29 +0000
Subject: [New-bugs-announce] [issue22607] find by dichotomy the failing test
Message-ID: <1413016289.65.0.402088984068.issue22607@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

This issue stems from issue 22588.

See message 228968 for the rationale:
Automatize the dichotomy process used to to identify memory leaks, crash, reference leak, resource leak, etc. in a failing test.

----------
components: Tests
messages: 229067
nosy: haypo, xdegaye
priority: normal
severity: normal
status: open
title: find by dichotomy the failing test
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Oct 11 13:23:01 2014
From: report at bugs.python.org (Urs Traber)
Date: Sat, 11 Oct 2014 11:23:01 +0000
Subject: [New-bugs-announce] [issue22608] test_socket fails with sem_init:
	Too many open files
Message-ID: <1413026581.56.0.334221063135.issue22608@psf.upfronthosting.co.za>


New submission from Urs Traber:

test_socke.py does not clean up its event objects used for synchronization. This may cause multiple such ERRORs (*):

testLinebufferedWrite (__main__.LineBufferedFileObjectClassTestCase) ... sem_init: Too many open files
ERROR

Fixed by setting the allocated Event objects to None at the end of a test (see patch attached).



*) e.g. on Digital UNIX with a default of maximal 4096 open files per process

----------
components: Tests
files: test_socket.patch
keywords: patch
messages: 229075
nosy: Urs.Traber
priority: normal
severity: normal
status: open
title: test_socket fails with sem_init: Too many open files
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file36878/test_socket.patch

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

From report at bugs.python.org  Sat Oct 11 14:04:09 2014
From: report at bugs.python.org (Evgeny Kapun)
Date: Sat, 11 Oct 2014 12:04:09 +0000
Subject: [New-bugs-announce] [issue22609] Constructors of some mapping
	classes don't accept `self`	keyword argument
Message-ID: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

>>> import collections
>>> collections.Counter(self=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got multiple values for argument 'self'
>>> collections.OrderedDict(self="test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got multiple values for argument 'self'
>>> collections.UserDict(self="test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got multiple values for argument 'self'

Python surely should have positional-only parameters.

----------
components: Library (Lib)
messages: 229076
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: Constructors of some mapping classes don't accept `self` keyword argument
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Oct 11 14:18:28 2014
From: report at bugs.python.org (Urs Traber)
Date: Sat, 11 Oct 2014 12:18:28 +0000
Subject: [New-bugs-announce] [issue22610] test_ftplib fails with sem_init:
	Too many open files
Message-ID: <1413029908.66.0.757580851096.issue22610@psf.upfronthosting.co.za>


New submission from Urs Traber:

same issue as http://bugs.python.org/issue22608

e.g.

test_sanitize (__main__.TestTLS_FTPClassMixin) ... sem_init: Too many open files
ERROR

Fixed by setting the allocated Event objects to None when not needed anymore.

----------
components: Tests
files: test_ftplib.patch
keywords: patch
messages: 229077
nosy: Urs.Traber
priority: normal
severity: normal
status: open
title: test_ftplib fails with sem_init: Too many open files
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file36879/test_ftplib.patch

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

From report at bugs.python.org  Sat Oct 11 18:33:59 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Oct 2014 16:33:59 +0000
Subject: [New-bugs-announce] [issue22611] pip needs ctypes
Message-ID: <1413045239.87.0.575221009186.issue22611@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I think a bit weird that pip needs ctypes inconditionally. Note the following traceback is on an Unix platform and ctypes seems imported by a... win32 shell coloring library!

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_venv.py", line 356, in test_with_pip
    with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmppsirrkh8/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_venv.py", line 362, in test_with_pip
    self.fail(msg.format(exc, details))
AssertionError: Command '['/tmp/tmppsirrkh8/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 209, in _main
    default_pip=args.default_pip,
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 116, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 40, in _run_pip
    import pip
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/__init__.py", line 9, in <module>
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/log.py", line 9, in <module>
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/__init__.py", line 2, in <module>
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/initialise.py", line 5, in <module>
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/ansitowin32.py", line 6, in <module>
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/winterm.py", line 2, in <module>
  File "/tmp/tmpvhf7jjwp/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/win32.py", line 7, in <module>
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'


(from http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/8753/steps/test/logs/stdio)

----------
components: Demos and Tools, Library (Lib)
messages: 229093
nosy: Marcus.Smith, dstufft, ncoghlan, pitrou, pmoore
priority: normal
severity: normal
status: open
title: pip needs ctypes
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Oct 11 19:58:45 2014
From: report at bugs.python.org (flying sheep)
Date: Sat, 11 Oct 2014 17:58:45 +0000
Subject: [New-bugs-announce] [issue22612] Add block info to unicodedata
Message-ID: <1413050325.25.0.295627364762.issue22612@psf.upfronthosting.co.za>


New submission from flying sheep:

See also #6331.

The repo https://github.com/nagisa/unicodeblocks contains pretty much the functionality i?d like to see: a way to get access to information about all blocks, and a way to get the block name a char is in.

I propose to include something very similar to those two APIs in unicodedata:

unicodedata.Block: class with start, end, and name property.

its __contains__ should work for single-char-strings (which tests if that char is in the block) and for ints (which tests if the codepoint is in the block)

maybe make it iterable over its chars?

unicodedata.blocks: OrderedDict of str (block name) ? Block object mappings ordered by Block.start.

then blocks.keys() would yield the names in order, and blocks.values() the block objects in order.

unicodedata.block_of(chr, name_only=False): returns the Block object for which ?chr in block? is True, or its name.

---

alternative: make the Block class an unfancy namedtuple without __contains__ method.

---

Together with #18234, fixing this bug will complete UnicodeData support in python, i guess.

----------
messages: 229101
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Add block info to unicodedata
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 12 00:17:23 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 11 Oct 2014 22:17:23 +0000
Subject: [New-bugs-announce] [issue22613] Several minor doc issues
Message-ID: <1413065843.62.0.682552430945.issue22613@psf.upfronthosting.co.za>


New submission from Zachary Ware:

>From docs@:

"""
Hello,

First, I want to thank you for the useful and clear documentation of Python.

Beeing a fanatic reader of it, sometimes I encounter some mistake (or it seems to me it is such). If this could bring some help, you will find in the attached file a list of points requiring attention.

All the comments concern the official standard documentation of Python 3.4.0.

With regards.

Jacques Ducasse
"""

----------
assignee: docs at python
components: Documentation
files: PythonDocErreurs141010.pdf
keywords: easy
messages: 229104
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Several minor doc issues
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36883/PythonDocErreurs141010.pdf

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

From report at bugs.python.org  Sun Oct 12 00:18:00 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Oct 2014 22:18:00 +0000
Subject: [New-bugs-announce] [issue22614] Idle: problem
	in	PyShellEditorWindow.color_breakpoint_text
Message-ID: <1413065880.69.0.0818621344041.issue22614@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In Jan 2014 in the opening messages of #20167, msg207599, Serhiy Storchaka reported that
./python -m idlelib.idle Lib/decimal.py
opened the file on both 2.7 and 3.4 (beta) but that closing on 3.4 (but not 2.7) caused 'application closed' errors in Multicall .__del__ methods. These have been fixed and recently refixed.

In msg228954, Serhiy reported a new problem, which I an transferring to this new issue, with 2.7 and 3.4 but not 3.5.

./python -m idlelib.idle Lib/decimal.py
Traceback (most recent call last):
  File "/home/serhiy/py/cpython-3.4/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/serhiy/py/cpython-3.4/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/PyShell.py", line 1562, in main
    if flist.open(filename) is None:
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/FileList.py", line 36, in open
    edit = self.EditorWindow(self, filename, key)
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/PyShell.py", line 141, in __init__
    self.color_breakpoint_text()
  File "/home/serhiy/py/cpython-3.4/Lib/idlelib/PyShell.py", line 159, in color_breakpoint_text
    self.text.tag_config('BREAK', cfg)
AttributeError: 'NoneType' object has no attribute 'tag_config'

Serhiy, you did not specify the particular binaries you used. I will assume recent.

Versions: as far as I know, there are no idlelib code differences between 3.4 and default (3.5).  I rechecked closed issues for patches pushed by someone else only to 3.5.  So any behavior difference between 3.4 and 3.5 must by due to a difference in tkinter, another stdlib module, or python itself.

What system? I do not reproduce on Win 7 with an Oct 9 build.

When?  If the command line worked for 2.7 in Jan and fails now, when did it start failing?  If the command worked for 3.4 after the Feb patches and fails now, same question.

How? You did not state, but in a later message implied that the file opened in the editor and the problem only happened when you closed, as with the January report.  However, the traceback says that the problem occurred during initialization.  According to Find in Files, the only call to color_breakpoint_text is that one __init__ call.  I therefore do not understand your msg228957 comment "The code runs up to self.text.update() in restore_file_breaks() and runs further only after windows closing."

restore_file_breaks is only called in two places. One is when file names are changed (which should not happen when closing an untouched file), the other is just before color_break during initialization.  Here is the last part of PyShellEditorWindow.__init__.

        def filename_changed_hook(old_hook=self.io.filename_change_hook,
                                  self=self):
            self.restore_file_breaks()
            old_hook()
        self.io.set_filename_change_hook(filename_changed_hook)
        if self.io.filename:
            self.restore_file_breaks()
        self.color_breakpoint_text()

You msg228958 comment that changing .update to .update_idletasks also puzzles me. According to the tkinter docstrings, the difference is that the latter does less (assuming that .update also clears non-user callbacks, whatever they are)

update(self)
    Enter event loop until all pending events have been processed by Tcl.

update_idletasks(self)
    Enter event loop until all idle callbacks have been called. This
    will update the display of windows but not process events caused by
    the user.

During initialization, I would not expect there to be any user events.

----------
messages: 229105
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: problem in PyShellEditorWindow.color_breakpoint_text
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Oct 12 00:31:33 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 11 Oct 2014 22:31:33 +0000
Subject: [New-bugs-announce] [issue22615] "make clinic" doesn't work
Message-ID: <1413066693.48.0.0538322040876.issue22615@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is on the default branch.

$ make clinic
./python -E ./Tools/clinic/clinic.py --make
Error in file "./Modules/arraymodule.c" on line 1943:
Exception raised during parsing:
Traceback (most recent call last):
  File "./Tools/clinic/clinic.py", line 1626, in parse
    parser.parse(block)
  File "./Tools/clinic/clinic.py", line 3178, in parse
    self.state(line)
  File "./Tools/clinic/clinic.py", line 3660, in state_parameter
    converter = dict[name](c_name or parameter_name, parameter_name, self.function, value, **kwargs)
  File "./Tools/clinic/clinic.py", line 2200, in __init__
    self.converter_init(**kwargs)
TypeError: converter_init() got an unexpected keyword argument 'type'
make: *** [clinic] Erreur 255

----------
components: Build
messages: 229107
nosy: brett.cannon, larry, pitrou
priority: critical
severity: normal
status: open
title: "make clinic" doesn't work
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 12 09:35:07 2014
From: report at bugs.python.org (Aivar Annamaa)
Date: Sun, 12 Oct 2014 07:35:07 +0000
Subject: [New-bugs-announce] [issue22616] Allow connecting AST nodes with
	corresponding source	ranges
Message-ID: <1413099307.65.0.261518195286.issue22616@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

Currently lineno and col_offset attributes in AST nodes have confusing roles. According to documentation they indicate the starting position of node's source text but according to recent developments (#16795) they seem to indicate a position most suitable to use in error messages related to that node (rather narrow goal IMO).

Another problem is that currently the AST nodes don't contain any information about the end position of corresponding source text. Therefore it's very difficult to relate nodes with source. One could want to do this for example in advanced graphical debuggers (https://bitbucket.org/plas/thonny)

I propose adding new attributes to AST nodes which indicate the corresponding source range. If you want to keep nodes lightweight by default, then you could also introduce a flag in ast.parse for getting these attributes.

The range could be given either in token indices or in character positions (or both). This probably needs more discussion. (I would vote against pointers to UTF-8 bytes, as is the case with col_offset currently.)

----------
components: Interpreter Core
messages: 229124
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: Allow connecting AST nodes with corresponding source ranges
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 12 14:46:40 2014
From: report at bugs.python.org (LuisC)
Date: Sun, 12 Oct 2014 12:46:40 +0000
Subject: [New-bugs-announce] [issue22617] Jobs Opportunities in France/Canada
Message-ID: <20141012115353.3110736DA26@zimbra.bajajcapital.com>


New submission from LuisC:

Jobs Opportunities in France/Canada

This letter is to inform you on behalf of the management of EVANS HOTEL & Suites Paris France, that the hotel needs able men and women, married and not married who are willing to relocate to France in order to fill various slots in the available jobs/vacancies in their hotels.

Accountant, accounting clerk
  * minimum education requires:- diploma certificate
  * skills requires: - record-keeping , project organization, computer literacy

Barkeeper, bartender
  * minimum education requires:- high school certificate
  * skills requires: - dealing with the public, customer service

Cleaner, car wash, laundry
  * minimum education requires:- any
  * skills requires: - care and hard working

Customer services, reservation agents
  * minimum education requires:- diploma
  * skills requires: - dealing with the public,English/French, computer skills

Master chef, meat - poultry & fish chef, pasta chef, sauce chef
  * minimum education requires:- certificate
  * skills requires: - serving, customer service, Busing, estimating amounts

Apprentice cook, grill cook, short order cook
  * minimum education requires:- trained cook
  * skills requires: cooking, serving

Host, hostess, waiter, waitress
  * minimum education requires:- high school certificate
  * skills requires: - dealing with the public,English/French

Food service supervisors
  * minimum education requires:- high school certificate
  * skills requires: - customer service , communication skills ,English/French

Sales administrator, sales person, retail sales clerk
  * minimum education requires:- high school certificate
  * skills requires: - dealing with the public, customer service, product
  Knowledge Hotel nurses
  * minimum education requires:- certificate
  * skills requires: - minimum 2 years experience

Store keeper, store keeper supervisor
  * minimum education requires:- high school certificate
  * skills requires: - dealing with the public, customer service, product
  Knowledge

Receptionist, secretary, hotel front desk, clerks
  * minimum education requires:- high school certificate
  * skills requires: - dealing with the public, customer service, scheduling

Electronics technicians, computer engineer
  * minimum education requires:- certificate
  * skills requires: - customer service

Dj , dancers , musicians
  * minimum education requires:- any
  * skills requires: - professional

Day / night security guard
  * minimum education requires:- high school

* skills requires: - trained, strong and intelligent Computer operator ,
  graphic designer

* minimum education requires:- certificate
  * skills requires: - professional computer literacy

The hotel management will take care of your accommodation & flight ticket to France or Canada any where the management which to post you for service.

Requirements
  * color passport photograph
  * cv/resume (English OR French)

interested applicant should click on reply to Contact EVANS HOTEL management.

Mr. Mario Costa
Email:- applicetionoffice at job4u.com
      Tel: +33 605 734 438 / Fax: + 33 160 54177 42
      20 Avenue Victoria 75001 Paris France

We wish you good luck!

Sincerely,
  Ms.Myrna Kilcrease

France/Canada Foreign Workers Services
Email:- info.kilcrease at gmail.com

----------
messages: 229142
nosy: lcarrionr
priority: normal
severity: normal
status: open
title: Jobs Opportunities in France/Canada

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

From report at bugs.python.org  Sun Oct 12 15:56:21 2014
From: report at bugs.python.org (Alex Vaystikh)
Date: Sun, 12 Oct 2014 13:56:21 +0000
Subject: [New-bugs-announce] [issue22618] urllib.parse.parse_qsl different
	results after	urllib.parse.unquote
Message-ID: <1413122181.37.0.728502828464.issue22618@psf.upfronthosting.co.za>


New submission from Alex Vaystikh:

parsing query-string before and after cleaning with urllib.parse.unquote can have very different results: http://nbviewer.ipython.org/gist/bornio/e112e6d8d04dfed898c8

Perhaps it should be better documented, or make the method more idempotent?

----------
components: Library (Lib)
messages: 229144
nosy: Alex.Vaystikh, orsenthil
priority: normal
severity: normal
status: open
title: urllib.parse.parse_qsl different results after urllib.parse.unquote
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 12 17:24:10 2014
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 12 Oct 2014 15:24:10 +0000
Subject: [New-bugs-announce] [issue22619] Possible implementation of
	negative limit for traceback	functions
Message-ID: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov:

This is the possible patch for this proposal: https://mail.python.org/pipermail/python-ideas/2014-October/029826.html.

----------
components: Library (Lib)
messages: 229167
nosy: vlth
priority: normal
severity: normal
status: open
title: Possible implementation of negative limit for traceback functions
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Oct 12 20:16:05 2014
From: report at bugs.python.org (Cristian Baboi)
Date: Sun, 12 Oct 2014 18:16:05 +0000
Subject: [New-bugs-announce] [issue22620] pythonw does not open on windows
	8.1 x64
Message-ID: <1413137765.14.0.582555536728.issue22620@psf.upfronthosting.co.za>


Changes by Cristian Baboi <cristian.baboi at gmail.com>:


----------
components: Windows
nosy: Cristian.Baboi
priority: normal
severity: normal
status: open
title: pythonw does not open on windows 8.1 x64
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 13 08:09:23 2014
From: report at bugs.python.org (josch)
Date: Mon, 13 Oct 2014 06:09:23 +0000
Subject: [New-bugs-announce] [issue22621] Please make it possible to make
	the output of hash()	equal between 32 and 64 bit architectures
Message-ID: <1413180563.52.0.548204621913.issue22621@psf.upfronthosting.co.za>


New submission from josch:

I recently realized that the output of the following is different between 32 bit and 64 bit architectures:

PYTHONHASHSEED=0 python3 -c 'print(hash("a"))'

In my case, I'm running some test cases which involve calling a Python module which creates several hundred megabyte big graphs and other things. The fastest way to make sure that the output I get is the same that I expect is to just call the md5sum or sha256sum shell tools on the output and compare them with the expected values. Unfortunately, some libraries I use rely on the order of items in Python dictionaries for their output. Yes, they should not do that but they also don't care and thus don't fix the problem.

My initial solution to this was to use PYTHONHASHSEED=0 which helped but I now found out that this is limited to producing the same hash within the set of 32 bit and 64 bit architectures, respectively. See above line which behaves different depending on the integer size of architectures.

So what I'd like CPython to have is yet another workaround like PYTHONHASHSEED which allows me to temporarily influence the inner workings of the hash() function such that it behaves the same on 32 bit and 64 bit architectures. Maybe something like PYTHONHASH32BIT or similar?

If I understand the CPython hash function correctly, then this environment variable would just bitmask the result of the function with 0xFFFFFFFF or cast it to int32_t to achieve the same output across architectures.

Would this be possible?

My only alternative seems to be to either maintain patched versions of all modules I use which wrongly rely on dictionary ordering or to go to great lengths of parsing the (more or less) random output they produce into a sorted intermediary format - which seems like a bad idea because the files are several hundred megabytes big and this would just take very long and require additional complexity in handling them compared to being able to just md5sum or sha256sum them for the sake of checking whether my test cases succeed or not.

----------
messages: 229219
nosy: josch
priority: normal
severity: normal
status: open
title: Please make it possible to make the output of hash() equal between 32 and 64 bit architectures
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 13 13:16:08 2014
From: report at bugs.python.org (towb)
Date: Mon, 13 Oct 2014 11:16:08 +0000
Subject: [New-bugs-announce] [issue22622] ElementTree only writes
	declaration when passed encoding
Message-ID: <1413198968.88.0.623198680069.issue22622@psf.upfronthosting.co.za>


New submission from towb:

This generates an XML declaration:

    import xml.etree.ElementTree as ET

    root = ET.Element('rss', version='2.0')
    tree = ET.ElementTree(root)
    tree.write('test.xml', encoding='iso-8859-1', xml_declaration=True)

However the declaration disappears if your don't pass an encoding. This doesn't match the documentation:

    xml_declaration controls if an XML declaration should be added to the file. Use False for never, True for always, None for only if not US-ASCII or UTF-8 or Unicode (default is None).

----------
components: Library (Lib)
messages: 229238
nosy: towb
priority: normal
severity: normal
status: open
title: ElementTree only writes declaration when passed encoding
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 13 14:44:03 2014
From: report at bugs.python.org (Link Mauve)
Date: Mon, 13 Oct 2014 12:44:03 +0000
Subject: [New-bugs-announce] [issue22623] Missing guards for some POSIX
	functions
Message-ID: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za>


New submission from Link Mauve:

Many POSIX functions aren?t available on every system, especially embedded ones.

The first patch introduces guards around some of these functions and add them to AC_CHECK_FUNCS in the configure.ac; the second one recompile every changed generated file, using autoreconf -fi and clinic.

----------
components: Build
hgrepos: 276
messages: 229243
nosy: Link Mauve
priority: normal
severity: normal
status: open
title: Missing guards for some POSIX functions
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 13 20:34:55 2014
From: report at bugs.python.org (Link Mauve)
Date: Mon, 13 Oct 2014 18:34:55 +0000
Subject: [New-bugs-announce] [issue22624] Bogus usage of floatclock in
	timemodule
Message-ID: <1413225295.8.0.611582673071.issue22624@psf.upfronthosting.co.za>


New submission from Link Mauve:

In Modules/timemodule.c, py_process_time() still uses floatclock() even when HAVE_CLOCK isn?t defined.

----------
components: Build
messages: 229260
nosy: Link Mauve
priority: normal
severity: normal
status: open
title: Bogus usage of floatclock in timemodule
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 13 20:50:19 2014
From: report at bugs.python.org (Link Mauve)
Date: Mon, 13 Oct 2014 18:50:19 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue22625=5D_When_cross-compili?=
 =?utf-8?q?ng=2C_don=E2=80=99t_try_to_execute_binaries?=
Message-ID: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>


New submission from Link Mauve:

```
% make
./Programs/_freeze_importlib \
        ./Lib/importlib/_bootstrap.py Python/importlib.h
./Programs/_freeze_importlib: ./Programs/_freeze_importlib: cannot execute binary file
Makefile:710: recipe for target 'Python/importlib.h' failed
make: *** [Python/importlib.h] Error 126
```

I tried `make touch` as it was suggested to me on #python-dev, but it didn?t fix that issue.

----------
components: Cross-Build
messages: 229261
nosy: Link Mauve
priority: normal
severity: normal
status: open
title: When cross-compiling, don?t try to execute binaries
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 13 21:53:44 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 13 Oct 2014 19:53:44 +0000
Subject: [New-bugs-announce] [issue22626] Documentation should point people
	to bugs. over HTTPS
Message-ID: <1413230024.39.0.966950626463.issue22626@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Very simple patch.

----------
assignee: docs at python
components: Documentation
files: https.diff
keywords: patch
messages: 229266
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: Documentation should point people to bugs. over HTTPS
versions: Python 3.5
Added file: http://bugs.python.org/file36903/https.diff

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

From report at bugs.python.org  Tue Oct 14 03:31:45 2014
From: report at bugs.python.org (Christopher Lee)
Date: Tue, 14 Oct 2014 01:31:45 +0000
Subject: [New-bugs-announce] [issue22627] Calling timestamp() on a datetime
	object modifies the	timestamp of a different datetime object.
Message-ID: <1413250305.11.0.302636475589.issue22627@psf.upfronthosting.co.za>


New submission from Christopher Lee:

I have an example script here[1].
This script creates 2 datetime objects (using a timedelta work around to deal with large timestamps).
It then makes 2 assertions, that the timestamp of the created object is the same as the one that was used to create it. (when run with no arguments this script passes both assertions).
However, if the argument 'breakme' is passed to the script then after the first assertion the method 'timestamp()' is called on a different (un-asserted) datetime which will now make the 2nd assertion fail.

[1] http://paste.ubuntu.com/8556130/

----------
components: Library (Lib)
messages: 229276
nosy: thomir, veebers
priority: normal
severity: normal
status: open
title: Calling timestamp() on a datetime object modifies the timestamp of a different datetime object.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 14 05:09:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 14 Oct 2014 03:09:38 +0000
Subject: [New-bugs-announce] [issue22628] Idle: Tree lines are spaced too
	close together.
Message-ID: <1413256178.66.0.725794954703.issue22628@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

(Mentioned on #16233) At least on my windows 7 system, the lines of idlelib.TreeWidget, used for Path Browser and Class (Module) Browser, are spaced too narrowly.  They are so close together that they overlap and each cuts off enough of the line above to make reading difficult.

TreeWidget is actually a canvas painted with icons, connecting lines, and lines of text. There is no automatic spacing of text lines as with tkinter.Text.  A comment in the draw method notes "XXX This hard-codes too many geometry constants!".

The attached patch changes two of the constants.  Increasing dy spreads the line apart a bit so there is very little clipping. (Both g and y are sometimes complete, sometimes not.) The other change moves the lines up relative to the icons so they are not offset.

Saimadhav, does this change look ok on linux?

I think the long term fix (before 3.5) is to use ttk.Treeview.  So I am not inclined to spend lots of time fine-tuning on various systems or adding user configuration (though we might for Treeview).  However, dy could be made conditional on, for instance, sys.platform[0:3] == 'win'.

----------
assignee: terry.reedy
files: atree.diff
keywords: patch
messages: 229277
nosy: sahutd, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Idle: Tree lines are spaced too close together.
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36905/atree.diff

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

From report at bugs.python.org  Tue Oct 14 05:33:50 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 14 Oct 2014 03:33:50 +0000
Subject: [New-bugs-announce] [issue22629] Idle: update htest.py and hests
Message-ID: <1413257630.76.0.367621064016.issue22629@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

After using idle-test/htest.py and individual htests when editing files, a few updates are needed.

1. Improve the docstring for htest.py; add info about "# htest #" and #2 below.

2. Use Toplevel(parent) instead of Tk() for test-specific childs windows of the main, master window.  Currently, for some tests, such as CallTipWindow, the focus does not properly shift to the test window. Closing the master window first leaves the test window open.  Closing the test window second then causes several tcl errors (printed to console if available), a Windows message, and an Idle freeze of 5 seconds or more before Idle works again.  The change in this initial patch fixes the focus, non-close, error, and hang problems.  One click and the test window is ready to go; one click on the master and both go away.

3. Coding style issues -- I prefer to use winfo_rootx/y, as done elsewhere in Idle, to using re (close call).  For CallTipWindow, the inner class is not needed now, if it ever was.

----------
components: IDLE
files: @htest-34.diff
keywords: patch
messages: 229278
nosy: sahutd, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Idle: update htest.py and hests
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36906/@htest-34.diff

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

From report at bugs.python.org  Tue Oct 14 11:05:54 2014
From: report at bugs.python.org (Ben Mather)
Date: Tue, 14 Oct 2014 09:05:54 +0000
Subject: [New-bugs-announce] [issue22630]
	`concurrent.futures.Future.set_running_or_notify_cancel`	does
	not notify cancel
Message-ID: <1413277554.48.0.992007500484.issue22630@psf.upfronthosting.co.za>


New submission from Ben Mather:

The documentation for the `set_running_or_notify_cancel` method on `concurrent.futures.Future` states that it will notify waiting threads and trigger callbacks after the `Future` has been cancelled, however currently this is done immediately by the call to `cancel`.

Oddly waiters (private interface used to implement `wait` and `as_completed`) do follow the behaviour documented for callbacks (they are called in `set_running_or_notify_cancel`) which means that they are not equivalent to setting a callback on each future.


I have attached three possible patches:
 1) "change-callbacks.patch" - this changes the behaviour to match the documentation.
 2) "change-docs.patch" - this fixes the documentation to match the current behaviour.
 3) "change-docs-and-waiters.patch" - in addition to fixing the documentation, this also fixes the inconsistency between waiters and callbacks by invoking waiters' `add_cancelled` method in `cancel`.

I believe moving to the documented behaviour (1) would be a mistake as currently `set_running_or_notify_cancel` and the `RUNNING` state can be skipped entirely allowing Futures to be used just as a way to send results.

Should mention that I have a separate patch (which I will submit separately (or here?)) that re-implements `wait` and `as_completed` using only publicly exposed methods.  This makes it possible to extend or replace `Future` without having to preserve its private interface.  Unfortunately this slightly breaks compatibility due to the difference between waiters and callbacks.  I thought it would be best to discuss this issue first as I don't believe the current behaviour is as intended.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: change-callbacks.patch
keywords: patch
messages: 229282
nosy: bwhmather, docs at python
priority: normal
severity: normal
status: open
title: `concurrent.futures.Future.set_running_or_notify_cancel` does not notify cancel
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36908/change-callbacks.patch

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

From report at bugs.python.org  Tue Oct 14 16:21:28 2014
From: report at bugs.python.org (Stefan Tatschner)
Date: Tue, 14 Oct 2014 14:21:28 +0000
Subject: [New-bugs-announce] [issue22631] Feature Request CAN_RAW_FD_FRAME
Message-ID: <1413296488.48.0.164198774992.issue22631@psf.upfronthosting.co.za>


New submission from Stefan Tatschner:

CAN support was introduced with issue #10141. Python still seems to lack support for CAN FD which is available with the socket option CAN_RAW_FD_FRAMES, see here (chapter 4.1.5): https://www.kernel.org/doc/Documentation/networking/can.txt

----------
components: IO
messages: 229289
nosy: rumpelsepp
priority: normal
severity: normal
status: open
title: Feature Request CAN_RAW_FD_FRAME
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 14 20:28:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Oct 2014 18:28:52 +0000
Subject: [New-bugs-announce] [issue22632] Official IDLE web page address is
	not valid
Message-ID: <1413311332.96.0.42616641652.issue22632@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

WWW address (http://www.python.org/idle/) mentioned in "About IDLE" dialog window is no longer valid.

----------
assignee: docs at python
components: Documentation, IDLE
messages: 229329
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: Official IDLE web page address is not valid
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Oct 14 20:35:14 2014
From: report at bugs.python.org (Guido)
Date: Tue, 14 Oct 2014 18:35:14 +0000
Subject: [New-bugs-announce] [issue22633] Memory disclosure/buffer overread
	via bug in	Py_FrozenMain
Message-ID: <1413311714.85.0.507321102423.issue22633@psf.upfronthosting.co.za>


New submission from Guido:

Python/frozenmain.c:27 - https://hg.python.org/cpython/file/424fbf011176/Python/frozenmain.c#l27

Memory is allocated for sizeof(wchar_t*) * argc bytes. If argc is 0 (which is a possibility, see below), then 0 bytes are attempted to allocate.

Note that PyMem_RawMalloc typically calls _PyMem_RawMalloc, which ensures that a nonzero value is passed to malloc: https://hg.python.org/cpython/file/424fbf011176/Objects/obmalloc.c#l60

In the case of argc == 1, we have the guarantee that one byte is allocated.


Then, this: https://hg.python.org/cpython/file/424fbf011176/Python/frozenmain.c#l54 routine fills the argv_copy array with values. However, if argc == 0, this code is never reached.

https://hg.python.org/cpython/file/424fbf011176/Python/frozenmain.c#l71 then sets the program name to argv_copy[0] using Py_SetProgramName().

The issue here is is that because argv_copy[0] may be uninitialized, it may be a nonzero value, because, as far as I know, malloc doesn't give any guarantees as to the initial values of the allocated values (hence the existence of something like calloc).

If a pointer to a zero byte is passed to Py_SetProgramName(), the function doesn't change progname: https://hg.python.org/cpython/file/424fbf011176/Python/pythonrun.c#l884

But since there are no guarantees as to what argv_copy[0] is AND there are no guarantees about the memory region that follows, a rare and unlikely though theoretically possible situation may emerge where each time progname is referenced (for example indirectly by reading to sys.executable), a string is returned that contains bytes after argv_copy[0], resulting in a memory disclosure.

Here's an example of how to run a program with zero arguments (argc == 0):

// https://stackoverflow.com/questions/8113786/executing-a-process-with-argc-0

#include <spawn.h>
#include <stdlib.h>

int main(int argc, char** argv, char** envp)
{
        pid_t pid;
        char* zero_argv[] = {NULL};
        posix_spawn(&pid, "./hello", NULL, NULL, zero_argv, envp);

        int status;
        waitpid(&pid, &status, NULL);
        return 0;
}

I propose the following patch:

--- frozenmain.c	2014-10-14 19:56:27.144705062 +0200
+++ new_frozenmain.c	2014-10-14 19:59:16.800704366 +0200
@@ -24,13 +24,15 @@
     /* We need a second copies, as Python might modify the first one. */
     wchar_t **argv_copy2 = NULL;
 
-    argv_copy = PyMem_RawMalloc(sizeof(wchar_t*) * argc);
+    argv_copy = PyMem_RawMalloc(sizeof(wchar_t*) * (argc ? argc : 1));
     argv_copy2 = PyMem_RawMalloc(sizeof(wchar_t*) * argc);
     if (!argv_copy || !argv_copy2) {
         fprintf(stderr, "out of memory\n");
         goto error;
     }
 
+    argv_copy[0] = '\0';
+
     Py_FrozenFlag = 1; /* Suppress errors from getpath.c */
 
     if ((p = Py_GETENV("PYTHONINSPECT")) && *p != '\0')

By enforcing a minimal allocation of 1 byte in this file, we are guaranteed that malloc doesn't return a non-zero value after it is called with malloc(0) (this is possible, see man malloc) and we don't have to rely on the heap allocator to do this (in case it's not _PyMem_RawMalloc).

Setting argv_copy[0] to zero ensures a buffer overread will never occur.

Tested only for Python 3.4.

Guido

----------
messages: 229330
nosy: Guido
priority: normal
severity: normal
status: open
title: Memory disclosure/buffer overread via bug in Py_FrozenMain
type: security
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 14 21:59:45 2014
From: report at bugs.python.org (Siming Yuan)
Date: Tue, 14 Oct 2014 19:59:45 +0000
Subject: [New-bugs-announce] [issue22634] importing _ctypes failed:
	undefined symbol:	ffi_call_win32
Message-ID: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>


New submission from Siming Yuan:

Compiling Python 3.4.2 32-bit using GCC under RHEL6.4 and RHEL5.5 yields to crash:

*** WARNING: renaming "_ctypes" since importing it failed: build/lib.linux-x86_64-3.4/_ctypes.cpython-34m.so: undefined symbol: ffi_call_win32

Why is it referring to a win32 api when i'm compiling under Linux?

This failure causes pip installation to also fail due to missing ctypes module.

FYI - 3.4.1 under exact same env. builds fine.

----------
components: Build
messages: 229342
nosy: Siming.Yuan
priority: normal
severity: normal
status: open
title: importing _ctypes failed: undefined symbol: ffi_call_win32
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 14 23:09:18 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 14 Oct 2014 21:09:18 +0000
Subject: [New-bugs-announce] [issue22635] subprocess.getstatusoutput changed
	behavior in 3.4	(maybe 3.3.4?)
Message-ID: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

(U) The examples for the function still show the return code in the form os.popen would produce (a program exiting with status 1 would return 256 as the status), but the new code from #10197 makes the status 1, not 256.

(U) This is a breaking change for code relying on what was already a legacy interface. Either the docs should call out the change, or the code needs to restore the previous behavior.

(U) Ultra simple repro:

>>> subprocess.getstatusoutput('python -c "exit(1)"')
Expected:
(256, '')
Actual:
(1, '')

----------
messages: 229354
nosy: josh.rosenberg
priority: normal
severity: normal
status: open
title: subprocess.getstatusoutput changed behavior in 3.4 (maybe 3.3.4?)
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 15 00:32:55 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Oct 2014 22:32:55 +0000
Subject: [New-bugs-announce] [issue22636] avoid using a shell in
	ctypes.util: replace os.popen	with subprocess
Message-ID: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies the ctypes.util module to not use a shell: it replaces os.open() with subprocess.Popen on Linux.

Running a shell is slower and is more vulnerable to code injection.

I only modified code path on Linux right now. They are still calls to os.popen() on sunos5, freebsd, openbsd and dragonfly.

----------
files: ctypes_util_popen.patch
keywords: patch
messages: 229363
nosy: haypo
priority: normal
severity: normal
status: open
title: avoid using a shell in ctypes.util: replace os.popen with subprocess
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36923/ctypes_util_popen.patch

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

From report at bugs.python.org  Wed Oct 15 00:35:37 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Oct 2014 22:35:37 +0000
Subject: [New-bugs-announce] [issue22637] avoid using a shell in uuid:
	replce os.popen with	subprocess.Popen
Message-ID: <1413326137.66.0.946040587589.issue22637@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modifies the uuid module to not use a shell: it replaces os.popen() with subprocess.Popen on UNIX.

Running a shell is slower and is more vulnerable to code injection.

I only modified code path on UNIX right now. They is still a call to os.popen() on Windows.

Note: The patch works on bytes string instead of Unicode.

----------
files: uuid_popen.patch
keywords: patch
messages: 229364
nosy: haypo
priority: normal
severity: normal
status: open
title: avoid using a shell in uuid: replce os.popen with subprocess.Popen
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36924/uuid_popen.patch

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

From report at bugs.python.org  Wed Oct 15 01:11:15 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Oct 2014 23:11:15 +0000
Subject: [New-bugs-announce] [issue22638] ssl module: the SSLv3 protocol is
	vulnerable ("POODLE"	attack)
Message-ID: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Copy of Donald Stuff email sent to python-dev:

A big security breach of SSL 3.0 just dropped a little while ago (named POODLE).
With this there is now no ability to securely connect via SSL 3.0. I believe
that we should disable SSL 3.0 in Python similarly to how SSL 2.0 is disabled,
where it is disabled by default unless the user has explicitly re-enabled it.

The new attack essentially allows reading the sensitive data from within a SSL
3.0 connection stream. It takes roughly 256 requests to break a single byte so
the attack is very practical. You can read more about the attack here at the
google announcement [1] or the whitepaper [2].

[1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
[2] https://www.openssl.org/~bodo/ssl-poodle.pdf

----------
messages: 229368
nosy: haypo
priority: normal
severity: normal
status: open
title: ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)
type: security
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 15 01:43:15 2014
From: report at bugs.python.org (Steve P)
Date: Tue, 14 Oct 2014 23:43:15 +0000
Subject: [New-bugs-announce] [issue22639] test "test_bad_address" fails on
	Python 3.4.2 under	Linux Mint 13 Maya
Message-ID: <1413330195.68.0.914082091574.issue22639@psf.upfronthosting.co.za>


New submission from Steve P:

Looking in past bug reports, I suspect the test itself is problematic. When I paste the (erroneous) URL the tests is using into Firefox, I get a page back from my ISP with "Sorry, the website sadflkjsasf.i.nvali.d cannot be found"

Here's the output of the test:

@chimp:~/Downloads/Python-3.4.2 $ ./python -m test -v test_bad_address
== CPython 3.4.2 (default, Oct 14 2014, 15:34:15) [GCC 4.6.3]
==   Linux-3.2.0-23-generic-i686-with-debian-wheezy-sid little-endian
==   hash algorithm: siphash24 32bit
==   /home/sp/Downloads/Python-3.4.2/build/test_python_11906
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_bad_address
test test_bad_address crashed -- Traceback (most recent call last):
  File "/home/sp/Downloads/Python-3.4.2/Lib/test/regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/home/sp/Downloads/Python-3.4.2/Lib/importlib/__init__.py", line 109, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2254, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2224, in _find_and_load_unlocked
ImportError: No module named 'test.test_bad_address'

1 test failed:
    test_bad_address

----------
components: Tests
messages: 229386
nosy: Steve.P
priority: normal
severity: normal
status: open
title: test "test_bad_address" fails on Python 3.4.2 under Linux Mint 13 Maya
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 15 10:23:20 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 15 Oct 2014 08:23:20 +0000
Subject: [New-bugs-announce] [issue22640] Add silent mode for py_compile
Message-ID: <1413361400.01.0.34334853586.issue22640@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is similar to issue 21338.

It would be good to add a new option "-q" to the CLI interface and add a new parameter "quiet" to py_compile.compile() (e.g. if doraise is False and quiet is True, do not print anything).

----------
assignee: berker.peksag
components: Library (Lib)
messages: 229409
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: Add silent mode for py_compile
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 15 11:53:41 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 15 Oct 2014 09:53:41 +0000
Subject: [New-bugs-announce] [issue22641] Use better default context in
	asyncio
Message-ID: <1413366821.48.0.472104990078.issue22641@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

asyncio is not yet bound by legacy use cases, so this patch switches asyncio to stronger default SSL settings for client connections. It also adds tests for that (the code path was untested).

----------
components: Library (Lib), asyncio
files: asyncio_default_context.patch
keywords: patch
messages: 229424
nosy: alex, christian.heimes, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Use better default context in asyncio
type: security
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36934/asyncio_default_context.patch

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

From report at bugs.python.org  Wed Oct 15 14:46:20 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 15 Oct 2014 12:46:20 +0000
Subject: [New-bugs-announce] [issue22642] trace module: unclear error message
Message-ID: <1413377180.82.0.707385230262.issue22642@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

$ python3.4 -m trace -l 
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/local/lib/python3.4/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.4/trace.py", line 858, in <module>
    main()
  File "/usr/local/lib/python3.4/trace.py", line 787, in main
    progname = prog_argv[0]
IndexError: list index out of range


I would expect something more clear to be printed, like the program usage helper you get in this case:

$ python3.4 -m trace 
/usr/local/lib/python3.4/trace.py: must specify one of --trace, --count, --report, --listfuncs, or --trackcalls

----------
messages: 229441
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: trace module: unclear error message
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 15 16:50:30 2014
From: report at bugs.python.org (paul)
Date: Wed, 15 Oct 2014 14:50:30 +0000
Subject: [New-bugs-announce] [issue22643] Integer overflow in case_operation
Message-ID: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za>


New submission from paul:

Crashes python 3.4.1. 

# Objects\unicodeobject.c
# 
# static PyObject *
# case_operation(PyObject *self,
#                Py_ssize_t (*perform)(int, void *, Py_ssize_t, Py_UCS4 *, Py_UCS4 *))
# {
#     PyObject *res = NULL;
#     Py_ssize_t length, newlength = 0;
#     int kind, outkind;
#     (...)
# 1   length = PyUnicode_GET_LENGTH(self);
# 2   tmp = PyMem_MALLOC(sizeof(Py_UCS4) * 3 * length);
#     (...)
# 3   newlength = perform(kind, data, length, tmp, &maxchar);
# 
# 1. there are no safety checks 
# 2. 12*length overflows
# 3. perform() writes to tmp buffer, which is too small to hold the result

----------
files: poc_case_op.py
messages: 229455
nosy: pkt
priority: normal
severity: normal
status: open
title: Integer overflow in case_operation
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file36941/poc_case_op.py

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

From report at bugs.python.org  Wed Oct 15 17:21:32 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 15 Oct 2014 15:21:32 +0000
Subject: [New-bugs-announce] [issue22644] Update Windows installers to
	OpenSSL 1.0.1j
Message-ID: <1413386492.03.0.06348060819.issue22644@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://www.openssl.org/news/secadv_20141015.txt

----------
components: Extension Modules
keywords: security_issue
messages: 229462
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update Windows installers to OpenSSL 1.0.1j

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

From report at bugs.python.org  Wed Oct 15 17:44:16 2014
From: report at bugs.python.org (Zac Greve)
Date: Wed, 15 Oct 2014 15:44:16 +0000
Subject: [New-bugs-announce] [issue22645] Unable to install Python 3.4.2
	amd64 on Windows 8.1	Update 1
Message-ID: <1413387856.31.0.878649422025.issue22645@psf.upfronthosting.co.za>


New submission from Zac Greve:

I am unable to install Python 3.4.2 amd64 on Windows as the installer exits with an error stating that it cannot run a required program.

----------
components: Windows
messages: 229465
nosy: Zac.Greve
priority: normal
severity: normal
status: open
title: Unable to install Python 3.4.2 amd64 on Windows 8.1 Update 1
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 15 20:09:30 2014
From: report at bugs.python.org (panos black)
Date: Wed, 15 Oct 2014 18:09:30 +0000
Subject: [New-bugs-announce] [issue22646] Set SMTPHandler's "credentials"
	through	"logging.config.dictConfig".
Message-ID: <1413396570.86.0.25871256892.issue22646@psf.upfronthosting.co.za>


New submission from panos black:

If you configure logging using a JSON file, then, after you parse it and you pass it to logging.config.dictConfig(), you realize that when you define an SMTPHandler you can't set "credentials", or, more precisely, whether you set it or not the credentials value is ignored.

This happens because SMTPHandler's __init__ has the following code

        if isinstance(credentials, tuple):
            self.username, self.password = credentials
        else:
            self.username = None

while "credentials" inside dictConfig() is a "ConvertingList" and not a "tuple". As a result, username is set to None. 

I think that this is a problem because:

a) "credentials" is allowed to be specified in the configuration file (i.e. if you have an identifier that SMTPHandler's __init__, knows nothing about then you get an exception).
b) Other fields like, "timeout", and "toaddrs" work as expected (i.e. you can set them just fine)
c) This behaviour is not documented and you end up with improperly configured logging.

I guess that similar problems exist in other handlers too, but I haven't checked them one by one.

I think that it would make sense to be able to set all __init__ arguments in the Handlers section, or at least, if this is not desirable, to document this behaviour.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 229488
nosy: docs at python, panos.black, vinay.sajip
priority: normal
severity: normal
status: open
title: Set SMTPHandler's "credentials" through "logging.config.dictConfig".
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 15 21:35:38 2014
From: report at bugs.python.org (Steve P)
Date: Wed, 15 Oct 2014 19:35:38 +0000
Subject: [New-bugs-announce] [issue22647] test_readline failed on
	ScientificLinux 6.5
Message-ID: <1413401738.61.0.369363357097.issue22647@psf.upfronthosting.co.za>


New submission from Steve P:

"make test" after clean build got one failure. This was under Python 3.4.2 newly downloaded. Here is the log:

./python -m test -v test_readline
== CPython 3.4.2 (default, Oct 15 2014, 11:08:11) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
==   Linux-2.6.32-431.29.2.el6.x86_64-x86_64-with-redhat-6.5-Carbon little-endian
==   hash algorithm: siphash24 64bit
==   /home/pothiers/Downloads/Python-3.4.2/build/test_python_19950
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_readline
testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok
test_init (test.test_readline.TestReadline) ... FAIL

======================================================================
FAIL: test_init (test.test_readline.TestReadline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pothiers/Downloads/Python-3.4.2/Lib/test/test_readline.py", line 53, in test_init
    self.assertEqual(stdout, b'')
AssertionError: b'\x1b[?1034h' != b''

----------------------------------------------------------------------
Ran 2 tests in 0.021s

FAILED (failures=1)
test test_readline failed
1 test failed:
    test_readline

----------
messages: 229493
nosy: Steve.P
priority: normal
severity: normal
status: open
title: test_readline failed on ScientificLinux 6.5
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 15 21:45:08 2014
From: report at bugs.python.org (Pierre Boulanger)
Date: Wed, 15 Oct 2014 19:45:08 +0000
Subject: [New-bugs-announce] [issue22648] Unable to install Python 3.4.2
	amd64 on Windows 8.1
Message-ID: <1413402308.59.0.884804309845.issue22648@psf.upfronthosting.co.za>


New submission from Pierre Boulanger:

I try to install python 3.4.2-amd 64 but i have an error: a program used for the installation could not be run.

befor i have python 3.4.1 and it work perfectly.

----------
components: Installation
messages: 229494
nosy: brp-log
priority: normal
severity: normal
status: open
title: Unable to install Python 3.4.2 amd64 on Windows 8.1
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 15 22:30:45 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Oct 2014 20:30:45 +0000
Subject: [New-bugs-announce] [issue22649] Use _PyUnicodeWriter in
	case_operation()
Message-ID: <1413405045.21.0.992047718976.issue22649@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The case_operation() in Objects/unicodeobject.c is used for case operations: lower, upper, casefold, etc.

Currently, the function uses a buffer of Py_UCS4 and overallocate the buffer by 300%. The function uses the worst case: one character replaced with 3 characters.

I propose the use the _PyUnicodeWriter API to be able to optimize the most common case: each character is replaced by only one another character, and the output string uses the same unicode kind (UCS1, UCS2 or UCS4).

The patch preallocates the writer using the kind of the input string, but in some cases, the result uses a lower kind (ex: latin1 => ASCII). "Special" characters taking the slow path from unit tests:

- test_capitalize: '?nnish' => 'FInnish' (ascii)
- test_casefold: '?' => 'ss', '?' => 'fi'
- test_swapcase: '?' => 'FI', '?' => 'SS'
- test_title: '?NNISH' => 'Finnish'
- test_upper: '?' => 'FI', '?' => 'SS'

The writer only uses overallocation if a replaced character uses more than one character. Bad cases where the length changes:

- test_capitalize: '????' => '?????', 'h?' => 'Hi?', '??' => '???i?', '?nnish' => 'FInnish'
- test_casefold: '?' => 'ss', '?' => 'fi'
- test_lower: '?' => 'i?'
- test_swapcase: '?' => 'FI', '?' => 'i?', '?' => 'SS', '?' => '???'
- test_title: '?NNISH' => 'Finnish'
- test_upper: '?' => 'FI', '?' => 'SS', '?', '???'

----------
files: case_writer.patch
keywords: patch
messages: 229497
nosy: haypo
priority: normal
severity: normal
status: open
title: Use _PyUnicodeWriter in case_operation()
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file36942/case_writer.patch

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

From report at bugs.python.org  Thu Oct 16 00:27:08 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 15 Oct 2014 22:27:08 +0000
Subject: [New-bugs-announce] [issue22650] set up and use VM for net access
	in the test suite
Message-ID: <1413412028.88.0.410856906094.issue22650@psf.upfronthosting.co.za>


New submission from Georg Brandl:

Our test suite currently contacts a range of hosts for different "online" tests, including python.org hosts.  This has led to sudden breakages in the past, e.g. when www.python.org changed URLs or switched to https by default.

It would probably a good idea to consolidate as much as possible into accessing a new VM called something like "testsuite.python.org", where the necessary services can be kept running regardless of the necessities of actual python.org services.

First step to do this is to compile a list of tests that could use the VM, and a list of services that need to be running.

----------
components: Tests
messages: 229505
nosy: dstufft, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: set up and use VM for net access in the test suite
type: enhancement

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

From report at bugs.python.org  Thu Oct 16 09:57:11 2014
From: report at bugs.python.org (Nick Jacobson)
Date: Thu, 16 Oct 2014 07:57:11 +0000
Subject: [New-bugs-announce] [issue22651] Open file in a+ mode reads from
	end of file in Python 3.4
Message-ID: <1413446231.99.0.734842825619.issue22651@psf.upfronthosting.co.za>


New submission from Nick Jacobson:

In Python 2.7.8.10 running the following gives one result:

    >>> with open(r"C:\myfile.txt", "a+") as f:
    ...     f.tell()
    ...
    0L

But in Python 3.4.1.0 it gives a different result:

    >>> with open(r"C:\myfile.txt", "a+") as f:
    ...     f.tell()
    ...
    98

According to the man page for fopen, for a+ mode: "The initial file position for reading is at the beginning of the file." Source: http://linux.die.net/man/3/fopen

----------
components: IO
messages: 229511
nosy: nicksjacobson
priority: normal
severity: normal
status: open
title: Open file in a+ mode reads from end of file in Python 3.4
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Oct 16 12:33:37 2014
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 16 Oct 2014 10:33:37 +0000
Subject: [New-bugs-announce] [issue22652] Add suggestion about keyword
	arguments to this error	message: "builtins.TypeError:
	my_func() takes 1 positional	argument but 2 were given"
Message-ID: <1413455617.21.0.000325400143663.issue22652@psf.upfronthosting.co.za>


New submission from Ram Rachum:

When programming, I just got this exception:

    builtins.TypeError: my_func() takes 1 positional argument but 2 were given

After a couple of minutes of investigation I figured out that the problem is that the function has a `*` in its signature, so arguments must be specified as keyword arguments, not positional arguments.

It would be nice if the exception message would include some text to suggest that, like:

    builtins.TypeError: my_func() takes 1 positional argument but 2 were given. If you were trying to use the keyword-only argument foo, please specify it as foo=value.

It's a little verbose and specific, but maybe it'll help people figure out this problem, especially newbies. We can have logic to show this message only if there are keyword-only arguments.

----------
components: Interpreter Core
messages: 229521
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Add suggestion about keyword arguments to this error message: "builtins.TypeError: my_func() takes 1 positional argument but 2 were given"
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 16 14:21:14 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 16 Oct 2014 12:21:14 +0000
Subject: [New-bugs-announce] [issue22653] Crash in insertdict
Message-ID: <1413462074.66.0.621604261793.issue22653@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I got a weird crash in an interpreter session. Here is what I did:

$ ./python 
Python 3.5.0a0 (default:fd658692db3a+, Oct 15 2014, 23:13:43) 
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open('toto', 'ab')
>>> f.write(b'bb')
2
>>> f.flush()
>>> 
>>> f = open('toto', 'ab')
__main__:1: ResourceWarning: unclosed file <_io.BufferedWriter name='toto'>
python: Objects/dictobject.c:855: insertdict: Assertion `ep->me_key != ((void *)0) && ep->me_key != (&_dummy_struct)' failed.
Abandon (core dumped)


Here are the inner frames of the traceback:

(gdb) bt
#0  0x00007f27e691df77 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f27e69215e8 in __GI_abort () at abort.c:90
#2  0x00007f27e6916d43 in __assert_fail_base (fmt=0x7f27e6a6df58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion at entry=0x6878d0 "ep->me_key != ((void *)0) && ep->me_key != (&_dummy_struct)", file=file at entry=0x6874f2 "Objects/dictobject.c", 
    line=line at entry=855, function=function at entry=0x6880a0 <__PRETTY_FUNCTION__.10152> "insertdict") at assert.c:92
#3  0x00007f27e6916df2 in __GI___assert_fail (assertion=0x6878d0 "ep->me_key != ((void *)0) && ep->me_key != (&_dummy_struct)", 
    file=0x6874f2 "Objects/dictobject.c", line=855, function=0x6880a0 <__PRETTY_FUNCTION__.10152> "insertdict") at assert.c:101
#4  0x00000000004b65d0 in insertdict (mp=0x7f27e76f9838, key='f', hash=-9123380860235530973, value=<_io.BufferedWriter at remote 0x7f27e766e758>)
    at Objects/dictobject.c:855
#5  0x00000000004b752a in PyDict_SetItem (
    op={'f': <_io.BufferedWriter at remote 0x7f27e766e758>, '__builtins__': <module at remote 0x7f27e7750358>, '__spec__': None, '__warningregistry__': {'version': 0}, '__doc__': None, 'rlcompleter': <module at remote 0x7f27e5f0b358>, '__name__': '__main__', '__cached__': None, '__package__': None, '__loader__': <SourceFileLoader(name='__main__', path='/home/antoine/.pythonrc.py') at remote 0x7f27e765d468>, 'readline': <module at remote 0x7f27e5f0b058>}, 
    key='f', value=<_io.BufferedWriter at remote 0x7f27e766e758>) at Objects/dictobject.c:1245
#6  0x00000000005a9f7c in PyEval_EvalFrameEx (f=Frame 0x7f27e7704d78, for file <stdin>, line 1, in <module> (), throwflag=0) at Python/ceval.c:2065


Here are the hash initialization values:

(gdb) p _Py_HashSecret
$1 = {uc = "\260\306\vA\a\342\274\337\341\026\003\bbq\366\f\"\032E\232jb%\023", fnv = {prefix = -2324734786846079312, suffix = 934058638581110497}, 
  siphash = {k0 = 16122009286863472304, k1 = 934058638581110497}, djbx33a = {padding = "\260\306\vA\a\342\274\337\341\026\003\bbq\366\f", 
    suffix = 1379617070853200418}, expat = {padding = "\260\306\vA\a\342\274\337\341\026\003\bbq\366\f", hashsalt = 1379617070853200418}}
(gdb) p PyHash_Func
$2 = {hash = 0x5ee557 <siphash24>, name = 0x6b2020 "siphash24", hash_bits = 64, seed_bits = 128}


The crash seems difficult to reproduce simply by typing the lines above. Perhaps by forcing the hash initialization values as above.

----------
components: Interpreter Core
messages: 229524
nosy: Mark.Shannon, pitrou
priority: normal
severity: normal
status: open
title: Crash in insertdict
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 16 23:09:55 2014
From: report at bugs.python.org (Billy)
Date: Thu, 16 Oct 2014 21:09:55 +0000
Subject: [New-bugs-announce] [issue22654] issue with PYTHON_FOR_BUILD
Message-ID: <1413493795.91.0.752363282337.issue22654@psf.upfronthosting.co.za>


New submission from Billy:

Hi all,

I've been cross-compiling Python3.4.1, but I have a issue than is following:

_PYTHON_PROJECT_BASE=/home/aphillips/work/leo368-20141008/fs/apps/python-3.4.1/arm _PYTHON_HOST_PLATFORM=linux-arm PYTHONPATH=../src/Lib:../src/Lib/plat-linux  -S -m  sysconfig --generate-posix-vars ; \
	if test $? -ne 0 ; then \
		echo "generate-posix-vars failed" ; \
		rm -f ./pybuilddir.txt ; \
		exit 1 ; \
	fi
/bin/sh: -S: command not found
generate-posix-vars failed
make[1]: *** [pybuilddir.txt] Error 1

If who knows about that, could you help me.

Best regards.

----------
components: Cross-Build
messages: 229553
nosy: bill9889
priority: normal
severity: normal
status: open
title: issue with PYTHON_FOR_BUILD
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 17 05:49:46 2014
From: report at bugs.python.org (Mao Rui)
Date: Fri, 17 Oct 2014 03:49:46 +0000
Subject: [New-bugs-announce] [issue22655] Build error on CentOS 5.4
Message-ID: <1413517786.06.0.142832078616.issue22655@psf.upfronthosting.co.za>


New submission from Mao Rui:

I tried to build Python 3.4.2 on CentOS 5.2 x64, but got an error of _decimal module.

[maorui at ccsubfile1v ~/soft/python/Python-3.4.2]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)

logs:
building '_decimal' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/_decimal.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/_decimal.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/basearith.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/basearith.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/constants.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/constants.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/context.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/context.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/convolute.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/convolute.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/crt.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/crt.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/difradix2.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/difradix2.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/fnt.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/fnt.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/fourstep.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/fourstep.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/io.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/io.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/memory.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/memory.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/mpdecimal.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/mpdecimal.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/numbertheory.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/numbertheory.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/sixstep.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/sixstep.o -Wextra -Wno-missing-field-initializers
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCONFIG_64=1 -DASM=1 -I/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec -I./Include -I. -IInclude -I/usr/local/include -I/home/maorui/soft/python/Python-3.4.2/Include -I/home/maorui/soft/python/Python-3.4.2 -c /home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/transpose.c -o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/transpose.o -Wextra -Wno-missing-field-initializers
gcc -pthread -shared build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/_decimal.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/basearith.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/constants.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/context.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/convolute.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/crt.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/difradix2.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/fnt.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/fourstep.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/io.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/memory.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/mpdecimal.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/numbertheory.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/sixstep.o build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/transpose.o -L/usr/local/lib -o build/lib.linux-x86_64-3.4/_decimal.cpython-34m.so
/usr/bin/ld: build/temp.linux-x86_64-3.4/home/maorui/soft/python/Python-3.4.2/Modules/_decimal/libmpdec/basearith.o: relocation R_X86_64_PC32 against `mprime_rdx' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

----------
components: Build
files: python build error.zip
messages: 229564
nosy: maorui
priority: normal
severity: normal
status: open
title: Build error on CentOS 5.4
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file36953/python build error.zip

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

From report at bugs.python.org  Fri Oct 17 15:15:04 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 17 Oct 2014 13:15:04 +0000
Subject: [New-bugs-announce] [issue22656] `help` ignores `__doc__` of
	descriptors
Message-ID: <1413551704.24.0.449864930924.issue22656@psf.upfronthosting.co.za>


New submission from Ram Rachum:

The builtin `property` lets you specify a `doc` argument for your properties, which is great because then it shows up in `help`. So I figured that when I'm writing my own descriptor, I could set `__doc__` on it and have `help` use it. Not so, `help` ignores it. 

See this example:

    class Property(object):
        "Emulate PyProperty_Type() in Objects/descrobject.c"
    
        def __init__(self, fget=None, fset=None, fdel=None, doc=None):
            self.fget = fget
            self.fset = fset
            self.fdel = fdel
            if doc is None and fget is not None:
                doc = fget.__doc__
            self.__doc__ = doc
    
        def __get__(self, obj, objtype=None):
            if obj is None:
                return self
            if self.fget is None:
                raise AttributeError("unreadable attribute")
            return self.fget(obj)
    
        def __set__(self, obj, value):
            if self.fset is None:
                raise AttributeError("can't set attribute")
            self.fset(obj, value)
    
        def __delete__(self, obj):
            if self.fdel is None:
                raise AttributeError("can't delete attribute")
            self.fdel(obj)
    
        def getter(self, fget):
            return type(self)(fget, self.fset, self.fdel, self.__doc__)
    
        def setter(self, fset):
            return type(self)(self.fget, fset, self.fdel, self.__doc__)
    
        def deleter(self, fdel):
            return type(self)(self.fget, self.fset, fdel, self.__doc__)
    
    
    class A:
        x = property(lambda self: 3,
                     doc='Helpful text')
        
        y = Property(lambda self: 7,
                     doc='More Helpful text')
        
    
    help(A.x) # Shows 'Helpful text'
    help(A.y) # Does not show 'More Helpful text'
    

It seems that `property` is special-cased or something. I want to be able to set a docstring on my own descriptors.

----------
components: Library (Lib)
messages: 229572
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `help` ignores `__doc__` of descriptors
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 17 16:54:54 2014
From: report at bugs.python.org (Douglas Naphas)
Date: Fri, 17 Oct 2014 14:54:54 +0000
Subject: [New-bugs-announce] [issue22657] Bad link to packages specification
	in language reference	2.x sec 6.12
Message-ID: <1413557694.48.0.952625223829.issue22657@psf.upfronthosting.co.za>


New submission from Douglas Naphas:

Section 6.12 of the Python 2.x language reference (https://docs.python.org/2/reference/simple_stmts.html#the-import-statement) has a link to "The original specification for packages" to http://www.python.org/doc/essays/packages.html, which is not found.

----------
assignee: docs at python
components: Documentation
messages: 229574
nosy: docs at python, douglasnaphas
priority: normal
severity: normal
status: open
title: Bad link to packages specification in language reference 2.x sec 6.12
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 17 18:46:30 2014
From: report at bugs.python.org (James Goodwin)
Date: Fri, 17 Oct 2014 16:46:30 +0000
Subject: [New-bugs-announce] [issue22658] IMAP4 Example lacking host
	information
Message-ID: <1413564390.73.0.387636698685.issue22658@psf.upfronthosting.co.za>


New submission from James Goodwin:

The IMAP4 Example for Python 3.4 (Section 21.15.2) does not show the appropriate host information for the example to work.  

Suggested fix would be to change the line "M = imaplib.IMAP4()" to "M = imaplib.IMAP4('localhost')"  This will bring the example inline with the poplib example (Section 21.14.2).

----------
assignee: docs at python
components: Documentation
messages: 229581
nosy: James.Goodwin, docs at python
priority: normal
severity: normal
status: open
title: IMAP4 Example lacking host information
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 17 19:11:55 2014
From: report at bugs.python.org (Billy)
Date: Fri, 17 Oct 2014 17:11:55 +0000
Subject: [New-bugs-announce] [issue22659] SyntaxError in the configure_ctypes
Message-ID: <1413565915.5.0.655058689376.issue22659@psf.upfronthosting.co.za>


New submission from Billy:

Hi all,

I have a issue with the cross-compilation, here I let it:

  File "../src/setup.py", line 1849
    exec(f.read(), globals(), fficonfig)
SyntaxError: unqualified exec is not allowed in function 'configure_ctypes' it contains a nested function with free variables
make[1]: *** [sharedmods] Error 1

Who wants to help me, please

Best regards.

----------
components: Cross-Build
messages: 229584
nosy: bill9889
priority: normal
severity: normal
status: open
title: SyntaxError in the configure_ctypes
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 17 20:00:53 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 17 Oct 2014 18:00:53 +0000
Subject: [New-bugs-announce] [issue22660] Review ssl docs for security
	recommendations
Message-ID: <1413568853.31.0.251861459385.issue22660@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The current ssl documentation has a number of statements which may need updating, particularly wrt. SSLv3.

----------
assignee: docs at python
components: Documentation
messages: 229590
nosy: alex, christian.heimes, docs at python, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Review ssl docs for security recommendations
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct 17 22:08:25 2014
From: report at bugs.python.org (Tcll)
Date: Fri, 17 Oct 2014 20:08:25 +0000
Subject: [New-bugs-announce] [issue22661] WinXP concerns
Message-ID: <1413576505.87.0.0627962615597.issue22661@psf.upfronthosting.co.za>


New submission from Tcll:

About a week ago I read you were also dropping support for WinXP.

This will cause issues for me as I don't support newer Win (or should I say MS-RAT infested) OS's

I use linux now, but I still use XP as a testing interface for Windows.
(I will not install any newer windows as I prefer my freedom when MS pushes their button)

I hope this changes development aims to continue supporting WinXP...

if not, I can no longer consider python as cross-platform,
and will be forced to use an outdated cross-platform interpreter.


I'm still looking into how to disable the MS-RAT with python, as a friend of my friend has already done it.
my friend wasn't interested in asking him how when he did it, and getting in contact with him is quite difficult.

if (and only if) I can disable MS's RAT, I will gladly use a newer windows as a testing interface, so long as I can hack it like XP.
(I like doing cool things to my OS, which is what I mean by "hacking")

The reason I chose 2.7 for the python version is due to me being a PyOpenGL programmer and that the extension runs faster in 2.7

----------
components: Windows
messages: 229597
nosy: Tcll, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: WinXP concerns
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 17 22:44:33 2014
From: report at bugs.python.org (Kyle)
Date: Fri, 17 Oct 2014 20:44:33 +0000
Subject: [New-bugs-announce] [issue22662] subprocess.Popen.communicate
	causing local tty terminal	settings to change inconsistently
Message-ID: <1413578673.84.0.0347750412267.issue22662@psf.upfronthosting.co.za>


New submission from Kyle:

I'm not sure if this is a bash or Python issue.  I'm trying to run a command on a remote server, using the subprocess module.  I call ssh inside of subprocess.Popen(...).communicate(), like so:

output = subprocess.Popen(["/bin/env %s /usr/bin/ssh -ttt %s@%s -- %s;" % (env, user, host, command)], stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True).communicate()

Following the call to communicate(), my terminal settings are changed.  However, it's not always repeatable.  Sometimes it happens, and other times it does not.  When it does happen, I've noticed that the following tty options are ON prior to the command executing, and OFF afterwards (output from stty -a):
icrnl opost isig icanon echo echoe echok

Something with the communicate() call seems to cause the issue.  I don't actually have to print anything to the screen from Python for it to occur.

The problem goes away if I remove the "-t" option to ssh, however, I'm passing through the TERM environmental variable, and need -t to be set.  Because of this, I'm not sure if the problem is with the Python call, or something within Bash.

I've been able to repeat this on Ubuntu 13.10 running Python 2.7.5, and on Red Hat 6.4 running Python 2.6.6.

----------
messages: 229602
nosy: kflavin
priority: normal
severity: normal
status: open
title: subprocess.Popen.communicate causing local tty terminal settings to change inconsistently
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 17 23:44:47 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 17 Oct 2014 21:44:47 +0000
Subject: [New-bugs-announce] [issue22663] patchcheck alters content of .png
	files
Message-ID: <1413582287.26.0.112923859968.issue22663@psf.upfronthosting.co.za>


New submission from Robert Collins:

cpython.hg$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Getting the list of files that have been added/changed ... 448 files
Fixing whitespace ... 0 files
Fixing C file whitespace ... 5 files:
  Include/patchlevel.h
  Modules/_ctypes/callbacks.c
  Modules/_io/_iomodule.c
  Modules/_io/fileio.c
  Modules/_posixsubprocess.c
Fixing docs whitespace ... 1 file:
  Doc/tools/static/py.png
Docs modified ... yes
Misc/ACKS updated ... yes
Misc/NEWS updated ... yes
configure regenerated ... yes
pyconfig.h.in regenerated ... no

Note the change to py.png: its not a text filetohave its whitespace changed :/.

----------
messages: 229609
nosy: rbcollins
priority: normal
severity: normal
status: open
title: patchcheck alters content of .png files

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

From report at bugs.python.org  Sat Oct 18 00:25:41 2014
From: report at bugs.python.org (ppperry)
Date: Fri, 17 Oct 2014 22:25:41 +0000
Subject: [New-bugs-announce] [issue22664] IDLE: Standard output and error
	from multiprocessing	vanishes
Message-ID: <1413584741.24.0.854552509589.issue22664@psf.upfronthosting.co.za>


New submission from ppperry:

Note: not sure whether this issue belongs as a "behavior" or an "enhancement"

In IDLE:
>>> def print_a_test_string():
     print "test"

>>>print_a_test_string()
test
>>>threading.Thread(target=print_a_test_string).start()
test
>>>multiprocessing.Process(target=print_a_test_string).start()
[test is not said]
>>>
Running this example in the standard interpreter will print "test" all three times (in current thread, new thread, new process). (Acutally, I got an AttributeError and had to work aroung it using functools.partial(print, "test"))

OS: Windows XP

----------
components: IDLE, Library (Lib)
messages: 229611
nosy: ppperry
priority: normal
severity: normal
status: open
title: IDLE: Standard output and error from multiprocessing vanishes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Oct 18 07:14:13 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 18 Oct 2014 05:14:13 +0000
Subject: [New-bugs-announce] [issue22665] shutil.__all__ incomplete
Message-ID: <1413609253.18.0.504077117345.issue22665@psf.upfronthosting.co.za>


New submission from Martin Panter:

Continuing on from Issue 22247 (other out-of-date __all__ attributes), shutil.__all__ is missing (at least) get_terminal_size(), which was implemented for Issue 13609.

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

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

From report at bugs.python.org  Sat Oct 18 15:08:05 2014
From: report at bugs.python.org (Flavio Grossi)
Date: Sat, 18 Oct 2014 13:08:05 +0000
Subject: [New-bugs-announce] [issue22666] email.Header no encoding of
	unicode strings containing	newlines
Message-ID: <1413637685.41.0.262065905558.issue22666@psf.upfronthosting.co.za>


New submission from Flavio Grossi:

When trying to encode an email header with a newline in it, correct encoding is done only for strings and not for unicode strings.
In fact, for unicode strings, encoding is only done if a non ascii character is contained in it.

The attached patch should fix the problem.

Simple example to reproduce the problem:
>>> from email.Header import Header as H

# correctly encoded
>>> H('two\r\nlines', 'utf-8').encode()
'=?utf-8?q?two=0D=0Alines?='

# unicode string not encoded
>>> H(u'two\r\nlines', 'utf-8').encode()
'two\r\nlines'

# unicode string with non ascii chars, correctly encoded
>>> H(u'two\r\nlines and \xe0', 'utf-8').encode()
'=?utf-8?b?dHdvDQpsaW5lcyBhbmQgw6A=?='

----------
components: email
files: fix_email_header_encoding_uses_ascii_before_selected_charset.diff
keywords: patch
messages: 229640
nosy: barry, flavio, r.david.murray
priority: normal
severity: normal
status: open
title: email.Header no encoding of unicode strings containing newlines
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36959/fix_email_header_encoding_uses_ascii_before_selected_charset.diff

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

From report at bugs.python.org  Sat Oct 18 21:26:20 2014
From: report at bugs.python.org (Drekin)
Date: Sat, 18 Oct 2014 19:26:20 +0000
Subject: [New-bugs-announce] [issue22667] Incorrect evaluation of variables
	with names containing	supplementary characters
Message-ID: <1413660380.02.0.891262818036.issue22667@psf.upfronthosting.co.za>


New submission from Drekin:

>>> eval("\N{mathematical double-struck capital a}")
NameError: name 'A' is not defined
>>> A = 2
>>> eval("\N{mathematical double-struck capital a}")
2
>>> "\N{mathematical double-struck capital a}" == "A"
False

----------
components: Interpreter Core, Unicode
messages: 229653
nosy: Drekin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Incorrect evaluation of variables with names containing supplementary characters
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Oct 19 00:13:53 2014
From: report at bugs.python.org (Tom Flanagan)
Date: Sat, 18 Oct 2014 22:13:53 +0000
Subject: [New-bugs-announce] [issue22668] memoryview.format is corrupted due
	to dangling shared	pointer
Message-ID: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za>


New submission from Tom Flanagan:

When slicing or cloning a memoryview object that has been previously cast to change its format string, the new memoryview's format shares a pointer to the parent's format string, which may be deleted at any time.

This manifests as a corrupt format when using the new memoryview object, causing crashes or unexpected behavior.

Tested on:
Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:45:13) [MSC v.1600 64 bit (AMD64)] on win32
Python 3.5.0a0 (default:cb8606fc84df, Oct 18 2014, 14:55:44) [GCC 4.8.2] on linux

----------
components: Interpreter Core
files: memoryview_bug.py
messages: 229664
nosy: Knio, pitrou, skrah
priority: normal
severity: normal
status: open
title: memoryview.format is corrupted due to dangling shared pointer
type: crash
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file36965/memoryview_bug.py

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

From report at bugs.python.org  Sun Oct 19 02:37:48 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Oct 2014 00:37:48 +0000
Subject: [New-bugs-announce] [issue22669] Test_venv fails when _ctypes is
	not available.
Message-ID: <1413679068.77.0.788594007735.issue22669@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

For whatever reason, AMD 64 Open Indiana ('stable' buildbot #3) is not building ctypes. test_venv fails with
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/test/test_venv.py", line 356, in test_with_pip
    with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmp644tt7bi/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/test/test_venv.py", line 362, in test_with_pip
    self.fail(msg.format(exc, details))
AssertionError: Command '['/tmp/tmp644tt7bi/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/ensurepip/__main__.py", line 4, in <module>
    ensurepip._main()
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 209, in _main
    default_pip=args.default_pip,
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 116, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/ensurepip/__init__.py", line 40, in _run_pip
    import pip
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/__init__.py", line 9, in <module>
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/log.py", line 9, in <module>
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/__init__.py", line 2, in <module>
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/initialise.py", line 5, in <module>
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/ansitowin32.py", line 6, in <module>
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/winterm.py", line 2, in <module>
  File "/tmp/tmp7od_thjv/pip-1.5.6-py2.py3-none-any.whl/pip/_vendor/colorama/win32.py", line 7, in <module>
  File "/export/home/buildbot/64bits/3.4.cea-indiana-amd64/build/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: No module named '_ctypes'

Since this is not a failure of ensurepip, I think this should instead be a test skip.  The easiest thing would be to do what you did with ssl.

----------
assignee: vinay.sajip
components: Library (Lib), Tests
messages: 229667
nosy: terry.reedy, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: Test_venv fails when _ctypes is not available.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Oct 19 10:30:34 2014
From: report at bugs.python.org (Samuel)
Date: Sun, 19 Oct 2014 08:30:34 +0000
Subject: [New-bugs-announce] [issue22670] wrong site-package installation
	even if correct libdir	passed
Message-ID: <1413707434.42.0.0466782880173.issue22670@psf.upfronthosting.co.za>


New submission from Samuel:

Today I compile try Python 3.4.2 on slackware-current in this way

./configure \
  --prefix=/usr \
  --libdir=/usr/lib64 \
  --mandir=/usr/man \
  --with-threads \
  --enable-ipv6 \
  --enable-shared \

make \
  LIBDIR=/usr/lib64 \
  SCRIPTDIR=/usr/lib64

make install

like slackbuild say.
But site package directory are under /usr/lib/python3.4/site-packages
and not under /usr/lib64/python3.4/site-packages, which contanin only a README file with

This directory exists so that 3rd party packages can be installed
here.  Read the source for site.py for more details.

----------
components: Cross-Build
messages: 229675
nosy: Samuel88
priority: normal
severity: normal
status: open
title: wrong site-package installation even if correct libdir passed
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Oct 19 11:35:52 2014
From: report at bugs.python.org (gigaplastik)
Date: Sun, 19 Oct 2014 09:35:52 +0000
Subject: [New-bugs-announce] [issue22671] Typo in class io.BufferedIOBase
	docs
Message-ID: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>


New submission from gigaplastik:

The online documentation for class io.BufferedIOBase states the following:

"Besides, the read() method does not have a default implementation that defers to readinto()."

According to the documentation for class io.RawIOBase (which the statement compares with) read() method actually defers to readall(), NOT readinto() as misleadingly stated.
The same typo is present in help('io.BufferedIOBase') output and, very likely, in all 3.X line docs for this class.

----------
assignee: docs at python
components: Documentation
messages: 229677
nosy: docs at python, gigaplastik
priority: normal
severity: normal
status: open
title: Typo in class io.BufferedIOBase docs
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Oct 19 20:10:15 2014
From: report at bugs.python.org (Jacopo Nespolo)
Date: Sun, 19 Oct 2014 18:10:15 +0000
Subject: [New-bugs-announce] [issue22672] float arguments in scientific
	notation not supported by	argparse
Message-ID: <1413742215.74.0.884028294997.issue22672@psf.upfronthosting.co.za>


New submission from Jacopo Nespolo:

Argparse fails to recognise negative numbers in scientific notation as valid numbers.

Example:
Suppose the program test.py has this option.
    par.add_argument('-a', type=float)

then './test.py -a -1e5' will fail, as well as -1.0e-4, -.5E+4 and variations thereof.
Furthermore, at the current state, it seems that argparse does not recognize -1. as a valid float either.

I tried to hack argparse.py myself, and I believe the patch attached should fix this issue. The base version of argparse.py is the one from Python 3.4.2 as found in Debian Sid.

The modified regular expression seemed to behave correctly in all test cases I could come up with.

----------
components: Library (Lib)
files: argparse.patch
keywords: patch
messages: 229689
nosy: jnespolo
priority: normal
severity: normal
status: open
title: float arguments in scientific notation not supported by argparse
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file36972/argparse.patch

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

From report at bugs.python.org  Sun Oct 19 21:00:58 2014
From: report at bugs.python.org (Aaron Myles Landwehr)
Date: Sun, 19 Oct 2014 19:00:58 +0000
Subject: [New-bugs-announce] [issue22673] Incorrect fileno for CONOUT$ /
	stdout
Message-ID: <1413745258.02.0.518044907787.issue22673@psf.upfronthosting.co.za>


New submission from Aaron Myles Landwehr:

If I execute the following code, the file descriptor for CONOUT$ has a fileno != 1. With CONIN$ the fileno != 0. Similar code in another language such as perl produces the desired results. 

sys.stdout.close();
sys.stdout = open("CONOUT$", "w");
sys.stderr.write(str(sys.stdout.fileno()));

I believe it has to do with the fact that stdout is an object in python and in perl or c, you are operating directly on the stream ala freopen() or the equivalent.

----------
components: IO
messages: 229690
nosy: snaphat
priority: normal
severity: normal
status: open
title: Incorrect fileno for CONOUT$ / stdout
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Oct 19 21:12:54 2014
From: report at bugs.python.org (Dolda2000)
Date: Sun, 19 Oct 2014 19:12:54 +0000
Subject: [New-bugs-announce] [issue22674] strsignal() missing from signal
	module
Message-ID: <1413745974.08.0.599782045243.issue22674@psf.upfronthosting.co.za>


New submission from Dolda2000:

Like it says on the tin, it would be nice if strsignal(3) were added to the signal module.

----------
components: Library (Lib)
messages: 229691
nosy: Dolda2000
priority: normal
severity: normal
status: open
title: strsignal() missing from signal module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 20 08:34:02 2014
From: report at bugs.python.org (Ricordisamoa)
Date: Mon, 20 Oct 2014 06:34:02 +0000
Subject: [New-bugs-announce] [issue22675] typo in argparse.py
Message-ID: <1413786842.34.0.621313425932.issue22675@psf.upfronthosting.co.za>


New submission from Ricordisamoa:

It should be "no help" instead of "ho nelp".

----------
components: Library (Lib)
files: typo.patch
keywords: patch
messages: 229714
nosy: Ricordisamoa
priority: normal
severity: normal
status: open
title: typo in argparse.py
type: enhancement
Added file: http://bugs.python.org/file36976/typo.patch

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

From report at bugs.python.org  Mon Oct 20 13:38:22 2014
From: report at bugs.python.org (kbengine)
Date: Mon, 20 Oct 2014 11:38:22 +0000
Subject: [New-bugs-announce] [issue22676] _pickle.c
Message-ID: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za>


New submission from kbengine:

I have an application, the use of Python3.2.3 development.
When I upgrade to Python3.4.2, found a problem.

I have an extended "xxx.c (c-python)" module, I call pickle to serialize and deserialize, _pickle.c calls the whichmodule to look for this module, The final will be to find the module from sys.modules.

But probably there are 200 elements in sys.modules, Use the "obj = getattribute (module, global_name, allow_qualname)" to try to get the object:

static PyObject *
getattribute(PyObject *obj, PyObject *name, int allow_qualname) {
        ...
        ...
        ...

        tmp = PyObject_GetAttr(obj, subpath);
        Py_DECREF(obj);
 
// There will be hundreds of times to return to NULL
// There will be hundreds of times calls "PyErr_Format           
// (PyExc_AttributeError," Can't get attribute%R on%R ", name, obj);"
// This process will lead to hundreds of calls to "moduleobject.c-
// module_repr(PyModuleObject *m)".

// So I frequently call pickle.dumps CPU consumption sharply.

        if (tmp == NULL) {
            if (PyErr_ExceptionMatches(PyExc_AttributeError)) {
                PyErr_Clear();


                PyErr_Format(PyExc_AttributeError,
                             "Can't get attribute %R on %R", name, obj);
            }
            Py_DECREF(dotted_path);
            return NULL;
        }
       ...
       ...
}

------------------------------------------------------
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      315    0.001    0.000    0.004    0.000 <frozen importlib._bootstrap>:690(_module_repr)




I went wrong?
Look forward to answer, thanks!

----------
components: Extension Modules
files: 20141020193031.jpg
messages: 229723
nosy: kbengine
priority: normal
severity: normal
status: open
title: _pickle.c
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file36980/20141020193031.jpg

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

From report at bugs.python.org  Mon Oct 20 14:00:01 2014
From: report at bugs.python.org (Ahmad El-Komey)
Date: Mon, 20 Oct 2014 12:00:01 +0000
Subject: [New-bugs-announce] [issue22677] icon not loaded
Message-ID: <1413806401.64.0.304134959214.issue22677@psf.upfronthosting.co.za>


New submission from Ahmad El-Komey:

Versions 2.7.7 and 2.7.8 (with both builds, 86 and 64 builds) have some strange things that is different from other versions:
1. The tk icon of the IDLE is not loaded. The icon loaded is as this one: Python27\Lib\idlelib\Icons\idle.ico
and it should be like the one found in Python27\Lib\idlelib\Icons\tk.gif

2. I cannot pin a shortcut to the program! This is not the case with other python versions.

----------
components: IDLE, Installation, Windows
messages: 229724
nosy: Ahmad.El-Komey, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: icon not loaded
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 20 18:27:15 2014
From: report at bugs.python.org (Mathieu Bridon)
Date: Mon, 20 Oct 2014 16:27:15 +0000
Subject: [New-bugs-announce] [issue22678] An OSError subclass for "no space
	left on device" would	be nice
Message-ID: <1413822435.2.0.235544061908.issue22678@psf.upfronthosting.co.za>


New submission from Mathieu Bridon:

I found myself writing the following code the other day:

        try:
            os.mkdir(path)
            
        except PermissionError:
            do_something()

        except FileExistsError:
            do_something_else()

        except FileNotFoundError:
            do_yet_another_thing()

        except OSError as e:
            import errno
            if e.errno == errno.ENOSPC:
                and_do_one_more_different_thing()

            else:
                raise e

The OSError subclasses in Python 3 are amazing, I love them.

I just wish there'd be more of them. :)

----------
components: Library (Lib)
messages: 229729
nosy: bochecha
priority: normal
severity: normal
status: open
title: An OSError subclass for "no space left on device" would be nice
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 20 18:49:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Oct 2014 16:49:38 +0000
Subject: [New-bugs-announce] [issue22679] Add encodings of supported in
	glibc locales
Message-ID: <1413823778.04.0.286011441147.issue22679@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are 6 encodings used in supported by glibc locales:

ARMSCII-8 - Armenian encoding
EUC-TW - Taiwan encoding in EUC family
GEORGIAN-PS - Georgian encoding
KOI8-T - Tajik encoding in KOI family
RK1048 - Kazakh variation of CP1251
TCVN5712-1 - Vietnam encoding

All these encodings are rare nowadays, but the fact that they are supported as encoding of official glibc locales means that they were used in some places in some time and there are some documents in these encodings. May be they are used even nowadays. I think it is worth to add support of all this encodings in Python.

This is a meta-issue. There are requests for support of GEORGIAN-PS (issue19459) and TCVN5712-1 (issue21081).

----------
components: Library (Lib)
messages: 229730
nosy: haypo, lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add encodings of supported in glibc locales
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 20 19:14:21 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Oct 2014 17:14:21 +0000
Subject: [New-bugs-announce] [issue22680] unittest discovery is fragile
Message-ID: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I just got the following traceback when trying discover without 3.5. It runs fine under 3.4...

$ ~/cpython/default/python -m unittest discover -v
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/antoine/cpython/default/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/antoine/cpython/default/Lib/unittest/__main__.py", line 18, in <module>
    main(module=None)
  File "/home/antoine/cpython/default/Lib/unittest/main.py", line 93, in __init__
    self.runTests()
  File "/home/antoine/cpython/default/Lib/unittest/main.py", line 244, in runTests
    self.result = testRunner.run(self.test)
  File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 168, in run
    test(result)
  File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 87, in __call__
    return self.run(*args, **kwds)
  File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 125, in run
    test(result)
  File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 87, in __call__
    return self.run(*args, **kwds)
  File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 125, in run
    test(result)
  File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 87, in __call__
    return self.run(*args, **kwds)
  File "/home/antoine/cpython/default/Lib/unittest/suite.py", line 125, in run
    test(result)
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 625, in __call__
    return self.run(*args, **kwds)
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 553, in run
    result.startTest(self)
  File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 54, in startTest
    self.stream.write(self.getDescription(test))
  File "/home/antoine/cpython/default/Lib/unittest/runner.py", line 47, in getDescription
    return '\n'.join((str(test), doc_first_line))
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 1354, in __str__
    self._testFunc.__name__)
AttributeError: 'str' object has no attribute '__name__'

----------
components: Library (Lib)
messages: 229731
nosy: ezio.melotti, michael.foord, pitrou, rbcollins
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest discovery is fragile
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 20 19:49:30 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Oct 2014 17:49:30 +0000
Subject: [New-bugs-announce] [issue22681] Add support of KOI8-T encoding
Message-ID: <1413827370.97.0.876918138857.issue22681@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

KOI8-T is Tajik encoding partially compatible with KOI8-R. This is default encoding of Tajik locale tg_TJ in glibc (but in X11 locale.alias file it is KOI8-C, issue20087).

Proposed patch adds support for this encoding. I have not found official mapping of KOI8-T and have used a table from Apple's implementation of libiconv. It matches a table in Wikipedia [2] and GNU iconv.

[1] http://www.opensource.apple.com/source/libiconv/libiconv-4/libiconv/tests/KOI8-T.TXT
[2] https://ru.wikipedia.org/wiki/???-8 (Russian)

----------
components: Library (Lib)
messages: 229739
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support of KOI8-T encoding
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Oct 20 22:21:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Oct 2014 20:21:16 +0000
Subject: [New-bugs-announce] [issue22682] Add support of KZ1048 (RK1048)
	encoding
Message-ID: <1413836476.72.0.167337994722.issue22682@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

KZ1048 is Kazakh encoding based on CP1251 (Windows Cyrillic codepage). It is standardized by Unicode [1] and IANA [2]. It is also known as STRK1048-2002 (by the name of original Kazakh standard) and RK1048 (used in glibc). It is default encoding of Kazakh locale kk_KZ in glibc.

Proposed patch adds support for this encoding.

[1] ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MISC/KZ1048.TXT
[2] https://www.iana.org/assignments/charset-reg/KZ-1048

----------
components: Library (Lib)
messages: 229741
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support of KZ1048 (RK1048) encoding
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 21 09:23:12 2014
From: report at bugs.python.org (Paul Ianas)
Date: Tue, 21 Oct 2014 07:23:12 +0000
Subject: [New-bugs-announce] [issue22683] bisect index out of bounds issue
Message-ID: <1413876192.76.0.889942882253.issue22683@psf.upfronthosting.co.za>


New submission from Paul Ianas:

The precondition for all the bisect functions is implemented like this:

    if lo < 0:
        raise ValueError('lo must be non-negative')
    if hi is None:
        hi = len(a)

Now, of course, if hi is given, and hi >= 2 * len(a), then we get an IndexError. In case hi < 0, we always get 0 as a result (even if the element is there).

I think it would be better to treat the hi in the precondition in the same way as the lo parameter: that means, raise a ValueError in case hi has an illegal value.

Disclaimer: of course, it makes no sense to give an illegal argument to that function; still, since lo is treated against illegal values, maybe it's better to do the same for hi.

At the same time, maybe moving the precondition code in a separate function (which raises a ValueError in case precondition is not met) makes more sense, for not repeating the same code in all bisect functions.

A small snippet which reproduces this:

from bisect import bisect_left

a = [1, 2, 3, 4]
idx = bisect_left(a, 2, 0, 10)  # 10 > 2 * 4
print(idx)

----------
components: Library (Lib)
messages: 229750
nosy: Paul.Ianas
priority: normal
severity: normal
status: open
title: bisect index out of bounds issue
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Oct 21 14:29:26 2014
From: report at bugs.python.org (Pas)
Date: Tue, 21 Oct 2014 12:29:26 +0000
Subject: [New-bugs-announce] [issue22684] message.as_bytes() produces
	recursion depth exceeded
Message-ID: <1413894566.0.0.84714989702.issue22684@psf.upfronthosting.co.za>


New submission from Pas:

Please see the attached traceback (or this http://pastebin.com/WYinRGie for fancy colors).

It depends on message size, we're trying to send Multipart MIME messages (a PDF attached, that has an image embedded).

After editing flask_mail.py to use the fallback ( message().as_string().encode(self.charset or 'utf-8') ) things work again.

If anyone could help confirm if this is a bug, or help me understand how I misuse the library, I'd be grateful. Thanks!

----------
components: email
files: py34-email.message.as_bytes-recursion-depth-exceeded.txt
messages: 229762
nosy: barry, pas, r.david.murray
priority: normal
severity: normal
status: open
title: message.as_bytes() produces recursion depth exceeded
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file36988/py34-email.message.as_bytes-recursion-depth-exceeded.txt

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

From report at bugs.python.org  Tue Oct 21 14:33:41 2014
From: report at bugs.python.org (wabu)
Date: Tue, 21 Oct 2014 12:33:41 +0000
Subject: [New-bugs-announce] [issue22685] memory leak: no transport for
	pipes by	create_subprocess_exec/shell
Message-ID: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za>


New submission from wabu:

using `p = create_subprocess_exec(..., stdout=subprocess.PIPE, limit=...)`, 
p.stdout has not transport set, so the underlying protocol is unable to pause the reading of the transport, resulting in high memory usage when slowly consuming input from p.stdout, even if the limit parameter is passed. 

A workaround is to set the transport manually after creating the subprocess:
`p.stdout.set_transport(p._transport.get_pipe_transport(1))`, but this should happen inside the create_subprocess call.

----------
components: asyncio
messages: 229763
nosy: gvanrossum, haypo, wabu, yselivanov
priority: normal
severity: normal
status: open
title: memory leak: no transport for pipes by create_subprocess_exec/shell
versions: Python 3.4

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

From report at bugs.python.org  Tue Oct 21 17:27:49 2014
From: report at bugs.python.org (FH)
Date: Tue, 21 Oct 2014 15:27:49 +0000
Subject: [New-bugs-announce] [issue22686] random.randint does not include
	endpoint
Message-ID: <1413905269.07.0.265786937955.issue22686@psf.upfronthosting.co.za>


New submission from FH:

Upon inspection, random.randint(a,b) does not include the endpoint b, contrary to documentation, and contrary to the argumentation in Issue7009.

To see this, run e.g.
sum(np.random.randint(0,1,1000))

which will return 0 repeatedly (statistically very unlikely). I tried both on Kubuntu 14.04/python 2.7 and pythoneverwhere.org

Within random.py, randint is (in both 2.7 and 3.5) implemented as 

def randint(self, a, b):
    """Return random integer in range [a, b], including both end points.
    """
    return self.randrange(a, b+1)

which falsely seems to include the endpoint (as randrange excludes the endpoint). However, upon running it does not.

----------
components: Library (Lib)
messages: 229765
nosy: georg.brandl, orsenthil, sciencebuggy
priority: normal
severity: normal
status: open
title: random.randint does not include endpoint
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Oct 21 18:45:26 2014
From: report at bugs.python.org (Piotr Engelking)
Date: Tue, 21 Oct 2014 16:45:26 +0000
Subject: [New-bugs-announce] [issue22687] horrible performance of
	textwrap.wrap() with a long word
Message-ID: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>


New submission from Piotr Engelking:

Wrapping a paragraph containing a long word takes a lot of time:

$ time python3 -c 'import textwrap; textwrap.wrap("a" * 2 ** 16)'

real	3m14.923s
user	3m14.792s
sys	0m0.016s
$

A straightforward replacement is 5000 times faster:

$ time python3 -c '("".join(x) for x in zip(*[iter("a" * 2 ** 16)] * 70))'

real	0m0.053s
user	0m0.032s
sys	0m0.016s
$

Tested on Debian with python3.4 3.4.2-1 and python2.7 2.7.8-10.

----------
messages: 229768
nosy: inkerman
priority: normal
severity: normal
status: open
title: horrible performance of textwrap.wrap() with a long word
type: performance
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  Tue Oct 21 19:21:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Oct 2014 17:21:33 +0000
Subject: [New-bugs-announce] [issue22688] Use the subprocess module in the
	uuid module
Message-ID: <1413912093.27.0.12896372872.issue22688@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a proposition (msg229163) to use the subprocess module instead of os.popen() in the uuid module.

I hesitate how classify this issue (behavior, security or enhancement) and for which versions target it. May be this is a dependency of issue17293.

----------
components: Library (Lib)
messages: 229769
nosy: haypo, neologix, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Use the subprocess module in the uuid module

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

From report at bugs.python.org  Tue Oct 21 23:03:44 2014
From: report at bugs.python.org (Aidan Hobson Sayers)
Date: Tue, 21 Oct 2014 21:03:44 +0000
Subject: [New-bugs-announce] [issue22689] Posix getenv makes no guarantee of
	lifetime of returned	string
Message-ID: <1413925424.96.0.804566099113.issue22689@psf.upfronthosting.co.za>


New submission from Aidan Hobson Sayers:

Posix says the following on the subject of getenv:

> The returned string pointer might be invalidated or the string content might be overwritten by a subsequent call to getenv()

(http://pubs.opengroup.org/onlinepubs/9699919799/functions/getenv.html)

Unfortunately, in Modules/getpath.c:

static void
calculate_path(void)
{
[...]
    char *_rtpypath = Py_GETENV("PYTHONPATH"); /* XXX use wide version on Windows */
    wchar_t *rtpypath = NULL;
    wchar_t *home = Py_GetPythonHome();
    char *_path = getenv("PATH");

So 3 potential getenv calls in quick succession, meaning _rtpypath and home can become junk before they get used and Python crashes before it can start up (it becomes unable to find the site module).

Unfortunately it looks like the assumption that getenv pointers will remain safe forever is used in a few places in python.

Explicit notes on the correct use of getenv: https://www.securecoding.cert.org/confluence/display/seccode/ENV34-C.+Do+not+store+pointers+returned+by+certain+functions

Someone's apparently seen this before (but didn't report it?) - http://sourceforge.net/p/edk2/mailman/edk2-devel/thread/66BD57653246D24E9698B0A6509545A86DDB863C at ORSMSX109.amr.corp.intel.com/

----------
components: Interpreter Core
messages: 229788
nosy: aidanhs
priority: normal
severity: normal
status: open
title: Posix getenv makes no guarantee of lifetime of returned string
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 21 23:37:22 2014
From: report at bugs.python.org (Sigz)
Date: Tue, 21 Oct 2014 21:37:22 +0000
Subject: [New-bugs-announce] [issue22690] importing Gtk breaks strptime
Message-ID: <1413927442.61.0.0173786511111.issue22690@psf.upfronthosting.co.za>


New submission from Sigz:

I usually convert date string to time with strptime formating. I noticed importing Gtk breaks strptime parsing for abbreviated month name and weekday name :

>>> import time
>>> time.strptime("Mon, 20 Oct 2014 08:00:32 +0000", "%a, %d %b %Y %H:%M:%S %z")
time.struct_time(tm_year=2014, tm_mon=10, tm_mday=20, tm_hour=8, tm_min=0, tm_sec=32, tm_wday=0, tm_yday=293, tm_isdst=-1)
>>> from gi.repository import Gtk
>>> time.strptime("Mon, 20 Oct 2014 08:00:32 +0000", "%a, %d %b %Y %H:%M:%S %z")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/_strptime.py", line 494, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "/usr/lib/python3.4/_strptime.py", line 337, in _strptime
    (data_string, format))
ValueError: time data 'Mon, 20 Oct 2014 08:00:32 +0000' does not match format '%a, %d %b %Y %H:%M:%S %z'
>>> 

Is there a workaround for Gtk + time ?

----------
components: Extension Modules
messages: 229794
nosy: sigzegv
priority: normal
severity: normal
status: open
title: importing Gtk breaks strptime
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 22 07:08:23 2014
From: report at bugs.python.org (James)
Date: Wed, 22 Oct 2014 05:08:23 +0000
Subject: [New-bugs-announce] [issue22691] A Better Help File
Message-ID: <1413954503.13.0.720826050231.issue22691@psf.upfronthosting.co.za>


New submission from James:

Just the General Help that is in Python, doesn't really help.  Here's what would help, if every Module, had an example in code of how it was used instead of the Trees.  I mean, word trees, well that's what the writing reminds me of, is word trees like you'd produce in an English class.  But, a short working piece of code, does allot more for me, than a lecture, you'd have to take a course to understand because of it's use of it's own writing style.  It doesn't help to type help() and hit enter.

----------
assignee: docs at python
components: Documentation
messages: 229796
nosy: FCK, docs at python
priority: normal
severity: normal
status: open
title: A Better Help File
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 22 08:32:44 2014
From: report at bugs.python.org (James)
Date: Wed, 22 Oct 2014 06:32:44 +0000
Subject: [New-bugs-announce] [issue22692] Problems with Python's help()
Message-ID: <3A83EEE4841F41009AD2DFC3F6120FAC@JamesPCX>


New submission from James:

Hello,

    I really think that Microsoft?s last release of Quick Basic 4.5 really had the ultimate of all help files.  Here?s why, you could cut and copy the code to the program you were working on, and then alter it to your program.  It was one of the nicer things you could do with the help file.  Because, tearing down the working example, usually just means customizing it to your needs, or wants.

    You have several randomizing routines right?  How do you use these modules?  I have to say, looking at the help, should work for anyone that can?t leave it alone and learn to program if that?s what they want to do.  I was always a hunt an pick programmer.  I rather read through the help files and see what it can do, and then figure out what I want to do.  There?s no reason anyone couldn?t be self taught via reading the help file but, we should at least want it to work that way.

    It?s fun to be on a ship with men.

James.

----------
messages: 229798
nosy: FCK
priority: normal
severity: normal
status: open
title: Problems with Python's help()

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

From report at bugs.python.org  Wed Oct 22 08:51:41 2014
From: report at bugs.python.org (James)
Date: Wed, 22 Oct 2014 06:51:41 +0000
Subject: [New-bugs-announce] [issue22694] The help file issue I'm having.
Message-ID: <732FBD5F227C4291A625E1BC62FDDBC8@JamesPCX>


New submission from James:

Hello,

    Now, I really want you to think about the hunt and pick method of programming and learning how to program.  Being self taught, isn?t something that can happen unless, the authors of the software want people to learn how to use it.  Help files, are not typically designed that way but, there?s an easy way to design them that way.  Some of the strange notation that requires a course in computer science, is not what anybody needs to program a computer.  The computer science method of explaining computer programming languages is all literally politics, or legal terms.  Let?s not make it harder than it really is, and keep both politics and legal terms out of this when in reality we just need a few terms to be define a function subroutine or suite of utilities and tools.  There?s science the right way, and we name things because they?ve never been named before, and then there?s politics, were we just talk too much about one dumb thing, or legal terms, and just re-invent the language around how many different ways we are capable of explaining the same damn thing differently, or making a new word out of lecture of human social situations and by defining one human social situation, come up with one legal term.

    People work best one way, they learn by example.

James.

----------
messages: 229800
nosy: FCK
priority: normal
severity: normal
status: open
title: The help file issue I'm having.

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

From report at bugs.python.org  Wed Oct 22 09:50:21 2014
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9C40Lkg0JzQsNC60LDRgNC+0LI=?=)
Date: Wed, 22 Oct 2014 07:50:21 +0000
Subject: [New-bugs-announce] [issue22695] open() declared deprecated in
	python 3 docs
Message-ID: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>


New submission from ??????? ???????:

Python 3 open() documentation ( https://docs.python.org/3/library/functions.html#open ) is probably broken. Here is what one can see at the end of open() description:
"...
Deprecated since version 3.4, will be removed in version 4.0.

The 'U' mode."

Reader may assume the open() function is what will be removed, which is wrong AFAIK

----------
assignee: docs at python
components: Documentation
messages: 229802
nosy: docs at python, ???????.???????
priority: normal
severity: normal
status: open
title: open() declared deprecated in python 3 docs
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Oct 22 14:20:53 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Oct 2014 12:20:53 +0000
Subject: [New-bugs-announce] [issue22696] Add a function to know about
	interpreter shutdown
Message-ID: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I propose to add a new function sys.shutting_down() (name debatable) returning True if the interpreter is currently shutting down.

This would be a function so that you can bind it and avoid having it wiped at shutdown :-)

----------
components: Interpreter Core
messages: 229817
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a function to know about interpreter shutdown
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 22 15:59:27 2014
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Wed, 22 Oct 2014 13:59:27 +0000
Subject: [New-bugs-announce] [issue22697] Deadlock with writing to stderr
	from forked process
Message-ID: <1413986367.14.0.352107167307.issue22697@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian:

Example code:

import os
import sys
import threading


def run():
    sys.stderr.write("in parent thread\n")

threading.Thread(target=run).start()
pid = os.fork()
if pid:
    os.waitpid(pid, 0)
else:
    sys.stderr.write("in child\n")


To run:  while python3 deadlock.py; do; done        

Note: does not reproduce if ran with `python -u` (unbuffered)

----------
components: IO, Interpreter Core
messages: 229825
nosy: ionel.mc
priority: normal
severity: normal
status: open
title: Deadlock with writing to stderr from forked process
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Oct 22 17:12:03 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Oct 2014 15:12:03 +0000
Subject: [New-bugs-announce] [issue22698] Add constants for ioctl request
	codes
Message-ID: <1413990723.24.0.56994728842.issue22698@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It would be useful to expose ioctl request codes (Linux specific?) [1] at Python level.

In particular this will allow to determine MAC address in uuid at Python level without using ctypes or calling external programs. [2]

[1] http://man7.org/linux/man-pages/man2/ioctl_list.2.html
[2] http://code.activestate.com/recipes/439094-get-the-ip-address-associated-with-a-network-inter/

----------
components: Extension Modules
messages: 229827
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add constants for ioctl request codes
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Oct 22 17:49:06 2014
From: report at bugs.python.org (Billy)
Date: Wed, 22 Oct 2014 15:49:06 +0000
Subject: [New-bugs-announce] [issue22699] cross-compilation of Python3.4
Message-ID: <1413992946.14.0.956103683321.issue22699@psf.upfronthosting.co.za>


New submission from Billy:

Who knows to cross-compile Python 3.4?

----------
messages: 229828
nosy: bill9889
priority: normal
severity: normal
status: open
title: cross-compilation of Python3.4
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 22 19:27:18 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Oct 2014 17:27:18 +0000
Subject: [New-bugs-announce] [issue22700] email's header_value_parser
	missing defect report for	'abc@xyz.c:om'
Message-ID: <1413998838.36.0.0996397027801.issue22700@psf.upfronthosting.co.za>


New submission from R. David Murray:

The example address in the title results in an 'invalid-header' object, but none of the sub-parts have an attached defect.  The 'misplaced-special' sub-part should have an associated Defect in its .defects attribute.

----------
components: email
messages: 229829
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email's header_value_parser missing defect report for 'abc at xyz.c:om'
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Oct 22 20:55:23 2014
From: report at bugs.python.org (Michael Kuss)
Date: Wed, 22 Oct 2014 18:55:23 +0000
Subject: [New-bugs-announce] [issue22701] Write unescaped unicode characters
	(Japanese, Chinese, etc) in JSON module when "ensure_ascii=False"
Message-ID: <1414004123.6.0.971106689488.issue22701@psf.upfronthosting.co.za>


New submission from Michael Kuss:

When running the following:

>> json.dump(['name': "??"], myfile.json, indent=4, separators=(',', ': '), ensure_ascii=False)

the function escapes the unicode, even though I have explicitly asked to not force to ascii:
\u6E2F\u533A

By changing "__init__.py" such that the fp.write call encodes the text as utf-8, the output json file displays the human-readable text required (see below).


OLD (starting line 167):

if (not skipkeys and ensure_ascii and
        check_circular and allow_nan and
        cls is None and indent is None and separators is None and
        encoding == 'utf-8' and default is None and not kw):
        iterable = _default_encoder.iterencode(obj)
    else:
        if cls is None:
            cls = JSONEncoder
        iterable = cls(skipkeys=skipkeys, ensure_ascii=ensure_ascii,
            check_circular=check_circular, allow_nan=allow_nan, indent=indent,
            separators=separators, encoding=encoding,
            default=default, **kw).iterencode(obj)
for chunk in iterable:
    fp.write(chunk)


NEW:

if (not skipkeys and ensure_ascii and
        check_circular and allow_nan and
        cls is None and indent is None and separators is None and
        encoding == 'utf-8' and default is None and not kw):
        iterable = _default_encoder.iterencode(obj)
        for chunk in iterable:
            fp.write(chunk)
    else:
        if cls is None:
            cls = JSONEncoder
        iterable = cls(skipkeys=skipkeys, ensure_ascii=ensure_ascii,
            check_circular=check_circular, allow_nan=allow_nan, indent=indent,
            separators=separators, encoding=encoding,
            default=default, **kw).iterencode(obj)
        for chunk in iterable:
            fp.write(chunk.encode('utf-8'))

----------
components: Extension Modules, Unicode
messages: 229830
nosy: Michael.Kuss, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Write unescaped unicode characters (Japanese, Chinese, etc) in JSON module when "ensure_ascii=False"
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Oct 23 00:37:21 2014
From: report at bugs.python.org (Van Ly)
Date: Wed, 22 Oct 2014 22:37:21 +0000
Subject: [New-bugs-announce] [issue22702] to improve documentation for
	join() (str method)
Message-ID: <1414017441.98.0.187335340973.issue22702@psf.upfronthosting.co.za>


New submission from Van Ly:

This issue should go in the Documentation component but that is not an option in the issue tracker. 

Suggestion to improve documentation for join() (str method). Applies to versions 2.7.5, 3.3.6, 3.5.0a0.

--quote

str.join(iterable)

Returns a string. Uses the string str to join strings from
iterable. Raises TypeError for non-string found in iterable including
object of bytes.

>>> # the iterable consists of number
>>> try:
>>>         print "-".join([0, 1, 2, 3])
>>> except TypeError:
>>>         print "A non-string is found in the iterable."
A non-string is found in the iterable.

>>> # the iterable consists of string
>>> try:
>>>         print ", ".join(["x", "y", "z", "0", "1", "2", "3"])
>>>         print " - ".join(["x", "y", "z", "0", "1", "2", "3"])
>>>         print " + ".join(["x", "y", "z", "0", "1", "2", "3"])
>>> except TypeError:
>>>         print "A non-string is found in the iterable."
x, y, z, 0, 1, 2, 3
x - y - z - 0 - 1 - 2 - 3
x + y + z + 0 + 1 + 2 + 3

--quote--

----------
components: Macintosh
files: documentationForJoin.rtf
messages: 229841
nosy: ned.deily, ronaldoussoren, vy0123
priority: normal
severity: normal
status: open
title: to improve documentation for join() (str method)
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.5
Added file: http://bugs.python.org/file36995/documentationForJoin.rtf

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

From report at bugs.python.org  Thu Oct 23 02:16:55 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Oct 2014 00:16:55 +0000
Subject: [New-bugs-announce] [issue22703] Idle Code Context: separate
	changing current and future	editors
Message-ID: <1414023415.32.0.701318253357.issue22703@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

#17535, msg225416, 2014-08-16 17:18 describes the current double behavior of Options / Code context.  It toggles the code-context state of both the current editor and the default for future editors.  The two toggles can be in opposite directions.  The check mark absent or present somewhat surprisingly indicates the initial state of future windows, not of the current window.

The consensus seemed to be that we should change to having Code Context toggle the current window only, with the checkmark indicating its current state.  The default for future windows will be left to the extension configuration, which will be easy to change with the new dialog, #3068.

----------
assignee: terry.reedy
components: IDLE
messages: 229845
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle Code Context: separate changing current and future editors
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 23 02:17:04 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Oct 2014 00:17:04 +0000
Subject: [New-bugs-announce] [issue22704] Review extension enable options
Message-ID: <1414023424.37.0.56141003135.issue22704@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Currently, each extension is supposed to have an 'enable' option and optionally enable_editor or enable_shell, to "to apply it only to editor/shell windows" (config-extensions.def comment).  I think the rule should be changed (see below).

Currently, the file itself does not follow its own rule.  Most editor-only options only have enable and not enable_editor.  One have enable and enable_shell=False, presumably to exclude the shell, but a user could override False with True, in the user config-extensions, which would not be valid.  The file should be changed to follow the current or altered rule.

I think that the requirement should be for the presence of any one of the enable options.  An extension that is only valid for the editor should simply have enable_editor.  Ditto for enable_shell. Enable by itself would globally turn the extension on or all for all windows, include output windows.  It is possible that we might need an enable_output option too.

----------
assignee: terry.reedy
components: IDLE
messages: 229846
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Review extension enable options
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 23 02:17:13 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Oct 2014 00:17:13 +0000
Subject: [New-bugs-announce] [issue22705] Idle extension configuration: add
	option-help option
Message-ID: <1414023433.5.0.357242409854.issue22705@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

#3068 adds a extension configuration dialog, with some validation of user input.  msg228890 suggest a new 'option-help' option to explain the meaning of options, limit int entries when appropriate, and limit string choices (with a drop-down list) when appropriate.  The help could also indicate options that require a restart to take effect.

----------
assignee: terry.reedy
components: IDLE
messages: 229847
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle extension configuration: add option-help option
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 23 02:17:33 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Oct 2014 00:17:33 +0000
Subject: [New-bugs-announce] [issue22706] Idle extension configuration and
	key bindings
Message-ID: <1414023453.7.0.681663520586.issue22706@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In default config-extensions.def, section [X] is followed by section [X_cfgBindings]. In user config-extensions.cfg, the two sections are written independently by the config dialog (key bindings) and by the extensions dialog (the [X]).  While having [X] and [X_cfgBindings] separated and even reversed in order seems to still work, it would be nicer if they were written together in the proper order.  It might be possible to do this in the user-config writing method in config-handler.

----------
components: IDLE
messages: 229848
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle extension configuration and key bindings
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 23 02:18:13 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Oct 2014 00:18:13 +0000
Subject: [New-bugs-announce] [issue22707] Idle: changed options should take
	effect immediately
Message-ID: <1414023493.97.0.227461422456.issue22707@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Currently, some option changes take effect immediately, and some only when Idle is started again.  To the extent possible, options should take effect immediately, perhaps by not caching values outside of the config dictionary that records changes before they are written out.

Where immediately effect is not possible, there should be an indication. See #22705 for documenting extension options.

----------
assignee: terry.reedy
components: IDLE
messages: 229849
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: changed options should take effect immediately
type: behavior

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

From report at bugs.python.org  Thu Oct 23 08:21:23 2014
From: report at bugs.python.org (Vova)
Date: Thu, 23 Oct 2014 06:21:23 +0000
Subject: [New-bugs-announce] [issue22708] httplib/http.client in method
	_tunnel used HTTP/1.0	CONNECT method
Message-ID: <1414045283.61.0.401738994501.issue22708@psf.upfronthosting.co.za>


New submission from Vova:

At my workplace I have to use corporate Internet proxy server with AD/domain/ntlm authorization. I use local cntlm proxy server to authorize myself on corporate proxy. Programs are send requests to cntlm proxy without any authorization information. Cntlm proxy communicate with corporate proxy and handle all authorization stuff and return response to programs. 

But programs which use httplib, like pip, and want to open https url can't work in my network scheme. Because to open https connection httplib send to cntlm proxy 

"CONNECT encrypted.google.com:443 HTTP/1.0\r\n"

HTTP/1.0 does not assume persistent connection so corporate proxy return http response 407 (need authorization) and close connection. Cntlm proxy detect closed connection and return http response 407 to pip/httplib which can't handle this response or begin ntlm negotiation, throw exception 

ProxyError('Cannot connect to proxy.', error('Tunnel connection failed: 407 Proxy Authentication Required',))  

and close.

So I suggest change HTTP CONNECT method to 

"CONNECT %s:%d HTTP/1.1\r\n"

This change allow cntlm proxy keep alive connection to corporate proxy do all authorization stuff and return proper response. 

And also in header of httplib is stated what it is "HTTP/1.1 client library"

----------
components: Library (Lib)
files: py2.7.httplib.patch
keywords: patch
messages: 229856
nosy: vova
priority: normal
severity: normal
status: open
title: httplib/http.client in method _tunnel used HTTP/1.0 CONNECT method
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file36996/py2.7.httplib.patch

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

From report at bugs.python.org  Thu Oct 23 09:16:00 2014
From: report at bugs.python.org (Akira Li)
Date: Thu, 23 Oct 2014 07:16:00 +0000
Subject: [New-bugs-announce] [issue22709] restore accepting detached stdin
	in fileinput binary mode
Message-ID: <1414048560.8.0.0429092094688.issue22709@psf.upfronthosting.co.za>


New submission from Akira Li:

The patch for Issue #21075: "fileinput.FileInput now reads bytes from standard stream if binary mode is specified" broke code that used
sys.stdin = sys.stdin.detach() with FileInput(mode='rb') in Python 3.3

I've attached the patch that makes FileInput to accept detached sys.stdin 
(without 'buffer' attribute) in binary mode.

----------
components: Library (Lib)
files: fileinput-detached-stdin.diff
keywords: patch
messages: 229859
nosy: akira
priority: normal
severity: normal
status: open
title: restore accepting detached stdin in fileinput binary mode
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file36997/fileinput-detached-stdin.diff

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

From report at bugs.python.org  Thu Oct 23 11:04:37 2014
From: report at bugs.python.org (David Barnett)
Date: Thu, 23 Oct 2014 09:04:37 +0000
Subject: [New-bugs-announce] [issue22710] doctest exceptions include
	nondeterministic namespace
Message-ID: <1414055077.68.0.197371426404.issue22710@psf.upfronthosting.co.za>


New submission from David Barnett:

doctests includes special exception processing support (described in https://docs.python.org/3/library/doctest.html#what-about-exceptions), but in python3 it seems to print the fully-qualified class name even for exception classes in the same module, which makes the expected output vary between py2 and py3.

For instance, given a file spam/eggs.py with these contents:
  class Error(Exception):
      """Spam, Bacon, and Spam
  
      >>> raise Error()
      Traceback (most recent call last):
          ...
      Error
      """
running the command
  python3 -m doctest spam/eggs.py
will fail expecting "eggs.Error" instead of just "Error".

If you instead invoke it with the command
  nosetests3 --with-doctest spam/eggs.py
it will fail expecting yet another name, "spam.eggs.Error".

It may be possible to work around issues like this using ELLIPSIS, but it makes the doctests harder to read and it really seems like at least exception classes defined in the same file should be able to match by just their short class name.

----------
components: Library (Lib)
messages: 229864
nosy: mu_mind
priority: normal
severity: normal
status: open
title: doctest exceptions include nondeterministic namespace
type: behavior
versions: Python 3.2, Python 3.4

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

From report at bugs.python.org  Thu Oct 23 14:57:26 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 23 Oct 2014 12:57:26 +0000
Subject: [New-bugs-announce] [issue22711] "legacy" distutils docs better
	than packaging guide
Message-ID: <1414069046.6.0.438005896108.issue22711@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I just noticed that access to the normal distutils docs has become difficult. They are hidden as "legacy" while a link to the packaging user guide (https://packaging.python.org/en/latest/) is prominently displayed.

The problem is that the packaging user guide is an unreadable mess of recommandations, which is both tedious and unhelpful when you want a detailed documentation of e.g. the setup() function.

I would ask to revert to the "old" distutils docs until the packaging guide becomes up to the task.

----------
assignee: docs at python
components: Documentation
messages: 229871
nosy: docs at python, dstufft, eric.araujo, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: "legacy" distutils docs better than packaging guide
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Oct 23 21:02:22 2014
From: report at bugs.python.org (zodalahtathi)
Date: Thu, 23 Oct 2014 19:02:22 +0000
Subject: [New-bugs-announce] [issue22712] Add 'input' argument to
	subprocess.check_call and	subprocess.call
Message-ID: <1414090942.23.0.710907955389.issue22712@psf.upfronthosting.co.za>


New submission from zodalahtathi:

Python 3.4 added a 'input' argument to the subprocess.check_output function to send bytes to stdin, but it was surprisingly not added to other subprocess helpers.

The same functionality should be added to subprocess.check_call and subprocess.call.

----------
components: Library (Lib)
messages: 229889
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: Add 'input' argument to subprocess.check_call and subprocess.call
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 23 21:03:16 2014
From: report at bugs.python.org (Garry Smith)
Date: Thu, 23 Oct 2014 19:03:16 +0000
Subject: [New-bugs-announce] [issue22713] print()
Message-ID: <1414090996.4.0.97787020472.issue22713@psf.upfronthosting.co.za>


New submission from Garry Smith:

Problem with print()
I did the following by accident while in the python console, print = 10, which it let me do, to horror.after that I could not use the print() command without getting the following error:-

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable

This is what I type in the console.

print = 33
a = 34
print(a)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not callable.

The only way to get the print command back was close and reopen the console.

----------
messages: 229890
nosy: gazza7364
priority: normal
severity: normal
status: open
title: print()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 24 06:35:08 2014
From: report at bugs.python.org (Van Ly)
Date: Fri, 24 Oct 2014 04:35:08 +0000
Subject: [New-bugs-announce] [issue22714] target of 'import statement' entry
	in general index for	'i' is wrong
Message-ID: <1414125308.24.0.874909264609.issue22714@psf.upfronthosting.co.za>


New submission from Van Ly:

The target points to within '__import__()' but should point to 'import()' method function.

For example,

# 'import statement' entry at index for 'i' on the following page
python-2.7.5-docs-html/genindex-I.html

# points to
python-2.7.5-docs-html/library/functions.html#index-8

# but should point to
python-2.7.5-docs-html/reference/simple_stmts.html#import

----------
assignee: docs at python
components: Documentation
messages: 229914
nosy: docs at python, vy0123
priority: normal
severity: normal
status: open
title: target of 'import statement' entry in general index for 'i' is wrong
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.5

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

From report at bugs.python.org  Fri Oct 24 16:38:25 2014
From: report at bugs.python.org (Akira Kitada)
Date: Fri, 24 Oct 2014 14:38:25 +0000
Subject: [New-bugs-announce] [issue22715] PEP 257: drop the recommendation
	for a blank line	between the class line and the docstring
Message-ID: <1414161505.87.0.98081609244.issue22715@psf.upfronthosting.co.za>


New submission from Akira Kitada:

The PEP 257 says:

   Insert a blank line before and after all docstrings (one-line or multi-line)
   that document a class


Looking at stdlib and popular open source software, I couldn't find packages that follow this style, so I think this is not really a convention.

----------
files: pep-0257.patch
keywords: patch
messages: 229921
nosy: akitada
priority: normal
severity: normal
status: open
title: PEP 257: drop the recommendation for a blank line between the class line and the docstring
Added file: http://bugs.python.org/file37003/pep-0257.patch

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

From report at bugs.python.org  Fri Oct 24 17:02:59 2014
From: report at bugs.python.org (flying sheep)
Date: Fri, 24 Oct 2014 15:02:59 +0000
Subject: [New-bugs-announce] [issue22716] Add reference to the object
	missing an attribute to	AttributeError
Message-ID: <1414162979.59.0.692601319144.issue22716@psf.upfronthosting.co.za>


New submission from flying sheep:

Trying to replicate a Ruby Gem that raises a ?did you mean? error when mistyping a method name, I hit a showstopper:

There seems to be no way to get the object which misses an attribute from an AttributeError.

I propose the appended patch (it might be completely broken because I?m not experienced in the Python C API, but I tried)

----------
components: Interpreter Core
files: attribute_error_origin.patch
keywords: patch
messages: 229923
nosy: flying sheep
priority: normal
severity: normal
status: open
title: Add reference to the object missing an attribute to AttributeError
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file37004/attribute_error_origin.patch

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

From report at bugs.python.org  Fri Oct 24 17:03:05 2014
From: report at bugs.python.org (mbasti)
Date: Fri, 24 Oct 2014 15:03:05 +0000
Subject: [New-bugs-announce] [issue22717] PySSL segmentation fault
Message-ID: <1414162985.53.0.0830998350646.issue22717@psf.upfronthosting.co.za>


New submission from mbasti:

Hello,

I'm getting null pointer dereference which leads to segmentation fault.
I have no stable reproducer, but don't hesitate to contact me.

Additional info is here: https://fedorahosted.org/freeipa/ticket/4649

python 2.7.8-4.1 (Fedora 21)

#0  0x00007f3c4a66dde4 in newPySSLObject (ciphers=0x7f3c4544eeb4 "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2", cacerts_file=<optimized out>, proto_version=PY_SSL_VERSION_SSL23, 
    certreq=<optimized out>, socket_type=<optimized out>, cert_file=0x0, key_file=0x0, Sock=0x7f3c3fbafc30) at /usr/src/debug/Python-2.7.8/Modules/_ssl.c:317
317	        self->ctx->options &= ~(SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

(gdb) p self->ctx
$1 = (SSL_CTX *) 0x0

----------
components: Extension Modules
messages: 229924
nosy: mbasti
priority: normal
severity: normal
status: open
title: PySSL segmentation fault
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 24 17:47:29 2014
From: report at bugs.python.org (Andreas Kostyrka)
Date: Fri, 24 Oct 2014 15:47:29 +0000
Subject: [New-bugs-announce] [issue22718] pprint not handline uncomparable
	dictionary keys well
Message-ID: <1414165649.11.0.50429325469.issue22718@psf.upfronthosting.co.za>


New submission from Andreas Kostyrka:

>>> import datetime, pprint
>>> pprint.pformat({datetime.datetime.now(): 1, None: 1})

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/pprint.py", line 63, in pformat
    return PrettyPrinter(indent=indent, width=width, depth=depth).pformat(object)
  File "/usr/lib/python2.7/pprint.py", line 122, in pformat
    self._format(object, sio, 0, 0, {}, 0)
  File "/usr/lib/python2.7/pprint.py", line 140, in _format
    rep = self._repr(object, context, level - 1)
  File "/usr/lib/python2.7/pprint.py", line 226, in _repr
    self._depth, level)
  File "/usr/lib/python2.7/pprint.py", line 238, in format
    return _safe_repr(object, context, maxlevels, level)
  File "/usr/lib/python2.7/pprint.py", line 280, in _safe_repr
    for k, v in _sorted(object.items()):
  File "/usr/lib/python2.7/pprint.py", line 82, in _sorted
    return sorted(iterable)
TypeError: can't compare datetime.datetime to NoneType

This is issue is kind of related to http://bugs.python.org/issue14998
but that talks only python 3.2+

----------
components: Library (Lib)
messages: 229934
nosy: Andreas.Kostyrka
priority: normal
severity: normal
status: open
title: pprint not handline uncomparable dictionary keys well
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 24 18:00:12 2014
From: report at bugs.python.org (Aaron)
Date: Fri, 24 Oct 2014 16:00:12 +0000
Subject: [New-bugs-announce] [issue22719] os.path.isfile & os.path.exists
	but in while loop
Message-ID: <1414166412.24.0.659144032685.issue22719@psf.upfronthosting.co.za>


New submission from Aaron:

When using os.path.isfile() and os.path.exists() in a while loop under certain conditions, os.path.isfile() returns True for paths that do not actually exist.

Conditions:
The folder "C:\Users\EAARHOS\Desktop\Python Review" exists, as do the files "C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py" and "C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py.bak". (Note that I also tested this on a path that contained no spaces, and got the same results.)

Code:
>>> bak_path = r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py"
>>> while os.path.isfile(bak_path):
...     bak_path += '.bak'
...     if not os.path.isfile(bak_path):
...         break
Traceback (most recent call last):
  File "<interactive input>", line 3, in <module>
  File "C:\Installs\Python33\Lib\genericpath.py", line 29, in isfile
    st = os.stat(path)
ValueError: path too long for Windows
>>> os.path.isfile(r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py.bak.bak")
False
>>> 

>>> bak_path = r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py"
>>> while os.path.exists(bak_path):
...     bak_path += '.bak'
...     if not os.path.exists(bak_path):
...         break
Traceback (most recent call last):
  File "<interactive input>", line 3, in <module>
  File "C:\Installs\Python33\Lib\genericpath.py", line 18, in exists
    st = os.stat(path)
ValueError: path too long for Windows
>>> os.path.exists(r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py.bak.bak")
False
>>> 

>>> bak_path = r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py"
>>> os.path.isfile(bak_path), os.path.exists(bak_path)
(True, True)
>>> bak_path += '.bak'
>>> os.path.isfile(bak_path), os.path.exists(bak_path)
(True, True)
>>> bak_path += '.bak'
>>> os.path.isfile(bak_path), os.path.exists(bak_path)
(True, True)
>>> bak_path
'C:\\Users\\EAARHOS\\Desktop\\Python Review\\baseExcel.py.bak.bak'
>>> temp = bak_path
>>> os.path.isfile(temp), os.path.exists(temp)
(True, True)
>>> os.path.isfile('C:\\Users\\EAARHOS\\Desktop\\Python Review\\baseExcel.py.bak.bak'), os.path.exists('C:\\Users\\EAARHOS\\Desktop\\Python Review\\baseExcel.py.bak.bak')
(False, False)
>>> 

On the other hand, this code works as expected:

>>> bak_path = r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py"
>>> while os.path.isfile(bak_path):
...     temp = bak_path + '.bak'
...     bak_path = temp
... 
>>> bak_path
'C:\\Users\\EAARHOS\\Desktop\\Python Review\\baseExcel.py.bak.bak'
>>> 

>>> bak_path = r"C:\Users\EAARHOS\Desktop\Python Review\baseExcel.py"
>>> while os.path.exists(bak_path):
...     temp = bak_path + '.bak'
...     bak_path = temp
... 
>>> bak_path
'C:\\Users\\EAARHOS\\Desktop\\Python Review\\baseExcel.py.bak.bak'
>>>

----------
components: Windows
messages: 229936
nosy: hosford42, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.isfile & os.path.exists but in while loop
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Oct 24 18:34:15 2014
From: report at bugs.python.org (kg*2)
Date: Fri, 24 Oct 2014 16:34:15 +0000
Subject: [New-bugs-announce] [issue22720] Obscure error w/ windows
	online-only file
Message-ID: <1414168455.92.0.21171948536.issue22720@psf.upfronthosting.co.za>


New submission from kg*2:

Windows has integrated onedrive into their os. A feature of onedrive is allowing users to browse files that aren't downloaded onto their computer. os.listdir will return the items, but when they are opened for read/writing it throws IOError[22]: invalid mode or file name. This error was not particularly helpful for this situation, as both the mode and the filename looked correct. Maybe a more specific error for this case would be help?

----------
components: IO
messages: 229941
nosy: kg*2
priority: normal
severity: normal
status: open
title: Obscure error w/ windows online-only file
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 24 19:00:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Oct 2014 17:00:50 +0000
Subject: [New-bugs-announce] [issue22721] pprint output for sets and dicts
	is not stable
Message-ID: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint() sorts the content of sets and dicts in order to get stable output which doesn't depend on iteration order of set or dict, which depend not only from values of elements, but also from set or dict history.

But in some cases the output is different for equal sets or dicts which differs only by their history.

>>> import pprint
>>> class A:  # string 'A' < 'int'
...     def __lt__(self, other): return False
...     def __gt__(self, other): return self != other
...     def __le__(self, other): return self == other
...     def __ge__(self, other): return True
...     def __eq__(self, other): return self is other
...     def __ne__(self, other): return self is not other
...     def __hash__(self): return 1  # == hash(1)
... 
>>> a = A()
>>> sorted([1, a])
[1, <__main__.A object at 0xb700c64c>]
>>> sorted([a, 1])
[1, <__main__.A object at 0xb700c64c>]
>>> # set
>>> pprint.pprint({1, a})
{<__main__.A object at 0xb700c64c>, 1}
>>> pprint.pprint({a, 1})
{1, <__main__.A object at 0xb700c64c>}
>>> # dict
>>> pprint.pprint({1: 1, a: 1})
{1: 1, <__main__.A object at 0xb700c64c>: 1}
>>> pprint.pprint({a: 1, 1: 1})
{<__main__.A object at 0xb700c64c>: 1, 1: 1}

This is happen because _safe_key's __lt__() calls the __lt__() method of it's left argument, and doesn't use special methods of it's right argument. a.__lt__(1) is successful, but (1).__lt__(a) is failed.

I think that instead of `self.obj.__lt__(other.obj)` here should be `self.obj < other.obj`. Or may be call other.obj.__gt__(self.obj) if the result of self.obj.__lt__(other.obj) is NotImplemented.

_safe_key was introduced in issue3976.

----------
components: Library (Lib)
messages: 229943
nosy: fdrake, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pprint output for sets and dicts is not stable
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct 24 20:25:14 2014
From: report at bugs.python.org (Buck Golemon)
Date: Fri, 24 Oct 2014 18:25:14 +0000
Subject: [New-bugs-announce] [issue22722] inheritable pipes are unwieldy
	without os.pipe2
Message-ID: <1414175114.21.0.89253014317.issue22722@psf.upfronthosting.co.za>


New submission from Buck Golemon:

In order to make an inheritable pipe, the code is quite a bit different between posixes that implement pipe2 and those that don't (osx, mainly). I believe the officially-supported path is to call os.pipe() then os.setinheritable(). This seems objectionable since set_inheritable() code is invoked twice, where I'd prefer to invoke it zero times (or at most once).

Would it be acceptable to implement a pipe2 shim for those platforms?
If so, I'll (attempt to) provide a patch.

Alternatively, can we change the signature of os.pipe() to os.pipe(flags=O_CLOEXEC) ?  In my opinion, such a function could be implemented via pipe2 on those platforms that provide it, obviating any need for an os.pipe2.

Please tell me which patch to provide, if any.

----------
messages: 229947
nosy: bukzor
priority: normal
severity: normal
status: open
title: inheritable pipes are unwieldy without os.pipe2

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

From report at bugs.python.org  Fri Oct 24 21:53:20 2014
From: report at bugs.python.org (Buck Golemon)
Date: Fri, 24 Oct 2014 19:53:20 +0000
Subject: [New-bugs-announce] [issue22723] visited-link styling is not
	accessible
Message-ID: <1414180400.68.0.547472264893.issue22723@psf.upfronthosting.co.za>


New submission from Buck Golemon:

The color needs adjusted such that it has at least 3:1 luminance contrast versus the surrounding non-link text. (See "non-inheritable" https://docs.python.org/3/library/os.html#os.dup)

See also:
 * http://www.w3.org/TR/WCAG20/#visual-audio-contrast-without-color
 * http://www.w3.org/WAI/WCAG20/Techniques/working-examples/G183/link-contrast.html

Given that the surrounding text is #222, the a:visited color should be bumped from #30306f to #6363bb in order to meet the 3:1 luminance-contrast guideline while preserving the hue and saturation.

By the same calculation, the un-visited links are slightly too dark and should be bumped from #00608f to #0072aa

Validation was done here: http://juicystudio.com/services/luminositycontrastratio.php

Luminance adjustments done here: http://colorizer.org/

----------
assignee: docs at python
components: Documentation
messages: 229952
nosy: bukzor, docs at python
priority: normal
severity: normal
status: open
title: visited-link styling is not accessible

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

From report at bugs.python.org  Sat Oct 25 01:52:39 2014
From: report at bugs.python.org (Benedikt Morbach)
Date: Fri, 24 Oct 2014 23:52:39 +0000
Subject: [New-bugs-announce] [issue22724] byte-compile fails for cross-builds
Message-ID: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za>


New submission from Benedikt Morbach:

For cross-builds the byte-compiling and 2to3 Grammar generation fail.

This is because PYTHONPATH/sys.path includes 'build/lib.$PLATFORM', in which the compiled .so modules reside.
The host python obviously barfs on those, as they are compiled for a different architecture.

However, this directory also contains _sysconfigdata.py, which is needed at all times.

A possible fix would be to separate those two.

----------
components: Cross-Build
messages: 229969
nosy: Benedikt.Morbach
priority: normal
severity: normal
status: open
title: byte-compile fails for cross-builds
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Oct 25 05:43:56 2014
From: report at bugs.python.org (Van Ly)
Date: Sat, 25 Oct 2014 03:43:56 +0000
Subject: [New-bugs-announce] [issue22725] improve documentation for
	enumerate() (built-in function)
Message-ID: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>


New submission from Van Ly:

The existing documentation is confusing. 

? improve wording as follows

enumerate(sequence, start=0)

Returns pairings of index into sequence[link to glossary.html#term-sequence] with the object at that index in the sequence.

? wording as found in v.2.7.5

enumerate(sequence, start=0)

Return an enumerate object. sequence must be a sequence, an iterator, or some other object which supports iteration. The next() method of the iterator returned by enumerate() returns a tuple containing a count (from start which defaults to 0) and the values obtained from iterating over sequence:

----------
assignee: docs at python
components: Documentation
messages: 229979
nosy: docs at python, vy0123
priority: normal
severity: normal
status: open
title: improve documentation for enumerate() (built-in function)
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.5

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

From report at bugs.python.org  Sat Oct 25 06:46:23 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Oct 2014 04:46:23 +0000
Subject: [New-bugs-announce] [issue22726] Idle: add help to config dialogs
Message-ID: <1414212383.94.0.847086482603.issue22726@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

At one time, ConfigDialog was given a do-nothing Help button.  It was diabled a couple of years ago.  This patch restores it for both config dialogs, displaying a text appropriate for both.  There are separate functions in anticipation of dialog-specific content.  For both, there is the issue of when changes take effect (#22707).  For extensions, there might be extension-specific help (#22705).

----------
assignee: terry.reedy
files: @config-help-34.diff
keywords: patch
messages: 229981
nosy: sahutd, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Idle: add help to config dialogs
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37010/@config-help-34.diff

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

From report at bugs.python.org  Sat Oct 25 21:34:32 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Oct 2014 19:34:32 +0000
Subject: [New-bugs-announce] [issue22727] Improve benchmarks precision
Message-ID: <1414265672.28.0.112980885823.issue22727@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch tries to improve precision of benchmarks in the benchmark suite by two measures:
- select the best timer for the pair of interpreters (i.e. perf_counter() if possible)
- make hashing deterministic to avoid fluctuations between runs

----------
components: Benchmarks
files: precision.patch
keywords: patch
messages: 230011
nosy: brett.cannon, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Improve benchmarks precision
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37014/precision.patch

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

From report at bugs.python.org  Sat Oct 25 22:26:06 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Oct 2014 20:26:06 +0000
Subject: [New-bugs-announce] [issue22728] Deprecate spurious benchmarks
Message-ID: <1414268766.06.0.994855016706.issue22728@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

"iterative_count" and "threaded_count" are really uninteresting benchmarks, inherited from Dave Beazley's GIL experiments. I suggest to deprecate them and remove from the "all" and "2n3" sets. Patch attached.

----------
components: Benchmarks
files: deprecated.patch
keywords: patch
messages: 230015
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate spurious benchmarks
type: enhancement
Added file: http://bugs.python.org/file37015/deprecated.patch

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

From report at bugs.python.org  Sat Oct 25 22:41:40 2014
From: report at bugs.python.org (Ben Mather)
Date: Sat, 25 Oct 2014 20:41:40 +0000
Subject: [New-bugs-announce] [issue22729] `wait` and `as_completed` depend
	on private api
Message-ID: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za>


New submission from Ben Mather:

Adds `remove_done_callback` to `Future` object, removes `_waiters` attribute, and re-implements `wait` and `as_completed` using callbacks.

This makes it possible to extend or replace `Future` without having to mimic its private `_waiters` interface.

Currently waiters and callbacks are triggered at different points after a cancel (waiters in `set_condition_and_notify_cancel` and callbacks in `cancel`.)  This is a problem as it means that implementing `wait` and `as_completed` using `add_done_callback` will result in a behaviour change unless the behaviour of `add_done_callback` is changed instead. 

I don't believe the current behaviour is as documented anyway so I'm not sure if this is a problem.  See issue 22630.

I am a little uncertain about the O(n) implementation of `remove_done_callback` but can't imagine a situation where it would be a problem.

----------
components: Library (Lib)
files: non-magic-waiters.patch
keywords: patch
messages: 230016
nosy: bwhmather
priority: normal
severity: normal
status: open
title: `wait` and `as_completed` depend on private api
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37016/non-magic-waiters.patch

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

From report at bugs.python.org  Sun Oct 26 21:24:46 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 26 Oct 2014 20:24:46 +0000
Subject: [New-bugs-announce] [issue22730] ensurepip should work with
	pythonw.exe
Message-ID: <1414355086.66.0.634731871403.issue22730@psf.upfronthosting.co.za>


New submission from Steve Dower:

I'd like to be able to run ensurepip in the 3.5 installer with pythonw.exe, to avoid having the console window appear.

Unfortunately, pip requires a valid value for sys.__stdout__. This patch adds a dummy value for __stdout__ that allows pip to be installed/uninstalled with pythonw.

I see no reason not to check this into default now, so just seeking a quick review from the module owners. I can also backport it to 3.4 if that's thought to be worthwhile, but I don't think the installer for 3.4 will be updated to use pythonw, so it probably doesn't matter.

----------
assignee: steve.dower
components: Installation
files: ensurepip.patch
keywords: patch
messages: 230032
nosy: dstufft, ncoghlan, steve.dower
priority: normal
severity: normal
status: open
title: ensurepip should work with pythonw.exe
versions: Python 3.5
Added file: http://bugs.python.org/file37020/ensurepip.patch

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

From report at bugs.python.org  Sun Oct 26 21:28:43 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 26 Oct 2014 20:28:43 +0000
Subject: [New-bugs-announce] [issue22731] test_capi test fails because of
	mismatched newlines
Message-ID: <1414355323.22.0.739956006711.issue22731@psf.upfronthosting.co.za>


New submission from Steve Dower:

The test_capi.test_forced_io_encoding test currently requires that newlines match when checking the results. This apparently does not occur with VC10 builds, but does appear with newer versions of the compiler.

This patch normalises the line endings in the values being checked. Just seeking a quick review before I check it in - not sure who's best to nosy, so I picked the test coverage group.

----------
assignee: steve.dower
components: Tests
files: test_capi.patch
keywords: patch
messages: 230034
nosy: christian.heimes, giampaolo.rodola, ncoghlan, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: test_capi test fails because of mismatched newlines
versions: Python 3.5
Added file: http://bugs.python.org/file37021/test_capi.patch

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

From report at bugs.python.org  Sun Oct 26 21:32:06 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 26 Oct 2014 20:32:06 +0000
Subject: [New-bugs-announce] [issue22732] ctypes tests don't set correct
	restype for intptr_t	functions
Message-ID: <1414355526.1.0.122133649749.issue22732@psf.upfronthosting.co.za>


New submission from Steve Dower:

The test_pass_pointer and test_int_pointer_arg tests are inconsistent between 32-bit and 64-bit builds because c_long is always 32 bits but the function being called may return a 64-bit value (it's a pointer, so c_long may truncate it).

I'd prefer to have a c_intptr type to use, but this patch uses c_longlong in the test if that's the size of a pointer.

Just looking for a quick review so I can check this into default. Not sure why it doesn't repro with VC10, but it certainly does with later compilers.

----------
assignee: steve.dower
components: Tests, ctypes
files: test_ctypes.patch
keywords: patch
messages: 230035
nosy: amaury.forgeotdarc, belopolsky, meador.inge, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: ctypes tests don't set correct restype for intptr_t functions
versions: Python 3.5
Added file: http://bugs.python.org/file37022/test_ctypes.patch

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

From report at bugs.python.org  Sun Oct 26 21:35:54 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 26 Oct 2014 20:35:54 +0000
Subject: [New-bugs-announce] [issue22733] MSVC ffi_prep_args doesn't handle
	64-bit arguments	properly
Message-ID: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za>


New submission from Steve Dower:

The ffi_prep_args function in libffi_msvc/ffi.c needs the attached patch to handle 64-bit parameters with the correct padding.

Without this patch, garbage may appear in the top part of 64-bit arguments as the values are not zeroed out by the memcpy.

I'm not 100% sure who 'owns' this file - is there an upstream project that should get the patch rather than Python? If not, I see no reason not to check this in now, even though it doesn't seem to repro with the VC10 builds.

----------
components: ctypes
files: ffi_prep_args.patch
keywords: patch
messages: 230036
nosy: amaury.forgeotdarc, belopolsky, meador.inge, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: MSVC ffi_prep_args doesn't handle 64-bit arguments properly
versions: Python 3.5
Added file: http://bugs.python.org/file37023/ffi_prep_args.patch

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

From report at bugs.python.org  Sun Oct 26 21:40:05 2014
From: report at bugs.python.org (Steve Dower)
Date: Sun, 26 Oct 2014 20:40:05 +0000
Subject: [New-bugs-announce] [issue22734] marshal needs a lower stack depth
	for debug builds on	Windows
Message-ID: <1414356005.7.0.437869876375.issue22734@psf.upfronthosting.co.za>


New submission from Steve Dower:

This patch decreases the stack depth limit for Windows debug builds to prevent the recursion test from failing. (Apparently VC14 uses more stack space for each frame than VC10, but the release build is unaffected.)

Not sure who the correct nosy for marshal is, so I picked test coverage, as this only really shows up in the tests.

----------
assignee: steve.dower
components: Tests
files: marshal.patch
keywords: patch
messages: 230037
nosy: christian.heimes, giampaolo.rodola, ncoghlan, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: marshal needs a lower stack depth for debug builds on Windows
versions: Python 3.5
Added file: http://bugs.python.org/file37024/marshal.patch

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

From report at bugs.python.org  Sun Oct 26 22:06:21 2014
From: report at bugs.python.org (Eldar Abusalimov)
Date: Sun, 26 Oct 2014 21:06:21 +0000
Subject: [New-bugs-announce] [issue22735] Fix various crashes exposed
	through mro() customization
Message-ID: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za>


New submission from Eldar Abusalimov:

The attached patch fixes several bugs revealed by providing a custom mro(). Most of these bugs are reentrancy issues (mainly, cls.__bases__ assignment within mro() which causes incorrect refcounting), but there are also some issues when using incomplete types with uninitialized MRO (dereferencing NULL when extending such types, attribute lookup on super, etc.). The patch is made against the default branch (py3k), however all these bugs exist in Python 2 as well.

I also tried to break the patch into smaller pieces (commits, in fact) to ease reviewing: a common pattern is test->minor->fix series. The patch set is an output of `git format-patch`, and most patches have a detailed commit message describing a change inside.

Adding memory mgmt and object model guys to nosy list.

----------
components: Interpreter Core
files: mro-crashers-fix-v1.diff
keywords: patch
messages: 230044
nosy: abusalimov, benjamin.peterson, lemburg, tim.peters
priority: normal
severity: normal
status: open
title: Fix various crashes exposed through mro() customization
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37025/mro-crashers-fix-v1.diff

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

From report at bugs.python.org  Mon Oct 27 02:03:42 2014
From: report at bugs.python.org (Van Ly)
Date: Mon, 27 Oct 2014 01:03:42 +0000
Subject: [New-bugs-announce] [issue22736] tutorial links at top,
	book recommendations at bottom of module documentation
Message-ID: <1414371822.19.0.713420749411.issue22736@psf.upfronthosting.co.za>


New submission from Van Ly:

IMO the box highlight at the top of module documentation, for example, re module (library/re.html#module-re), ought to place book recommendations at the very bottom in a section called 'Further Readings'. Why? Because being at the top of the documentation should mean it is instantly accessible. 

The box highlight of tutorials at the top is a nice touch.

----------
assignee: docs at python
components: Documentation
messages: 230052
nosy: docs at python, vy0123
priority: normal
severity: normal
status: open
title: tutorial links at top, book recommendations at bottom of module documentation
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Oct 27 03:38:59 2014
From: report at bugs.python.org (Joshua Harlow)
Date: Mon, 27 Oct 2014 02:38:59 +0000
Subject: [New-bugs-announce] [issue22737] Provide a rejected execution model
	and implementations	for futures.
Message-ID: <1414377539.49.0.348706562954.issue22737@psf.upfronthosting.co.za>


New submission from Joshua Harlow:

When a future can't be accepted by an executor that it is has been submitted to it would be really nice to throw have a type of 'RejectedExecutionException' (this is the name the java folks have used) to denote that the executors policy does not allow for further execution.

Some of the reasons that further execution could be rejected (an arbitrary executor policy would be really neat).

- Backlog of work to be done has reached a configurable threshold.
- Resource limits reached (in concept similar to a 503 HTTP error code), come back later...

This would be a great addition to allow for executor usage that does not cause resource starvation (currently executors have unbounded work queues, which is undesirable under load where a rejected execution error would be more appropriate to avoid more starvation...)

----------
components: Library (Lib)
messages: 230058
nosy: Joshua.Harlow
priority: normal
severity: normal
status: open
title: Provide a rejected execution model and implementations for futures.
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon Oct 27 05:39:46 2014
From: report at bugs.python.org (Van Ly)
Date: Mon, 27 Oct 2014 04:39:46 +0000
Subject: [New-bugs-announce] [issue22738] improve sys.argv,
	'python -h' documentation
Message-ID: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>


New submission from Van Ly:

I was looking at sys.argv from the reference guide. 

The font mix and change from v.2.7.5 to v.3.5.0a0 for sentence two of sys.argv (library/sys.html#module-sys) has made the second rendering of -c look capital when in fact it isn't.

--quote: from v.3.5.0a0 at library/sys.html#module-sys
If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string '-c'.
--quote--

--suggest: improve second sentence of sys.argv (v.2.7.5, v.3.5.0a0)
Call the Python interpreter with the option, -c str, and the value of argv[0] is '-c'.
--suggest--

--suggest: improve 'python -h' output
-c str : feed in a string as program (terminates option list)
--suggest--

----------
assignee: docs at python
components: Documentation
messages: 230059
nosy: docs at python, vy0123
priority: normal
severity: normal
status: open
title: improve sys.argv, 'python -h' documentation
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Oct 27 07:53:47 2014
From: report at bugs.python.org (Lachlan Kingsford)
Date: Mon, 27 Oct 2014 06:53:47 +0000
Subject: [New-bugs-announce] [issue22739] "There is no disk in the drive"
	error
Message-ID: <1414392827.56.0.571948062757.issue22739@psf.upfronthosting.co.za>


New submission from Lachlan Kingsford:

An error is being raised that 'There is no disk in the drive. Please insert a disk into drive \Device\Harddisk1\DR1. Cancel, Try Again, Continue)'.

The line of code referred to has no reference to any file or disk access. None of its calling procedures have any file or disk access. As such, I am fairly confident that the error is not caused by an error in my code.

The Python interpreter was embedded via cx_freeze. The embedded interpreter was Win64 running on 64 bit Windows 7. The computer that reported the bug did not have Python installed on it.

I have been unable to replicate the bug. Similar bugs have been reported due to USB sticks and phones, but none were plugged in or removed while the program was being run.

At this stage, I am unsure if this is a bug with Windows, cx_freeze, or pygame. The bug is also listed on https://github.com/lkingsford/AtlasWarriors/issues/5, with access to the source available. You can view the stack trace and an image of the error, and the stack trace there.

I am not sure if this is a known issue but I am unable to find any reference to it.

----------
components: IO, Windows
messages: 230060
nosy: Lachlan.Kingsford, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: "There is no disk in the drive" error
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 27 11:16:13 2014
From: report at bugs.python.org (Stephan Monecke)
Date: Mon, 27 Oct 2014 10:16:13 +0000
Subject: [New-bugs-announce] [issue22740] Cache error
Message-ID: <1414404973.65.0.809705058113.issue22740@psf.upfronthosting.co.za>


New submission from Stephan Monecke:

`python2 test.py` results in the following error:

Traceback (most recent call last):
  File "test.py", line 1, in <module>
    import seaborn as sns
  File "/path/seaborn.py", line 4, in <module>
    sns.set(style="ticks")
AttributeError: 'module' object has no attribute 'set'

seaborn.py is an old plot-file thats already deleted.

----------
components: Extension Modules
messages: 230065
nosy: smoneck
priority: normal
severity: normal
status: open
title: Cache error
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Oct 27 11:49:44 2014
From: report at bugs.python.org (Van Ly)
Date: Mon, 27 Oct 2014 10:49:44 +0000
Subject: [New-bugs-announce] [issue22741] suggestion for improving wording
	on len(s) (built-in	function)
Message-ID: <1414406984.61.0.134350920891.issue22741@psf.upfronthosting.co.za>


New submission from Van Ly:

-- suggest the following because 
-- the parenthetical parts interrupt the reading too often

len(s)

Returns a length count, the number of objects in argument s which may be a sequence, or mapping: a string, list or tuple, or a dictionary.

----------
assignee: docs at python
components: Documentation
messages: 230068
nosy: docs at python, vy0123
priority: normal
severity: normal
status: open
title: suggestion for improving wording on len(s) (built-in function)
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Oct 27 17:18:24 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 27 Oct 2014 16:18:24 +0000
Subject: [New-bugs-announce] [issue22742] IDLE shows traceback when printing
	non-BMP character
Message-ID: <1414426704.85.0.168243800807.issue22742@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

>>> print("\N{ROCKET}")
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    print("\N{ROCKET}")
  File "idlelib/PyShell.py", line 1352, in write
    return self.shell.write(s, self.tags)
UnicodeEncodeError: 'UCS-2' codec can't encode character '\U0001f680' in position 0: Non-BMP character not supported in Tk

Shouldn't IDLE replace non-encodable characters with "\uFFFD"?

I think

>>> "\N{ROCKET}"
?

is user-friendlier than the traceback.

See also #14304.

----------
components: Library (Lib)
messages: 230078
nosy: belopolsky
priority: normal
severity: normal
status: open
title: IDLE shows traceback when printing non-BMP character
type: behavior

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

From report at bugs.python.org  Mon Oct 27 18:02:22 2014
From: report at bugs.python.org (Friedrich Spee von Langenfeld)
Date: Mon, 27 Oct 2014 17:02:22 +0000
Subject: [New-bugs-announce] [issue22743] Specify supported XML version
Message-ID: <1414429342.52.0.789761709754.issue22743@psf.upfronthosting.co.za>


New submission from Friedrich Spee von Langenfeld:

The W3C has published two versions of the standard specification for the Extensible Markup Language (XML) [version 1.0 and 1.1]. I know that the W3C expects all parsers to understand both versions. I propose to state  here (https://docs.python.org/3/library/xml.html) which versions of XML Python supports, especially, because https://docs.python.org/3/library/xml.etree.elementtree.html uses version 1.0 of the W3C recommendation in its examples. The version compatibility is named in https://docs.python.org/3/library/pyexpat.html#xml.parsers.expat.xmlparser.XmlDeclHandler , but I don?t think a normal user, who only want a quick, but reliable solution, would ever read this entry.

What do you think?

----------
assignee: docs at python
components: Documentation
messages: 230079
nosy: Friedrich.Spee.von.Langenfeld, docs at python
priority: normal
severity: normal
status: open
title: Specify supported XML version
type: enhancement

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

From report at bugs.python.org  Mon Oct 27 19:04:12 2014
From: report at bugs.python.org (tegavu)
Date: Mon, 27 Oct 2014 18:04:12 +0000
Subject: [New-bugs-announce] [issue22744] os.path.join on Windows creates
	invalid paths with spaces
Message-ID: <1414433052.69.0.696616373755.issue22744@psf.upfronthosting.co.za>


New submission from tegavu:

Windows does not like/permit folders with spaces in the beginning or folders and files with a tailing space character, as this will cause problems.
The python functions for os.mkdir will solve this by eliminating the blanks automatically.
But os.path.join() will give wrong results.

Example:

#Python 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23)
import os
dir1 = "c:\\"
dir2 = "test   "
file = "test.txt"     

os.mkdir( os.path.join(dir1, dir2) )    
    # this will correctly create c:\test\
f = open( os.path.join(dir1, dir2, file) ,"wb")
    # this will fail with 'FileNotFoundError: [Errno 2] No such file or directory: 'c:\\test     \\test.txt''
print("__" + os.path.join(dir1, dir2, file) + "__")   
    # this will incorrectly show 'c:\test     \test.txt'
    # or if you chose to also have spaces at the end of "test.txt     " will show them

----------
messages: 230082
nosy: tegavu
priority: normal
severity: normal
status: open
title: os.path.join on Windows creates invalid paths with spaces
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Oct 27 19:41:35 2014
From: report at bugs.python.org (Wolfgang Rohdewald)
Date: Mon, 27 Oct 2014 18:41:35 +0000
Subject: [New-bugs-announce] [issue22745] cgitb with Py3: TypeError: 'str'
	does not support the	buffer interface
Message-ID: <1414435295.09.0.872195623782.issue22745@psf.upfronthosting.co.za>


New submission from Wolfgang Rohdewald:

The attached script works with Python2.7. With Python3.4, it produces

Traceback (most recent call last):
  File "/usr/lib/python3.4/cgitb.py", line 268, in __call__
    self.handle((etype, evalue, etb))
  File "cgibug.py", line 12, in handle
    cgitb.Hook.handle(self, info)
  File "/usr/lib/python3.4/cgitb.py", line 273, in handle
    self.file.write(reset())
TypeError: 'str' does not support the buffer interface

When replacing the file mode 'wb' with 'w', it produces this failure:
  File "/usr/lib/python3.4/cgitb.py", line 288, in handle
    self.file.write(doc + '\n')
TypeError: can't concat bytes to str

The script works as expected with Python2.7 with both file modes.

----------
components: Library (Lib)
files: cgibug.py
messages: 230083
nosy: wrohdewald
priority: normal
severity: normal
status: open
title: cgitb with Py3: TypeError: 'str' does not support the buffer interface
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file37043/cgibug.py

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

From report at bugs.python.org  Mon Oct 27 19:48:57 2014
From: report at bugs.python.org (Wolfgang Rohdewald)
Date: Mon, 27 Oct 2014 18:48:57 +0000
Subject: [New-bugs-announce] [issue22746] cgitb html: wrong encoding for
	utf-8
Message-ID: <1414435737.5.0.509535388247.issue22746@psf.upfronthosting.co.za>


New submission from Wolfgang Rohdewald:

The attached script shows the non-ascii characters wrong wherever they occur, including the exception message and the comment in the source code.

Looking at the produced .html, I can say that cgitb simply passes the single byte utf-8 codes without encoding them as needed.

Same happens with Python3.4 (after applying some quick and dirty changes to cgitb.py, see bug #22745).

----------
components: Library (Lib)
files: cgibug.py
messages: 230085
nosy: wrohdewald
priority: normal
severity: normal
status: open
title: cgitb html: wrong encoding for utf-8
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37044/cgibug.py

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

From report at bugs.python.org  Mon Oct 27 22:30:08 2014
From: report at bugs.python.org (Matt Frank)
Date: Mon, 27 Oct 2014 21:30:08 +0000
Subject: [New-bugs-announce] [issue22747] Interpreter fails in initialize on
	systems where	HAVE_LANGINFO_H is undefined
Message-ID: <1414445408.19.0.175857050886.issue22747@psf.upfronthosting.co.za>


New submission from Matt Frank:

On systems where configure is unable to find langinfo.h (or where nl_langinfo() is not defined), configure undefines HAVE_LANGINFO_H in pyconfig.h.  Then in pythonrun.c:get_locale_encoding() the call to nl_langinfo() is wrapped in an #ifdef, but the #else path on the ifdef does a PyErr_SetNone(PyExc_NotImplementedError) and returns NULL, which  causes initfsencoding() to fail with the message "Py_Initialize: Unable to get the locale encoding", which causes the interpreter to abort.

I'm confused because http://bugs.python.org/issue8610 (from 2010) seems to have come down on the side of deciding that nl_langinfo() failures should be treated as implicitly returning either "ASCII" or "UTF-8" (I'm not sure which).  But maybe that was for a different part of the interpreter?

In any case there are 4 choices here, all of which are preferable to what we are doing now.

1. Fail during configure.  If we can't even start the interpreter, then why waste the users time with the build?
2. Fail during compilation.  The #else path could contain #error "Python only works on systems where nl_langinfo() is correctly implemented."  Again, this would be far preferable to failing only once the user has finished the install and tries to get the interpreter prompt.
3. Implement our own python_nl_langinfo() that we fall back on when the system one doesn't exist.  (It could, for example, return "ASCII" (or "ANSI_X3.4-1968") to start with, and "UTF-8" after we see a call to setlocale(LC_CTYPE, "") or setlocale(LC_ALL, "").
4. just return the string "ASCII".

The attached patch does the last.  I'm willing to try to write the patch for choice (3) if that's what you'd prefer.  (I have an implementation that does (3) for systems that also don't have setlocale() implemented, but I don't yet know how to do it if nl_langinfo() doesn't exist but setlocale() does.)

----------
components: Interpreter Core
files: no_langinfo_during_init.patch
keywords: patch
messages: 230106
nosy: Arfrever, WanderingLogic, haypo, lemburg, loewis, pitrou
priority: normal
severity: normal
status: open
title: Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file37046/no_langinfo_during_init.patch

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

From report at bugs.python.org  Tue Oct 28 05:44:29 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 28 Oct 2014 04:44:29 +0000
Subject: [New-bugs-announce] [issue22748] Porting Extension Modules to
	Python 3 documentation	mention about PyString_* functions in
	Python 3
Message-ID: <1414471469.41.0.545994852005.issue22748@psf.upfronthosting.co.za>


New submission from Berker Peksag:

"Porting Extension Modules to Python 3" document mention about "PyString_*" functions in Python 3. I think the correct prefix should be "PyUnicode_*".

>From https://docs.python.org/3/howto/cporting.html#str-unicode-unification:

    "Python 3?s str() (PyString_* functions in C) type is equivalent to Python 2?s unicode() (PyUnicode_*)."

----------
assignee: docs at python
components: Documentation
messages: 230119
nosy: benjamin.peterson, berker.peksag, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Porting Extension Modules to Python 3 documentation mention about PyString_* functions in Python 3
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Oct 28 08:36:54 2014
From: report at bugs.python.org (Akira Li)
Date: Tue, 28 Oct 2014 07:36:54 +0000
Subject: [New-bugs-announce] [issue22749] remove obsolete remark in
	time.clock() docs
Message-ID: <1414481814.68.0.767829383037.issue22749@psf.upfronthosting.co.za>


New submission from Akira Li:

time.clock() documentation [1] says:

  this is the function to use for benchmarking Python or timing algorithms.

and

  Deprecated since version 3.3: The behaviour of this function depends on the platform: use perf_counter() or process_time() instead, depending on your requirements, to have a well defined behaviour.


[1]: https://hg.python.org/cpython/file/a22ef88143b9/Doc/library/time.rst#l127

The first remark is incorrect since 3.3. I've attached a documentation patch that removes it.

----------
assignee: docs at python
components: Documentation
files: docs-time-clock-remove-stale-remark.diff
keywords: patch
messages: 230124
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: remove obsolete remark in time.clock() docs
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37048/docs-time-clock-remove-stale-remark.diff

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

From report at bugs.python.org  Tue Oct 28 10:57:00 2014
From: report at bugs.python.org (Ferdinand)
Date: Tue, 28 Oct 2014 09:57:00 +0000
Subject: [New-bugs-announce] [issue22750] xmlapp.py display bug when
	validate XML by DTD
Message-ID: <1414490220.27.0.963002484178.issue22750@psf.upfronthosting.co.za>


New submission from Ferdinand:

Code is working, but the TEXT variable is not showing the correct line of the XML file but the the line after correct one :

Exemple :
[u6v7mr at vl-a-txx-05 Python]$ ./validateXML.py DTD/herve.xml DTD/Tomcat.dtd
ERROR: 'I' is not an allowed value for the 'value' attribute at DTD/herve.xml:3:19
TEXT: '
  <tomcat'
XML file is KO
[u6v7mr at vl-a-txx-05 Python]$

The line expected is  :   <env value="I"/>

The corresponding line in the DTD file is this one :
<!ATTLIST env
                value (D|F|R|P|Q|A) #REQUIRED
>

Here is the python's content :
[u6v7mr at vl-a-txx-05 Python]$ cat validateXML.py
#!/usr/bin/python

from xml.parsers.xmlproc import xmlproc
from xml.parsers.xmlproc import xmlval
from xml.parsers.xmlproc import xmldtd

def validate_xml(xml_filename, dtd_filename):
        """Validate a given XML file with a given external DTD.
        If the XML file is not valid, an exception will be
        printed with an error message."""
        dtd = xmldtd.load_dtd(dtd_filename)
        parser = xmlproc.XMLProcessor()
        parser.set_application(xmlval.ValidatingApp(dtd, parser))
        parser.dtd = dtd
        parser.ent = dtd
        try :
                parser.parse_resource(xml_filename)
        except :
                print "XML file is KO"
                return 0
        print "XML file is OK"

if __name__ == "__main__":
        import sys
        xml_filename, dtd_filename = sys.argv[1], sys.argv[2]
        validate_xml(xml_filename, dtd_filename)
[u6v7mr at vl-a-txx-05 Python]$


Here is the XML file with the error for the element env :
[u6v7mr at vl-a-txx-05 Python]$ cat DTD/herve.xml
<?xml version='1.0' encoding='utf-8'?>
<config>
  <env value="I"/>
  <tomcat count="1" start="1" step="1" adresseIP="10.108.250.72" offset="10" name="HERVE_R_NM_GEN" shutdown_port="40010" >
    <jvm>
      <memory verbosegc="true" logrotategc="true" min="512" max="1024"> </memory>
      <permgen max="128" min="128"> </permgen>
    </jvm>
  </tomcat>
 <tomcat count="1" start="2" step="1" adresseIP="10.108.250.72" offset="20" name="HERVE_R_NM_GEN" shutdown_port="40010" >
    <jvm>
      <memory verbosegc="true" logrotategc="true" min="512" max="1024"> </memory>
      <permgen max="128" min="128"> </permgen>
    </jvm>
  </tomcat>
</config>

[u6v7mr at vl-a-txx-05 Python]$
Here is the stdout expected :
[u6v7mr at vl-a-txx-05 Python]$ ./validateXML.py DTD/herve.xml DTD/Tomcat.dtd
ERROR: 'I' is not an allowed value for the 'value' attribute at DTD/herve.xml:3:19
TEXT: '
<env value="I"/>'
XML file is KO

----------
components: XML
files: Tomcat.dtd
messages: 230135
nosy: Spider06
priority: normal
severity: normal
status: open
title: xmlapp.py display bug when validate XML by DTD
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file37049/Tomcat.dtd

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

From report at bugs.python.org  Tue Oct 28 11:27:38 2014
From: report at bugs.python.org (Michael Cetrulo)
Date: Tue, 28 Oct 2014 10:27:38 +0000
Subject: [New-bugs-announce] [issue22751] Fix test___all__ warning about
	modified environment
Message-ID: <1414492058.43.0.353422984259.issue22751@psf.upfronthosting.co.za>


New submission from Michael Cetrulo:

The following warning is being generated when running test case:

  Warning -- locale was modified by test___all__

According to the comment there, importing the rlcompleter module changes (or used to change) the locale so after the import it was being set to 'C'

This patch reads the current locale before importing and resets it to that value afterwards.

----------
components: Tests
files: locale_envchange_patch.diff
keywords: patch
messages: 230136
nosy: Michael.Cetrulo, ezio.melotti
priority: normal
severity: normal
status: open
title: Fix test___all__ warning about modified environment
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37050/locale_envchange_patch.diff

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

From report at bugs.python.org  Tue Oct 28 15:26:38 2014
From: report at bugs.python.org (matrokhin oleg)
Date: Tue, 28 Oct 2014 14:26:38 +0000
Subject: [New-bugs-announce] [issue22752] incorrect time.timezone value
Message-ID: <1414506398.58.0.3585243804.issue22752@psf.upfronthosting.co.za>


New submission from matrokhin oleg:

There was timezone change in Russia at 26 october (http://www.timeanddate.com/time/change/russia/moscow)

But code in timemodule.c using first day of the year to get timezone
 
        t = (time((time_t *)0) / YEAR) * YEAR;
        p = localtime(&t);
        janzone = -p->tm_gmtoff;

so janzone have incorrect value (with old timezone)

----------
messages: 230153
nosy: errx
priority: normal
severity: normal
status: open
title: incorrect time.timezone value
type: behavior

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

From report at bugs.python.org  Tue Oct 28 15:47:08 2014
From: report at bugs.python.org (=?utf-8?b?SMOla2FuIEzDtnZkYWhs?=)
Date: Tue, 28 Oct 2014 14:47:08 +0000
Subject: [New-bugs-announce] [issue22753] urllib2 localnet Changed test to
	lookup IP-address of	localhost
Message-ID: <1414507628.78.0.884878705537.issue22753@psf.upfronthosting.co.za>


New submission from H?kan L?vdahl:

Running this test gave me an error: 
./python -m test -v test_urllib2_localnet

======================================================================
ERROR: test_proxy_qop_auth_works (test.test_urllib2_localnet.ProxyAuthTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/hakan/kod/cpython/cpython/Lib/urllib/request.py", line 1182, in do_open
    h.request(req.get_method(), req.selector, req.data, headers)
  File "/home/hakan/kod/cpython/cpython/Lib/http/client.py", line 1154, in request
    self._send_request(method, url, body, headers)
  File "/home/hakan/kod/cpython/cpython/Lib/http/client.py", line 1192, in _send_request
    self.endheaders(body)
  File "/home/hakan/kod/cpython/cpython/Lib/http/client.py", line 1150, in endheaders
    self._send_output(message_body)
  File "/home/hakan/kod/cpython/cpython/Lib/http/client.py", line 988, in _send_output
    self.send(msg)
  File "/home/hakan/kod/cpython/cpython/Lib/http/client.py", line 923, in send
    self.connect()
  File "/home/hakan/kod/cpython/cpython/Lib/http/client.py", line 900, in connect
    self.timeout, self.source_address)
  File "/home/hakan/kod/cpython/cpython/Lib/socket.py", line 710, in create_connection
    raise err
  File "/home/hakan/kod/cpython/cpython/Lib/socket.py", line 701, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

Changing "localhost" to "127.0.0.1" made the test pass. My friend puppet made a patch for it so it looks up the IP-address.

----------
components: Tests
messages: 230156
nosy: hakan
priority: normal
severity: normal
status: open
title: urllib2 localnet Changed test to lookup IP-address of localhost
versions: Python 3.5

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

From report at bugs.python.org  Tue Oct 28 19:04:40 2014
From: report at bugs.python.org (Aaron Klish)
Date: Tue, 28 Oct 2014 18:04:40 +0000
Subject: [New-bugs-announce] [issue22754] Implicit String Literal
	Concatenation Is Evil
Message-ID: <1414519480.06.0.561674688361.issue22754@psf.upfronthosting.co.za>


New submission from Aaron Klish:

Implicit string literal concatenation where
"string1" "string2"
becomes
"string1string2"
should be a language syntax error - not a feature.

This creates a silent error whenever someone builds a list of strings and forgets a comma.

I can't think of any good reason why the language supports this.  There are easier ways to build multi-line strings and there are already two explicit ways to do this on a single line.

It also violates the python principle:
"There should be one? and preferably only one ?obvious way to do it"

I realize changing this might break someone's code.  If that is a large concern, maybe the interpreter could support an option to enable/disable support for this.

----------
messages: 230163
nosy: aklish
priority: normal
severity: normal
status: open
title: Implicit String Literal Concatenation Is Evil
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Oct 28 23:40:52 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Tue, 28 Oct 2014 22:40:52 +0000
Subject: [New-bugs-announce] [issue22755] contextlib.closing documentation
	should use a new example
Message-ID: <1414536052.52.0.0865505363528.issue22755@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

urllib.request.urlopen() now always produces a context manager (either a HTTPResponse or addinfourl object). The example for contextlib.closing still uses urllib.request.urlopen as an example for the context manager wrapper, see

    https://docs.python.org/3/library/contextlib.html#contextlib.closing

This is confusing users that now expect the object not to be a context manager, see:

    http://stackoverflow.com/questions/26619404/with-and-closing-of-files-in-python

Can a different example be chosen?

----------
assignee: docs at python
components: Documentation
messages: 230184
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: contextlib.closing documentation should use a new example
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Oct 29 03:24:57 2014
From: report at bugs.python.org (Robert Collins)
Date: Wed, 29 Oct 2014 02:24:57 +0000
Subject: [New-bugs-announce] [issue22756] testAssertEqualSingleLine gives
	poor errors
Message-ID: <1414549497.69.0.925079174873.issue22756@psf.upfronthosting.co.za>


New submission from Robert Collins:

found while backporting unittest fixes.

The current test fails like so:
======================================================================
FAIL: testAssertEqualSingleLine (unittest2.test.test_case.Test_TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/robertc/work/unittest2.hg/unittest2/test/test_case.py", line 1014, in testAssertEqualSingleLine
    self.assertEqual(sample_text, revised_sample_text)
AssertionError: 'laden swallows fly slowly' != 'unladen swallows fly quickly'
- laden swallows fly slowly?                    ^^^^
+ unladen swallows fly quickly? ++                   ^^^^^


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/robertc/work/unittest2.hg/unittest2/test/test_case.py", line 1017, in testAssertEqualSingleLine
    self.assertTrue(sample_text_error == error)
AssertionError: False is not true


-> it shouldn't be using assertTrue.

----------
messages: 230194
nosy: rbcollins
priority: normal
severity: normal
status: open
title: testAssertEqualSingleLine gives poor errors

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

From report at bugs.python.org  Wed Oct 29 04:19:14 2014
From: report at bugs.python.org (Fay)
Date: Wed, 29 Oct 2014 03:19:14 +0000
Subject: [New-bugs-announce] [issue22757] TclStackFree: incorrect freePtr.
	Call out of sequence?
Message-ID: <1414552754.88.0.540025463882.issue22757@psf.upfronthosting.co.za>


New submission from Fay:

I have a code that graphs streaming data in a new window. If the cursor is within the graphing window and the cursor has been moved, the graphing window would crash and the message says that "python.exe has stopped working". In the CMD window, the following error is displayed:
"TclStackFree: incorrect freePtr. Call out of sequence?
This application has requested the Runtime to terminate it in an unusual way. 
Please contact the application's support team for more information." 
I've tried changing from python 2.7.7 to 2.7.8 and matplotlib-1.3.1 to 1.4.2. The problem persists in both cases.

----------
components: Library (Lib), Tkinter, Windows
messages: 230196
nosy: Charleston, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: TclStackFree: incorrect freePtr. Call out of sequence?
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 29 11:14:37 2014
From: report at bugs.python.org (Tim Graham)
Date: Wed, 29 Oct 2014 10:14:37 +0000
Subject: [New-bugs-announce] [issue22758] Regression in Python 3.2 cookie
	parsing
Message-ID: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za>


New submission from Tim Graham:

I noticed some failing Django tests on Python 3.2.6 the other day. The regression is caused by this change: https://github.com/python/cpython/commit/572d9c59a1441c6f8ffb9308824c804856020e31

Behavior before that commit (and on other version of Python even after that commit):

>>> from http.cookies import SimpleCookie
>>> SimpleCookie("Set-Cookie: foo=bar; Path=/")
<SimpleCookie: foo='bar'>

New broken behavior on Python 3.2.6:

>>> from http.cookies import SimpleCookie
>>> SimpleCookie("Set-Cookie: foo=bar; Path=/")
<SimpleCookie: >

Python 3.2.6 no longer accepts the "Set-Cookie: " prefix to BaseCookie.load:

>>> SimpleCookie("Set-Cookie: foo=bar; Path=/")
<SimpleCookie: >
>>> SimpleCookie("foo=bar; Path=/")
<SimpleCookie: foo='bar'>

This issue doesn't affect 2.7, 3.3, or 3.4 because of https://github.com/python/cpython/commit/b92e104dc57c37ddf22ada1c6e5380e09268ee93 (this commit wasn't backported to 3.2 because that branch is in security-fix-only mode).

I asked Berker about this and he suggested to create this issue and said, "If Georg is OK to backout the commit I can write a patch with additional test cases and commit it."

He also confirmed the regression as follows:

I've tested your example on Python 2.7.8, 3.2.6, 3.3.6, 3.4.2, 3.5.0 (all unreleased development versions - they will be X.Y.Z+1) and looks like it's a regression.

My test script is:

    try:
        from http.cookies import SimpleCookie
    except ImportError:
        from Cookie import SimpleCookie

    c = SimpleCookie("Set-Cookie: foo=bar; Path=/")
    print(c)

Here are the results:

Python 2.7.8:
Set-Cookie: foo=bar; Path=/

Python 3.5.0:
Set-Cookie: foo=bar; Path=/

Python 3.4.2:
Set-Cookie: foo=bar; Path=/

Python 3.3.6:
Set-Cookie: foo=bar; Path=/
[45602 refs]

Python 3.2.6:

[38937 refs]

----------
components: Library (Lib)
messages: 230200
nosy: Tim.Graham, berker.peksag, georg.brandl, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Regression in Python 3.2 cookie parsing
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Oct 29 16:30:32 2014
From: report at bugs.python.org (Hristo Venev)
Date: Wed, 29 Oct 2014 15:30:32 +0000
Subject: [New-bugs-announce] [issue22759] pathlib: Path.exists broken
Message-ID: <1414596632.63.0.58764649431.issue22759@psf.upfronthosting.co.za>


New submission from Hristo Venev:

$ touch a
c: stat("a/x", ...) -> errno=ENOTDIR
$ python
>>> pathlib.Path('a/x').exists()

This should return False and not throw an exception.

Patch not tested.

----------
files: py.patch
keywords: patch
messages: 230214
nosy: h.venev
priority: normal
severity: normal
status: open
title: pathlib: Path.exists broken
Added file: http://bugs.python.org/file37066/py.patch

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

From report at bugs.python.org  Wed Oct 29 16:35:07 2014
From: report at bugs.python.org (Michael Del Monte)
Date: Wed, 29 Oct 2014 15:35:07 +0000
Subject: [New-bugs-announce] [issue22760] re.sub does only first 16
	replacements if re.S is used
Message-ID: <1414596907.12.0.515901190995.issue22760@psf.upfronthosting.co.za>


New submission from Michael Del Monte:

Easily reproduced:

re.sub('x', 'a', "x"*20, re.S)

returns 'aaaaaaaaaaaaaaaaxxxx'

----------
components: Regular Expressions
messages: 230216
nosy: ezio.melotti, mgdelmonte, mrabarnett
priority: normal
severity: normal
status: open
title: re.sub does only first 16 replacements if re.S is used
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Oct 29 22:19:01 2014
From: report at bugs.python.org (yotamv)
Date: Wed, 29 Oct 2014 21:19:01 +0000
Subject: [New-bugs-announce] [issue22761] Catching StopIteraion inside list
	comprehension
Message-ID: <1414617541.45.0.218818215506.issue22761@psf.upfronthosting.co.za>


New submission from yotamv:

Inside a list comprehension expression, if a StopIteration exception is raised, the interpreter assumes the exception was raised by the object Iterated buy the list comprehension expression.

For example, this generator will never stop, and will keep returning empty tuples:

def izip(*args):
    iters = [iter(obj) for obj in args]
    while True:
        yield tuple(next(it) for it in iters)
x = izip([1,2],[3,4])
print(next(x)) #(1,3)
print(next(x)) #(2,4)
print(next(x)) #()

----------
components: Interpreter Core
messages: 230246
nosy: tomirendo
priority: normal
severity: normal
status: open
title: Catching StopIteraion inside list comprehension
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Oct 29 22:26:09 2014
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 29 Oct 2014 21:26:09 +0000
Subject: [New-bugs-announce] [issue22762] PyObject_Call called with an
	exception set while	displaying a traceback
Message-ID: <1414617969.36.0.329952012393.issue22762@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

To reproduce the crash run the following two-lines script and, at the fisrt (Pdb) prompt, remove the last line of this script (and the following empty lines if any):

import pdb; pdb.set_trace()
x = 1

then issue the 'quit' pdb command. This will cause an assert:

python: Objects/abstract.c:2079: PyObject_Call: Assertion `!PyErr_Occurred()' failed.
Aborted (core dumped)

A patch is attached.

----------
components: Interpreter Core
files: traceback.patch
keywords: patch
messages: 230247
nosy: xdegaye
priority: normal
severity: normal
status: open
title: PyObject_Call called with an exception set while displaying a traceback
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file37070/traceback.patch

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

From report at bugs.python.org  Thu Oct 30 04:13:07 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 30 Oct 2014 03:13:07 +0000
Subject: [New-bugs-announce] [issue22763] load_tests chaining into discover
	from non-discover	entry point gets top_level_dir wrong
Message-ID: <1414638787.38.0.74873076868.issue22763@psf.upfronthosting.co.za>


New submission from Robert Collins:

The following trivial chain-into-discover load_tests:
def load_tests(loader, tests, pattern):
    import os.path
    # top level directory cached on loader instance
    this_dir = os.path.dirname(__file__)
    return loader.discover(start_dir=this_dir, pattern=pattern)

Will work fine when that module was loaded by discover in the first place, but if the entry point was e.g. loader.loadTestsFromModule then it will fail because _top_level_dir starts None and is, if not supplied, inferred from start_dir.

One possible way to improve this would be to check for start_dir being a child of rather than just an exact match of, the elements of sys.path. This isn't complete of course, because individual packages can have their own path. And we also compare with top_level_dir to assess importability - but perhaps we can deprecate/ get rid of the top_level_dir concept entirely - it only has two functional uses: a) making it possible to import things when the path to be discovered isn't on sys.path yet, which could be done by the unittest front end, leaving the core API less complicated, and b) to map from paths back to modules which is complicated by the need to handle namespaces and other packages with multiple directories providing modules. (Because load_tests can chain into other directories that aren't under top_level_dir this same bug can show up in the inverse situation).

Another possibility would be to make a new api 'discover from a package' and split discover's internals into 'find packages' and then a chain call to this new api. I'm in favour of this latter approach because I think it will have less compromises and work better. It might also make it easier for us in fixing the rather ugly thing at the moment where discover('foo.bar') adds foo.bar to sys.path before figuring out that its a module dotted path, not a filesystem path.

----------
messages: 230253
nosy: rbcollins
priority: normal
severity: normal
status: open
title: load_tests chaining into discover from non-discover entry point gets top_level_dir wrong

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

From report at bugs.python.org  Thu Oct 30 10:57:45 2014
From: report at bugs.python.org (Robert Collins)
Date: Thu, 30 Oct 2014 09:57:45 +0000
Subject: [New-bugs-announce] [issue22764] object lifetime fragility in
	unittest tests
Message-ID: <1414663065.15.0.782385301612.issue22764@psf.upfronthosting.co.za>


New submission from Robert Collins:

test_assertRaises_frames_survival (unittest2.test.test_assertions.Test_Assertions
Depends on refcount behaviour to pass - adding a gc.collect() before the weakref checks is sufficient to fix things on pypy.

test_no_exception_leak (unittest2.test.test_case.Test_TestCase
similarly here adding a juidicious gc.collect solves the issue.

----------
messages: 230258
nosy: rbcollins
priority: normal
severity: normal
status: open
title: object lifetime fragility in unittest tests
versions: Python 3.5

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

From report at bugs.python.org  Thu Oct 30 12:51:46 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 30 Oct 2014 11:51:46 +0000
Subject: [New-bugs-announce] [issue22765] Fixes for test_gdb (first frame
	address, entry values)
Message-ID: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

The attached patch fixes two test_gdb problems that can occur under some circumstances:

- With new GDB (I think version >= 7.4.0, but I'm not sure about the precise version), GDB sometimes prints "entry-values" for variables, which can lead to failures like: "AssertionError: 'v at entry=()' != '()'". The cure for that is using "set print entry-values no" in GDB. I think this is also the root cause of issue 17126.

- While building on ppc64 little endian for Fedora, we experienced GDB printing program counter for the first frame, which breaks regular expressions matching in tests, e.g. instead of

#0 in PyObject_Print

the lines can look like

#0 0x00003fffb7dd1798 in PyObject_Print

I've talked to Fedora's GDB maintainer and I've been told that this can happen and it's not a GDB bug - GDB does not guarantee this. Therefore the second part of the attached patch turns printing program counters for *all* frames using "set print address off" to achieve same GDB output everywhere.

----------
components: Tests
files: test_gdb-ppc64le-and-entry-values-fix.patch
keywords: patch
messages: 230265
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Fixes for test_gdb (first frame address, entry values)
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file37073/test_gdb-ppc64le-and-entry-values-fix.patch

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

From report at bugs.python.org  Thu Oct 30 16:06:37 2014
From: report at bugs.python.org (Joshua Chin)
Date: Thu, 30 Oct 2014 15:06:37 +0000
Subject: [New-bugs-announce] [issue22766] collections.Counter's in-place
	operators should return	NotImplemented for unsupported types
Message-ID: <1414681597.28.0.694367413403.issue22766@psf.upfronthosting.co.za>


New submission from Joshua Chin:

Currently, in-place operations on 'collections.Counter' with unsupported types raises an 'AttributeError'.

Example:
>>> import collections
>>> counter = collections.Counter()
>>> counter += 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/collections/__init__.py", line 709, in __iadd__
    for elem, count in other.items():
AttributeError: 'int' object has no attribute 'items'

Instead, it should return 'NotImplemented' if 'other' is not a 'collections.Counter'

----------
components: Library (Lib)
files: counter.patch
keywords: patch
messages: 230271
nosy: Joshua.Chin
priority: normal
severity: normal
status: open
title: collections.Counter's in-place operators should return NotImplemented for unsupported types
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37075/counter.patch

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

From report at bugs.python.org  Thu Oct 30 17:35:50 2014
From: report at bugs.python.org (Tom Christie)
Date: Thu, 30 Oct 2014 16:35:50 +0000
Subject: [New-bugs-announce] [issue22767] `separators` argument to
	json.dumps() behaves	unexpectedly across 2.x vs 3.x
Message-ID: <1414686950.25.0.801159105863.issue22767@psf.upfronthosting.co.za>


New submission from Tom Christie:

This is one of those behavioural issues that is a borderline bug.

The seperators argument to `json.dumps()` behaves differently across python 2 and 3.

* In python 2 it should be provided as a bytestring, and can cause a UnicodeDecodeError otherwise.
* In python 3 it should be provided as unicode,and can cause a TypeError otherwise.

Examples:

    Python 2.7.2
    >>> print json.dumps({'snowman': '?'}, separators=(':', ','), ensure_ascii=False)
    {"snowman","?"}
    >>> print json.dumps({'snowman': '?'}, separators=(u':', u','), ensure_ascii=False)
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1: ordinal not in range(128)

And:

    Python 3.4.0
    >>> print(json.dumps({'snowman': '?'}, separators=(':', ','), ensure_ascii=False))
    {"snowman","?"}
    >>> print(json.dumps({'snowman': '?'}, separators=(b':', b','), ensure_ascii=False))
    <...>
    TypeError: sequence item 2: expected str instance, bytes found

Technically this isn't out of line with the documentation - in both cases it uses `separators=(':', ',')` which is indeed the correct type in both v2 and v3. However it's unexpected behaviour that it changes types between versions, without being called out.

Working on a codebase with `from __future__ import unicode_literals` this is particularly unexpected because we get a `UnicodeDecodeError` when running code that otherwise looks correct.

It's also slightly awkward to fix because it's a bit of a weird branch condition.

The fix would probably be to forcibly coerce it to the correct type regardless of if it is supplied as unicode or a bytestring, or at least to do so for python 2.7.

Possibly related to http://bugs.python.org/issue22701 but wasn't able to understand if that ticket was in fact a different user error.

----------
messages: 230274
nosy: Tom.Christie
priority: normal
severity: normal
status: open
title: `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Oct 30 19:18:56 2014
From: report at bugs.python.org (Mathieu Pasquet)
Date: Thu, 30 Oct 2014 18:18:56 +0000
Subject: [New-bugs-announce] [issue22768] Add a way to get the peer
	certificate of a SSL Transport
Message-ID: <1414693136.26.0.003644122895.issue22768@psf.upfronthosting.co.za>


New submission from Mathieu Pasquet:

Currently, the only workaround is to use transport._sock.getpeercert(True) on the Transport returned by loop.create_connection(), which is not something to be encouraged. It is useful to get such information, for example to perform a manual certificate check against a previously recorded certificate or hash.

I attached a trivial patch adding an extra 'peercert_bin' info, but I do not know if this is the right approach, as other issues of feature disparity might arise when more people try to switch to asyncio. Exposing a proxy SSLSocket object for read-only functions might be more beneficial.

----------
components: asyncio
files: peercert_bin.patch
keywords: patch
messages: 230281
nosy: gvanrossum, haypo, mathieui, yselivanov
priority: normal
severity: normal
status: open
title: Add a way to get the peer certificate of a SSL Transport
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37076/peercert_bin.patch

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

From report at bugs.python.org  Thu Oct 30 23:58:45 2014
From: report at bugs.python.org (David Durrett)
Date: Thu, 30 Oct 2014 22:58:45 +0000
Subject: [New-bugs-announce] [issue22769] Tttk tag_has() throws TypeError
	when called without item
Message-ID: <1414709925.15.0.196086635074.issue22769@psf.upfronthosting.co.za>


New submission from David Durrett:

Have only tried this on Python 2.7

To reproduce:

~~~~~
from Tkinter import *
import ttk

root = Tk()
tree = ttk.Treeview(root)

id = tree.insert('' , 'end', text='foo', tag='bar')
print tree.tag_has('bar', item=id)
# ^ this works..
print tree.tag_has('baz', item=id)
# ^ .. and this..
print tree.tag_has('bar')
# ^ .. this doesn't.
~~~~~
...
    self.tk.call(self._w, "tag", "has", tagname, item))
TypeError: must be string, not tuple

Possibly introduced by Issue20072.

Removing the self.tk.getboolean() wrapper in tag_has() appears to fix things.

----------
components: Tkinter
messages: 230305
nosy: ddurrett, gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tttk tag_has() throws TypeError when called without item
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Oct 31 00:05:44 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 30 Oct 2014 23:05:44 +0000
Subject: [New-bugs-announce] [issue22770] test_ttk_guionly and test_tk can
	cause Tk segfaults on	OS X when run with regrtest -j option
Message-ID: <1414710344.61.0.884489180713.issue22770@psf.upfronthosting.co.za>


New submission from Ned Deily:

The changes to tkinter tests introduced by the changes for Issue22236 (2.7 32fdaf401e50, 3.4 dd1dffe6f0d2, and default/3.5 014060738f7f) may cause Python to crash due to a Tk segfault on OS X.  The crash only shows up when using the -j option to regrtest and is dependent on other factors, e.g. 64-bit vs 32-bit and randomized address space allocations, so it is not 100% reproducible.  But it happens often enough (to me) when running the Python test suite from an installed framework location with a current Cocoa Tk 8.5.x or 8.6.x, for example, with an instance from a python.org binary installer:

    /usr/local/bin/python3.4 -m test -w -uall -j3

The reasons for the segfault are due to an arcane bug in Tk which shows up when Tcl interpreter instances are destroyed and created within the execution of an OS X app bundle, behavior which now happens as a result of the above changes when -j > 0 is used in an OS X framework build.  There is a more detailed analysis in the Tk bug I've opened:

    https://core.tcl.tk/tk/tktview?name=c18c36f80c

The bug is not one that most Tk users would run into, I think, so it's certainly not a critical bug in Tk.  But it is annoying to run into when running Python tests.  On the other hand, I'm not sure that it is worth trying to work around the problem in the tests; I think the basic idea of the Issue22236 changes is sound.

There is a relatively easy workaround if one runs into the problem: exclude the two problematic Tk tests and run them separately sequentially.

    pythonx.y -m test -w -uall -j3 -x test_tk test_ttk_guionly
    pythonx.y -m test -w -uall        test_tk test_ttk_guionly

(-m test.regrtest for Python 2.7.x)

It may be sufficient to just document the workaround here in case others run into it.

----------
components: Tests, Tkinter
messages: 230307
nosy: ned.deily, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_ttk_guionly and test_tk can cause Tk segfaults on OS X when run with regrtest -j option
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct 31 09:54:21 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 31 Oct 2014 08:54:21 +0000
Subject: [New-bugs-announce] [issue22771] shutil.make_archive() doesn't use
	its "verbose" argument
Message-ID: <1414745661.3.0.485255744856.issue22771@psf.upfronthosting.co.za>


New submission from Georg Brandl:

It seems like "verbose" should be passed to the archival function, but it isn't.

----------
components: Library (Lib)
messages: 230324
nosy: georg.brandl
priority: normal
severity: normal
status: open
title: shutil.make_archive() doesn't use its "verbose" argument
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Oct 31 13:02:26 2014
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 31 Oct 2014 12:02:26 +0000
Subject: [New-bugs-announce] [issue22772] doc error in __ifloordiv__ and
	__itruediv__
Message-ID: <1414756946.98.0.846704461281.issue22772@psf.upfronthosting.co.za>


New submission from Lorenz Quack:

the doc string of __itruediv__ and __ifloordiv__ represent the operator as x/y and x//y respectively.
This is obviously false and should be x/=y and x//=y

patch attached

----------
assignee: docs at python
components: Documentation
files: inplace_div_doc.patch
keywords: patch
messages: 230337
nosy: docs at python, donlorenzo
priority: normal
severity: normal
status: open
title: doc error in __ifloordiv__ and __itruediv__
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/file37083/inplace_div_doc.patch

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

From report at bugs.python.org  Fri Oct 31 15:01:28 2014
From: report at bugs.python.org (David Edelsohn)
Date: Fri, 31 Oct 2014 14:01:28 +0000
Subject: [New-bugs-announce] [issue22773] Export Readline version and expect
	ANSI sequence for	version < 0x6000
Message-ID: <1414764088.14.0.977066596578.issue22773@psf.upfronthosting.co.za>


New submission from David Edelsohn:

The patch for Issue19884 to set enable-meta-key to "off" does not work when readline-devel package is libreadline5, which includes SLES 11.

----------
components: Extension Modules
messages: 230340
nosy: David.Edelsohn, haypo, pitrou
priority: normal
severity: normal
status: open
title: Export Readline version and expect ANSI sequence for version < 0x6000

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

From report at bugs.python.org  Fri Oct 31 15:25:09 2014
From: report at bugs.python.org (=?utf-8?q?Szieberth_=C3=81d=C3=A1m?=)
Date: Fri, 31 Oct 2014 14:25:09 +0000
Subject: [New-bugs-announce] [issue22774] Weird S.rstrip() result
Message-ID: <1414765509.86.0.0341092418093.issue22774@psf.upfronthosting.co.za>


New submission from Szieberth ?d?m:

I just faced the following bug (v3.4.2):

>>> t1 = '#5 amarg (Concession)'
>>> t2 = '#6 ironman (Concession)'
>>> s = ' (Concession)'
>>> t1.rstrip(s)
'#5 amarg'
>>> t2.rstrip(s)
'#6 ironma'
>>> t1[:-len(s)]
'#5 amarg'
>>> t2[:-len(s)]
'#6 ironman'

----------
messages: 230343
nosy: SzieberthAdam
priority: normal
severity: normal
status: open
title: Weird S.rstrip() result
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Oct 31 17:58:03 2014
From: report at bugs.python.org (Tim Graham)
Date: Fri, 31 Oct 2014 16:58:03 +0000
Subject: [New-bugs-announce] [issue22775] SimpleCookie not picklable with
	HIGHEST_PROTOCOL
Message-ID: <1414774683.47.0.0600315909548.issue22775@psf.upfronthosting.co.za>


New submission from Tim Graham:

Expected:

>>> import pickle
>>> from http.cookies import SimpleCookie
>>> pickle.loads(pickle.dumps(SimpleCookie('hi=there'),2))
<SimpleCookie: hi='there'>
# Actual
<SimpleCookie: hi='Set-Cookie: hi=there'>

Patch is based on the suggestion from Georg Brandl in #22758 (I added the "else" as the fix did not work without it).

----------
components: Library (Lib)
files: cookie-pickle-highest.diff
keywords: patch
messages: 230354
nosy: Tim.Graham, berker.peksag, georg.brandl
priority: normal
severity: normal
status: open
title: SimpleCookie not picklable with HIGHEST_PROTOCOL
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file37088/cookie-pickle-highest.diff

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

From report at bugs.python.org  Fri Oct 31 19:13:10 2014
From: report at bugs.python.org (Yoel)
Date: Fri, 31 Oct 2014 18:13:10 +0000
Subject: [New-bugs-announce] [issue22776] SyslogHandler's record formatting
	during emit(..) not	covered by try-except block
Message-ID: <1414779190.8.0.640385408005.issue22776@psf.upfronthosting.co.za>


New submission from Yoel:

Not all exceptions occurring during SyslogHandler's emit(..) method are caught and handled since the try-except block only covers the latter part of the method.
Thus, since handleError is not invoked, such exceptions might cause the whole program to crash, even though logging.raiseExceptions is unset.

Execution example:

In [1]: import sys

In [2]: sys.version
Out[2]: '2.7.6 (default, Mar 22 2014, 22:59:56) \n[GCC 4.8.2]'

In [3]: import logging.handlers

In [4]: logging.raiseExceptions = 0

In [5]: syslogHandler = logging.handlers.SysLogHandler()

In [6]: logger = logging.getLogger()

In [7]: logger.addHandler(syslogHandler)

In [8]: logger.critical('1', '1')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-8-3d1c89a066c4> in <module>()
----> 1 logger.critical('1', '1')

/usr/lib/python2.7/logging/__init__.pyc in critical(self, msg, *args, **kwargs)
   1195         """
   1196         if self.isEnabledFor(CRITICAL):
-> 1197             self._log(CRITICAL, msg, args, **kwargs)
   1198 
   1199     fatal = critical

/usr/lib/python2.7/logging/__init__.pyc in _log(self, level, msg, args, exc_info, extra)
   1269                 exc_info = sys.exc_info()
   1270         record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra)
-> 1271         self.handle(record)
   1272 
   1273     def handle(self, record):

/usr/lib/python2.7/logging/__init__.pyc in handle(self, record)
   1279         """
   1280         if (not self.disabled) and self.filter(record):
-> 1281             self.callHandlers(record)
   1282 
   1283     def addHandler(self, hdlr):

/usr/lib/python2.7/logging/__init__.pyc in callHandlers(self, record)
   1319                 found = found + 1
   1320                 if record.levelno >= hdlr.level:
-> 1321                     hdlr.handle(record)
   1322             if not c.propagate:
   1323                 c = None    #break out

/usr/lib/python2.7/logging/__init__.pyc in handle(self, record)
    747             self.acquire()
    748             try:
--> 749                 self.emit(record)
    750             finally:
    751                 self.release()

/usr/lib/python2.7/logging/handlers.pyc in emit(self, record)
    840         exception information is present, it is NOT sent to the server.
    841         """
--> 842         msg = self.format(record) + '\000'
    843         """
    844         We need to convert record level to lowercase, maybe this will

/usr/lib/python2.7/logging/__init__.pyc in format(self, record)
    722         else:
    723             fmt = _defaultFormatter
--> 724         return fmt.format(record)
    725 
    726     def emit(self, record):

/usr/lib/python2.7/logging/__init__.pyc in format(self, record)
    462         it is formatted using formatException() and appended to the message.
    463         """
--> 464         record.message = record.getMessage()
    465         if self.usesTime():
    466             record.asctime = self.formatTime(record, self.datefmt)

/usr/lib/python2.7/logging/__init__.pyc in getMessage(self)
    326                     msg = self.msg      #Defer encoding till later
    327         if self.args:
--> 328             msg = msg % self.args
    329         return msg
    330 

TypeError: not all arguments converted during string formatting

In [9]: 

Executing similar code via StreamHandler for example, doesn't raise the TypeError exception.

----------
components: Library (Lib)
messages: 230364
nosy: Yoel, vinay.sajip
priority: normal
severity: normal
status: open
title: SyslogHandler's record formatting during emit(..) not covered by try-except block
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Oct 31 23:04:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 31 Oct 2014 22:04:53 +0000
Subject: [New-bugs-announce] [issue22777] Test pickling with all protocols
Message-ID: <1414793093.86.0.888366361477.issue22777@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some pickling tests use only default protocol. Other tests use only lower protocols (0, 1, and may be 2). Proposed match makes all pickling tests using all existing protocols from 0 to HIGHEST_PROTOCOL inclusive. Also fixed some minor bugs.

----------
components: Tests
files: tests_pickling.patch
keywords: patch
messages: 230395
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Test pickling with all protocols
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file37091/tests_pickling.patch

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

From report at bugs.python.org  Fri Oct 31 23:07:49 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Oct 2014 22:07:49 +0000
Subject: [New-bugs-announce] [issue22778] list's in-place add doesn't return
	NotImplemented when	appropriate
Message-ID: <1414793269.83.0.627145039019.issue22778@psf.upfronthosting.co.za>


New submission from Ethan Furman:

--> s = []
--> s += 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

For comparison, when NotImplemented is appropriately returned the message looks like this:

--> s -= 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for -=: 'list' and 'int'

Which is certainly more helpful than "<blank> object is not iterable"

----------
messages: 230396
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: list's in-place add doesn't return NotImplemented when appropriate
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Oct 31 23:14:36 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 31 Oct 2014 22:14:36 +0000
Subject: [New-bugs-announce] [issue22779] deque in-place addition does not
	return NotImplemented	when appropriate
Message-ID: <1414793676.66.0.938379315821.issue22779@psf.upfronthosting.co.za>


New submission from Ethan Furman:

--> from collections import deque
--> d = deque()
--> d += 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

deque should be returning NotImplemented, which would generate a more appropriate error message:

TypeError: unsupported operand type(s) for -=: 'collections.deque' and 'int'

which is what happens with -=, *=, /=, |=, at which point I stopped testing.

----------
assignee: rhettinger
messages: 230397
nosy: ethan.furman, rhettinger
priority: low
severity: normal
stage: needs patch
status: open
title: deque in-place addition does not return NotImplemented when appropriate
type: behavior
versions: Python 3.5

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