From report at bugs.python.org  Thu Aug  1 00:48:21 2013
From: report at bugs.python.org (Robin Schoonover)
Date: Wed, 31 Jul 2013 22:48:21 +0000
Subject: [New-bugs-announce] [issue18610] wsgiref.validator expects
	wsgi.input read to give	exactly one arg
Message-ID: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>


New submission from Robin Schoonover:

wsgiref.validator requires wsgi.input's read to always give EXACTLY one argument. This is incorrect.

It's own documentation says:
* That wsgi.input is used properly:
  - .read() is called with zero or one argument

PEP3333 says:
A server should allow read() to be called without an argument, and return the remainder of the client's input stream.

----------
components: Library (Lib)
files: wsgiref.patch
keywords: patch
messages: 194027
nosy: Robin.Schoonover
priority: normal
severity: normal
status: open
title: wsgiref.validator expects wsgi.input read to give exactly one arg
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31106/wsgiref.patch

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

From report at bugs.python.org  Thu Aug  1 11:50:44 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 01 Aug 2013 09:50:44 +0000
Subject: [New-bugs-announce] [issue18611] Mac: Some Python Launcher issues
Message-ID: <1375350644.84.0.910420929307.issue18611@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

There are some issues with the Python Launcher application:

1) There is a useless 'Help' menu, the application does not
   include help (removal is trivial and doesn't affect functionality)

2) The list of interpreters does not include the framework locations,
   only /usr/local, /usr and /sw (Fink).

   IMHO the factory default should only include the framework and
   system pythons.

3) Python Launcher should probably sniff the script for a '#!', if 
   only to detect if the script is python 2 or 3. 
   
   This may need to be an option, an the algoritm needs to be specified.
   Probably something like:

   - No #!: use app setting
   - #!/usr/bin/env ...: use '...' to determine python version, use
     app setting to find that. 
   
     Rationale: /usr/bin/env uses $PATH to find a binary, the value
     of $PATH for GUI apps cannot easily be changed by users (if at all,
     there used to be an environment.plist file but I haven't checked if
     thats still used by the system).  Therefore it is better to use
     an application setting for this.

   - #!/path/to/python: use that interpreter if it exists
     (not sure yet what should happen if that interpreter does not exist)

   This has several advantages over the current behavior:
   - Can use a single Python Launcher for python2 and python3 scripts
   - Works with virtualenv/pyvenv environments (assuming that the right
     path is used in the #! line)

See also the pep397 specification for the "py" launcher on windows, but I don't propose to add such a command-line tool to Mac installations, the normal Unix conventions work just fine for command-line use.

See als #5262

----------
assignee: ronaldoussoren
components: Macintosh
messages: 194041
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Mac: Some Python Launcher issues
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  1 13:23:32 2013
From: report at bugs.python.org (uglemat)
Date: Thu, 01 Aug 2013 11:23:32 +0000
Subject: [New-bugs-announce] [issue18612] More elaborate documentation on
	how list comprehensions	and generator expressions relate to
	each other
Message-ID: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>


New submission from uglemat:

Today there are list comprehensions, set comprehensions, dict comprehensions and then... there are generator expressions, which apparently was called 'generator comprehensions' in the original PEP, don't know why that was changed. Some questions arises:

 * Are generator expressions a type of list comprehension, or are generator expressions to be considered their own thing.

 * Does 'list comprehension' mean a type of comprehension that happens to return a list, or is it to be considered more of a general concept.

I usually talk about 'list comprehension' as a type of comprehension, and 'generator expression' as another type of comprehension, and after investigating whether or not that is correct I couldn't find an answer. On the wikipedia article on list comprension (http://en.wikipedia.org/wiki/List_comprehension#Python) they list generator expressions as well, indicating that it's a type of list comprehension. I think there's a lot of confusion to be had here, and that the documentation should clarify what exactly is meant by 'list comprehensions', regardless of what happens to be the case.

I haven't really a bug report before, so forgive me if I'm doing something wrong. :)

----------
assignee: docs at python
components: Documentation
messages: 194048
nosy: docs at python, uglemat
priority: normal
severity: normal
status: open
title: More elaborate documentation on how list comprehensions and generator expressions relate to each other
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug  1 14:01:51 2013
From: report at bugs.python.org (Laurent Fournier)
Date: Thu, 01 Aug 2013 12:01:51 +0000
Subject: [New-bugs-announce] [issue18613] wrong float minus op result
Message-ID: <1375358511.45.0.0761593009905.issue18613@psf.upfronthosting.co.za>


New submission from Laurent Fournier:

Python 3.3.1 (with GCC 4.7.3) on Linux

print (.3-.1)
0.199999999999999998

----------
messages: 194050
nosy: Laurent.Fournier
priority: normal
severity: normal
status: open
title: wrong float minus op result
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  1 15:54:05 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 01 Aug 2013 13:54:05 +0000
Subject: [New-bugs-announce] [issue18614] Enhanced \N{} escapes for Unicode
	strings
Message-ID: <1375365245.12.0.441428484785.issue18614@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

As per the discussion here:

http://mail.python.org/pipermail/python-ideas/2013-July/022419.html

\N{} escapes should support the Unicode code point notation U+xxxx (where there are four, five or six hex digits after the U+).

E.g. '\N{U+03BB}' => '?'

unicodedata.lookup should also support such numeric names, e.g.:

unicodedata.lookup('U+03BB') => '?'

As '+' is otherwise prohibited in Unicode character names, there should never be ambiguity between 'U+xxxx' as a code point and an actual name, and a single lookup function can handle both.

(See http://www.unicode.org/versions/Unicode6.2.0/ch04.pdf#G39 for details on characters allowed in names.)


Also add a function for the reverse

unicodedata.codepoint('?') => 'U+03BB'


def codepoint(c):
    return 'U+{:04X}'.format(ord(c))

----------
components: Unicode
messages: 194075
nosy: ezio.melotti, stevenjd
priority: normal
severity: normal
status: open
title: Enhanced \N{} escapes for Unicode strings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  1 17:17:55 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 01 Aug 2013 15:17:55 +0000
Subject: [New-bugs-announce] [issue18615] sndhdr.whathdr could return a
	namedtuple
Message-ID: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Both sndhdr.whathdr an sndhdr.what returns a tuple with various information, while it could return a namedtuple. I attached a patched for this, with tests as well.

----------
components: Library (Lib)
files: sndhdr.patch
keywords: patch
messages: 194080
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: sndhdr.whathdr could return a namedtuple
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31110/sndhdr.patch

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

From report at bugs.python.org  Thu Aug  1 17:56:02 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 01 Aug 2013 15:56:02 +0000
Subject: [New-bugs-announce] [issue18616] enable more ssl socket options
	with	get_server_certificate
Message-ID: <1375372562.92.0.356754094449.issue18616@psf.upfronthosting.co.za>


New submission from Derek Wilson:

ssl.get_server_certificate does not allow advanced options like what ciphers to use (for ssl2 for instance) or SNI for virtual hosts with multiple ssl sites on one IP address.

Adding **kwargs enables any current and future SSLSocket options to be passed along to the underlying connection. wrap_socket doesn't include all the options (npn and sni for instance), so I use SSLSocket instead.

----------
components: Extension Modules
files: ssl_get_server_certificate_kwargs.patch
keywords: patch
messages: 194083
nosy: underrun
priority: normal
severity: normal
status: open
title: enable more ssl socket options with get_server_certificate
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31111/ssl_get_server_certificate_kwargs.patch

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

From report at bugs.python.org  Thu Aug  1 18:58:37 2013
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 01 Aug 2013 16:58:37 +0000
Subject: [New-bugs-announce] [issue18617] TLS and Intermediate Certificates
Message-ID: <1375376317.99.0.429350247521.issue18617@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Currently the Python SSL module requires the full chain, including all intermediaries, to be served in order to validate a TLS connection. This isn't *wrong* however a number of folks have had issues trying to setup a custom PyPI index in pip due to missing them. The believed the problem with validation to be in pip/Python because it works in their browser.

Essentially browsers have the ability to download missing intermediate certs using an url found inside the AIA data. This is slow and isn't generally recommended that you rely on it for any particular site. However it does mean that TLS connections work in more situations.

At the least this should probably be documented, and possibly the Python library be enhanced to be more browser like in this regard.

----------
components: Library (Lib)
messages: 194088
nosy: dstufft
priority: normal
severity: normal
status: open
title: TLS and Intermediate Certificates
type: enhancement

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

From report at bugs.python.org  Thu Aug  1 19:47:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 17:47:43 +0000
Subject: [New-bugs-announce] [issue18618] Need an atexit.register equivalent
	that also works in	subinterps
Message-ID: <1375379263.55.0.273685957163.issue18618@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Callbacks registered with atexit.register() are only called at shutdown of the main interpreter. For some purposes (perhaps most of them, arguably), you actually want to execute the callbacks at subinterpreter shutdown too.

----------
messages: 194092
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: Need an atexit.register equivalent that also works in subinterps

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

From report at bugs.python.org  Thu Aug  1 20:20:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 18:20:15 +0000
Subject: [New-bugs-announce] [issue18619] atexit leaks callbacks in
	subinterpreters
Message-ID: <1375381215.71.0.728082521631.issue18619@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

atexit uses PEP 3121 module initialization, and by this scheme each subinterpreter gets a separate module state. However, atexit's m_free doesn't actually decref the callbacks: it only frees the callbacks array, thinking the callbacks were already decref'ed when run. This is ok at main interpreter shutdown, but not at subinterpreter shutdown (see issue 18618).

----------
components: Interpreter Core, Library (Lib)
messages: 194098
nosy: Robin.Schreiber, pitrou, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: atexit leaks callbacks in subinterpreters
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  1 22:30:44 2013
From: report at bugs.python.org (Chris Curvey)
Date: Thu, 01 Aug 2013 20:30:44 +0000
Subject: [New-bugs-announce] [issue18620] multiprocessing page leaves out
	important part of Pool	example
Message-ID: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>


New submission from Chris Curvey:

on http://docs.python.org/2/library/multiprocessing.html, there is a bit about how to use a Pool properly, which looks like this

pool = Pool(processes=4)              # start 4 worker processes
result = pool.apply_async(f, [10])

What this neglects to mention is that only one process will get any of the work.  If you really want four processes in the pool to work, you have to call apply_async four times.  For example:

results = []
pool = Pool(processes=4)
for i in xrange(4):
    results.append(pool.apply_async(f, [10]))

hat tip to http://stackoverflow.com/questions/12483512/python-multiprocessing-apply-async-only-uses-one-process

----------
assignee: docs at python
components: Documentation
messages: 194115
nosy: Chris.Curvey, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing page leaves out important part of Pool example
type: enhancement

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

From report at bugs.python.org  Thu Aug  1 22:49:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 20:49:56 +0000
Subject: [New-bugs-announce] [issue18621] site.py keeps too much stuff alive
	when it patches	builtins
Message-ID: <1375390196.76.0.0867903823381.issue18621@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The site module patches the builtins module unless Python is run with -S. Unfortunately, this means the builtins dict then keeps the site module globals alive until the end of interpreter shutdown, preventing the garbage collection of many other objects or modules.

Attached patch isolates those patched builtins inside a separate module "_sitebuiltins".

----------
components: Library (Lib)
files: sitebuiltins.patch
keywords: patch
messages: 194117
nosy: pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: site.py keeps too much stuff alive when it patches builtins
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31114/sitebuiltins.patch

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

From report at bugs.python.org  Thu Aug  1 23:04:17 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 01 Aug 2013 21:04:17 +0000
Subject: [New-bugs-announce] [issue18622] reset_mock on mock created by
	mock_open causes infinite	recursion
Message-ID: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za>


New submission from Michael Foord:

As reported at: http://code.google.com/p/mock/issues/detail?id=209

>>> from unittest import mock
[107971 refs]
>>> mock.mock_open
<function mock_open at 0x10cff9d20>
[107974 refs]
>>> a = mock.mock_open()
[109965 refs]
>>> a.reset_mock()
...

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 194119
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: reset_mock on mock created by mock_open causes infinite recursion
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug  2 00:12:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Aug 2013 22:12:27 +0000
Subject: [New-bugs-announce] [issue18623] Factor out the _SuppressCoreFiles
	context manager
Message-ID: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

_SuppressCoreFiles in test_subprocess is a useful facility for other tests, for instance test_faulthandler (which has its own logic) or test_capi (which actually happily dumps core in one of its subtests).
It could probably be factored out into test.support.

----------
components: Tests
keywords: easy
messages: 194125
nosy: ezio.melotti, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Factor out the _SuppressCoreFiles context manager
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 01:04:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 23:04:29 +0000
Subject: [New-bugs-announce] [issue18624] Add alias for iso-8859-8-i which
	is the same as	iso-8859-8
Message-ID: <1375398269.06.0.0330535739148.issue18624@psf.upfronthosting.co.za>


New submission from R. David Murray:

Emails and web pages may specify a character set of iso-8859-8-i, which has exactly the same code points as iso-8859-8. The -i has to do with how bi-directional text is handled, but doesn't affect the encoding: http://lists.w3.org/Archives/Public/www-validator/2001Apr/0008.html

----------
components: Unicode, email
keywords: easy
messages: 194134
nosy: barry, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add alias for iso-8859-8-i which is the same as iso-8859-8
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 01:54:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 01 Aug 2013 23:54:04 +0000
Subject: [New-bugs-announce] [issue18625] ks_c-5601-1987 is used by
	microsoft when it really means	cp949
Message-ID: <1375401244.03.0.758628896825.issue18625@psf.upfronthosting.co.za>


New submission from R. David Murray:

When Microsoft handles Korean text, it uses its own code page, cp949, which is a superset of ks_c-5601-1987.  But when talking to the rest of the world, it claims that the character set name is ks_c-5601-1987.  This means that text claimed to be in ks_c-5601-1987 in email messages (and probably on web pages) can't always be decoded using the codec that ks_c-5601-1987 maps to (euc_kr). [*]

This problem shows up in the real world in email.  If non euc_kr characters are used, email will try blow up when trying to decode the ostensibly ks_c-5601-1987 text.  (I'm not sure if it will also blow up trying to encode it, I'm not sure what characters the two codecs cover.)

I'm not sure what the best solution is, but one possibility would be to add a "fixup" table to email that would cause it to decode ostensibly ks_c-5601-1987 text using the cp949 codec.  Since cp949 is a superset, this should at least solve the input side.

[*] Some relevant standards discussion:
   
    http://lists.w3.org/Archives/Public/ietf-charsets/2001AprJun/0033.html

>From this, it isn't clear why we map ks_c-5601-1987 to euc_kr, since they at least appear to be different codecs.  I haven't looked at the relevant RFCs to see what the differences are, though.

----------
components: Unicode, email
messages: 194139
nosy: barry, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: ks_c-5601-1987 is used by microsoft when it really means cp949
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 05:12:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Aug 2013 03:12:40 +0000
Subject: [New-bugs-announce] [issue18626] Make "python -m inspect <name>"
	dump the source of a	module
Message-ID: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

"python -m inspect <name>" doesn't currently do anything.

It would be handy if this:

    python -m inspect site

Was roughly equivalent to:

    python -c "import inspect, site; print(inspect.getsource(site))"

Even better would be if it understood entry point notation so you could use "modname:qualname" to get the source code of a particular item within a module.

----------
components: Library (Lib)
messages: 194148
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make "python -m inspect <name>" dump the source of a module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 06:43:38 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 02 Aug 2013 04:43:38 +0000
Subject: [New-bugs-announce] [issue18627] Typo in Modules/hashlib.h
Message-ID: <1375418618.45.0.59595383081.issue18627@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Got typo in Modules/hashlib.h. See this patch for detail:

--- a/Modules/hashlib.h	Wed Jul 31 20:48:26 2013 -0400
+++ b/Modules/hashlib.h	Fri Aug 02 12:39:00 2013 +0800
@@ -2,7 +2,7 @@
 
 /*
  * Given a PyObject* obj, fill in the Py_buffer* viewp with the result
- * of PyObject_GetBuffer.  Sets and exception and issues a return NULL
+ * of PyObject_GetBuffer.  Sets an exception and issues a return NULL
  * on any errors.
  */
 #define GET_BUFFER_VIEW_OR_ERROUT(obj, viewp) do { \

----------
assignee: docs at python
components: Documentation
messages: 194151
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo in Modules/hashlib.h
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  2 06:49:44 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Aug 2013 04:49:44 +0000
Subject: [New-bugs-announce] [issue18628] PEP 8 and encodings
Message-ID: <1375418984.87.0.318628832877.issue18628@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Three related doc change proposals. The Versions only apply to the third as the first two are for PEP 8.

1. PEP 8 has a section entitled "Encodings (PEP 263)" with a link to the verbose PEP. I think it would be better if it were "Source Encoding" with a link to the 'current' Reference Manual section 2.1.4. Encoding declarations. The latter gets right to the point.

2. This section twice uses the informal and undefined term 'coding cookie'. It is not in the ref manual section above, nor in the glossary, nor in the index. (Dave Angel asked about the definition on python-list. Before searching on the web, he first thought it meant BOM.) I suggest changing "a coding cookie" to "an encoding declaration".

3. The index has several entries that begin with 'encode', including one that just says 'encodings'. The last is the one that points to 2.1.4., but one would only guess by process of elimination. I think 'encoding (source file)' or 'encoding declarations (source file)' would be clearer.

----------
assignee: docs at python
components: Documentation
messages: 194152
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: PEP 8 and encodings
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug  2 17:22:11 2013
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 02 Aug 2013 15:22:11 +0000
Subject: [New-bugs-announce] [issue18629] future division breaks timedelta
	division by integer
Message-ID: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone:

datetime.timedelta instances are divisible by integers on Python 2.7, but not when __future__.division has been turned on:


exarkun at top:~$ ~/Projects/cpython/2.7/python -c '
from datetime import timedelta
print timedelta(seconds=3) / 2
'
0:00:01.500000
exarkun at top:~$ ~/Projects/cpython/2.7/python -c '
from __future__ import division
from datetime import timedelta
print timedelta(seconds=3) / 2
'
Traceback (most recent call last):
  File "<string>", line 4, in <module>
TypeError: unsupported operand type(s) for /: 'datetime.timedelta' and 'int'
exarkun at top:~$ ~/Projects/cpython/2.7/python
Python 2.7.5+ (2.7:8205e72b5cfc, Aug  2 2013, 11:12:04) 

This presents a minor barrier to Python 3 transitions, since it prevents the use of __future__.division in a module trying to retain Python 2 compatibility where timedelta division is used.

----------
components: Library (Lib)
messages: 194181
nosy: exarkun
priority: normal
severity: normal
status: open
title: future division breaks timedelta division by integer
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  2 20:08:04 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:08:04 +0000
Subject: [New-bugs-announce] [issue18630] mingw: exclude unix only modules
Message-ID: <1375466884.41.0.796204643285.issue18630@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Build
files: 0013-MINGW-exclude-unix-only-modules.patch
keywords: patch
messages: 194191
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: exclude unix only modules
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31119/0013-MINGW-exclude-unix-only-modules.patch

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

From report at bugs.python.org  Fri Aug  2 20:11:37 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:11:37 +0000
Subject: [New-bugs-announce] [issue18631] mingw: setup msvcrt and _winapi
	modules
Message-ID: <1375467097.24.0.168691156888.issue18631@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Build
files: 0014-MINGW-setup-msvcrt-and-_winapi-modules.patch
keywords: patch
messages: 194192
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: setup msvcrt and _winapi modules
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31120/0014-MINGW-setup-msvcrt-and-_winapi-modules.patch

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

From report at bugs.python.org  Fri Aug  2 20:15:27 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:15:27 +0000
Subject: [New-bugs-announce] [issue18632] mingw: build extensions with GCC
Message-ID: <1375467327.02.0.323723692344.issue18632@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.
Now more simple version of previous patch.

----------
components: Build
files: 0015-MINGW-build-extensions-with-GCC.patch
keywords: patch
messages: 194193
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: build extensions with GCC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31121/0015-MINGW-build-extensions-with-GCC.patch

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

From report at bugs.python.org  Fri Aug  2 20:55:02 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 18:55:02 +0000
Subject: [New-bugs-announce] [issue18633] mingw: use Mingw32CCompiler as
	default compiler for	mingw* build
Message-ID: <1375469702.92.0.916914527806.issue18633@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved version based  on get_platform()

----------
components: Build, Cross-Build
files: 0016-MINGW-use-Mingw32CCompiler-as-default-compiler-for-m.patch
keywords: patch
messages: 194197
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: use Mingw32CCompiler as default compiler for  mingw* build
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31123/0016-MINGW-use-Mingw32CCompiler-as-default-compiler-for-m.patch

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

From report at bugs.python.org  Fri Aug  2 21:16:45 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:16:45 +0000
Subject: [New-bugs-announce] [issue18634] mingw find import library
Message-ID: <1375471005.24.0.423283634636.issue18634@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: required by setup.py on hosts with installed only shared (DLL) packages.

----------
components: Build, Cross-Build
files: 0017-MINGW-find-import-library.patch
keywords: patch
messages: 194198
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw find import library
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31124/0017-MINGW-find-import-library.patch

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

From report at bugs.python.org  Fri Aug  2 21:34:16 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 02 Aug 2013 19:34:16 +0000
Subject: [New-bugs-announce] [issue18635] Enum sets _member_type_ to
	instantiated values but not	the class
Message-ID: <1375472056.62.0.564467694147.issue18635@psf.upfronthosting.co.za>


New submission from Chris Lambacher:

It would be useful to set the discovered member_type to the Enum class and not just the instance. Attached is a patch to add _member_type_ to the enum_class.

----------
files: enum_member_type_on_class.patch
keywords: patch
messages: 194199
nosy: lambacck
priority: normal
severity: normal
status: open
title: Enum sets _member_type_ to instantiated values but not the class
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31125/enum_member_type_on_class.patch

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

From report at bugs.python.org  Fri Aug  2 21:35:16 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:35:16 +0000
Subject: [New-bugs-announce] [issue18636] mingw: setup _ssl module
Message-ID: <1375472116.92.0.328904140064.issue18636@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Build, Cross-Build, Extension Modules
files: 0018-MINGW-setup-_ssl-module.patch
keywords: patch
messages: 194200
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: setup _ssl module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31126/0018-MINGW-setup-_ssl-module.patch

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

From report at bugs.python.org  Fri Aug  2 21:38:29 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:38:29 +0000
Subject: [New-bugs-announce] [issue18637] mingw: export _PyNode_SizeOf as
	PyAPI for parser module
Message-ID: <1375472309.41.0.38535995821.issue18637@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules.

----------
components: Extension Modules, Interpreter Core
files: 0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch
keywords: patch
messages: 194201
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: export _PyNode_SizeOf as PyAPI for parser module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31127/0019-MINGW-export-_PyNode_SizeOf-as-PyAPI-for-parser-modu.patch

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

From report at bugs.python.org  Fri Aug  2 21:42:01 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:42:01 +0000
Subject: [New-bugs-announce] [issue18638] mingw: generalization of posix
	build in sysconfig.py
Message-ID: <1375472521.36.0.980902141673.issue18638@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved patch

----------
components: Build, Cross-Build
files: 0020-MINGW-generalization-of-posix-build-in-sysconfig.py.patch
keywords: patch
messages: 194202
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: generalization of posix build in sysconfig.py
versions: Python 3.4
Added file: http://bugs.python.org/file31128/0020-MINGW-generalization-of-posix-build-in-sysconfig.py.patch

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

From report at bugs.python.org  Fri Aug  2 21:45:43 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:45:43 +0000
Subject: [New-bugs-announce] [issue18639] mingw: avoid circular dependency
	from time module during	native build of extentions
Message-ID: <1375472743.5.0.167328971816.issue18639@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: patch is not required in cross-build environment.

----------
assignee: eric.araujo
components: Build, Distutils, Extension Modules
files: 0021-MINGW-avoid-circular-dependency-from-time-module-dur.patch
keywords: patch
messages: 194203
nosy: eric.araujo, rpetrov, tarek
priority: normal
severity: normal
status: open
title: mingw: avoid circular dependency from time module during native build of extentions
versions: Python 3.4
Added file: http://bugs.python.org/file31129/0021-MINGW-avoid-circular-dependency-from-time-module-dur.patch

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

From report at bugs.python.org  Fri Aug  2 21:49:19 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:49:19 +0000
Subject: [New-bugs-announce] [issue18640] mingw: generalization of posix
	build in	distutils/sysconfig.py
Message-ID: <1375472959.93.0.699092056169.issue18640@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved patch

----------
assignee: eric.araujo
components: Build, Cross-Build, Distutils, Extension Modules
files: 0022-MINGW-generalization-of-posix-build-in-distutils-sys.patch
keywords: patch
messages: 194204
nosy: eric.araujo, rpetrov, tarek
priority: normal
severity: normal
status: open
title: mingw: generalization of posix build in distutils/sysconfig.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31130/0022-MINGW-generalization-of-posix-build-in-distutils-sys.patch

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

From report at bugs.python.org  Fri Aug  2 21:52:05 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 02 Aug 2013 19:52:05 +0000
Subject: [New-bugs-announce] [issue18641] mingw: customize site
Message-ID: <1375473125.37.0.800889135942.issue18641@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Split of issue3871 - build core modules: improved patch

----------
components: Build, Cross-Build, Extension Modules
files: 0023-MINGW-customize-site.patch
keywords: patch
messages: 194205
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: customize site
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31131/0023-MINGW-customize-site.patch

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

From report at bugs.python.org  Sat Aug  3 13:53:07 2013
From: report at bugs.python.org (Al Korgun)
Date: Sat, 03 Aug 2013 11:53:07 +0000
Subject: [New-bugs-announce] [issue18642] enhancement for operator 'assert'
Message-ID: <1375530787.73.0.318484624842.issue18642@psf.upfronthosting.co.za>


New submission from Al Korgun:

It would be pretty good, if 'assert' could raise specified exception, like that:

>>> data = None
>>> assert isinstance(data, basestring), TypeError("'data' must be a string")

<s>AssertionError</s>TypeError: 'data' must be a string

----------
components: Interpreter Core
messages: 194250
nosy: WitcherGeralt
priority: normal
severity: normal
status: open
title: enhancement for operator 'assert'
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug  3 14:11:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 03 Aug 2013 12:11:35 +0000
Subject: [New-bugs-announce] [issue18643] implement socketpair() on Windows
Message-ID: <1375531895.31.0.501848123953.issue18643@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

socketpair() is quite useful, notably for tests.
Currently, it's not defined on Windows.
Since it's rather easy to implement, it would be nice to have it, if not in the stdlib, at least in test.support.

----------
components: Library (Lib)
messages: 194252
nosy: neologix, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: implement socketpair() on Windows
type: enhancement

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

From report at bugs.python.org  Sat Aug  3 15:45:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 03 Aug 2013 13:45:19 +0000
Subject: [New-bugs-announce] [issue18644] Got ResourceWarning: unclosed file
	when using test	function from formatter module
Message-ID: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

This python is compiled with --with-pydebug option.

[sky at localhost cpython]$ cat /tmp/a.txt
manly man likes cute cat.
[sky at localhost cpython]$ ./python
Python 3.4.0a0 (default:e408e821d6c8, Jul 27 2013, 10:49:54) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from formatter import test
>>> test('/tmp/a.txt')
manly man likes cute cat.
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/a.txt' mode='r' encoding='UTF-8'>
>>> 
[sky at localhost cpython]$ ./python Lib/formatter.py /tmp/a.txt
manly man likes cute cat.
Lib/formatter.py:445: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/a.txt' mode='r' encoding='UTF-8'>
  test()

----------
components: Tests
files: formatter_fix_resource_warning.patch
keywords: patch
messages: 194260
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got ResourceWarning: unclosed file when using test function from formatter module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31138/formatter_fix_resource_warning.patch

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

From report at bugs.python.org  Sat Aug  3 22:41:43 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 03 Aug 2013 20:41:43 +0000
Subject: [New-bugs-announce] [issue18645] Add a configure option for
	performance guided	optimization
Message-ID: <1375562503.45.0.752070512413.issue18645@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

We can make it easier for users make custom, high-performance builds tailored to their actual use cases.

Here's an example of how Firefox does it:

https://developer.mozilla.org/en-US/docs/Building_with_Profile-Guided_Optimization

----------
components: Build
messages: 194295
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add a configure option for performance guided optimization
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug  3 22:42:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 20:42:06 +0000
Subject: [New-bugs-announce] [issue18646] Improve tutorial entry on 'Lambda
	Forms'.
Message-ID: <1375562526.59.0.207872880438.issue18646@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

[0. On mailing lists, 'lambda expression' is used rather than 'lambda form'. Docs use both. Consistency across docs is a broader issue than this one. So leave title alone for this one.]

1. (first sentence) "By popular demand, a few features commonly found in functional programming languages like Lisp have been added to Python." (in early Python 1!) I think this should just be deleted. See 4. below as a replacement.

2. " With the lambda keyword, small anonymous functions can be created."
Change to
"Small anonymous functions can be created with the lambda keyword."

3. change "Here?s a function that returns" to "This function returns"

3.5 add a sentence about the different between def and lambda (the name attribute.

4. Add sentences about the purposes of lambda. Add an example that illustrates passing functions. 

>>> pairs = [(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
>>> pairs.sort(key=lambda pair: pair[1])
>>> pairs
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]

----------
assignee: docs at python
components: Documentation
files: tut-lambda.diff
keywords: patch
messages: 194296
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Improve tutorial entry on 'Lambda Forms'.
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31142/tut-lambda.diff

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

From report at bugs.python.org  Sat Aug  3 22:42:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Aug 2013 20:42:07 +0000
Subject: [New-bugs-announce] [issue18647] re.error: nothing to repeat
Message-ID: <1375562527.29.0.365652198395.issue18647@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Now all doctests failed on 32-bit platforms due to the unlucky coincidence of my patch with at least two bugs which were hided before.

SubPattern.getwidth() is wrong, it truncates resulted values to sys.maxsize (should be MAXREPEAT). As side effect of my patch (on 32-bit MAXREPEAT == sys.maxsize) it now returns correct value in some cases on 32-bit platforms. On other hand, the _simple() function in sre_compile.py checks if getwidth() returns (0, MAXREPEAT) and raise an error in such case. Perhaps it should guards against such patterns as '(x*)*' (but it doesn't guards against '(x*y?)*' or '(x*y*)*' and can raise false positive). Now getwidth() returns (0, MAXREPEAT) for '(x*y?)*' on 32-bit platforms (this is a correct result) and triggers the check. The doctest module uses regular expression pattern '(?:.*$\n?)*' which now causes an error.

Definitely SubPattern.getwidth() is wrong and should be fixed. At least one of two, the _simple() function or doctest pattern should be fixed too. The simplest fix is disable the 'nothing to repeat' check.

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
messages: 194297
nosy: ezio.melotti, larry, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: re.error: nothing to repeat
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug  3 22:58:16 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Aug 2013 20:58:16 +0000
Subject: [New-bugs-announce] [issue18648] FP Howto and the PEP 8 lambda
	guildline
Message-ID: <1375563496.73.0.458556999556.issue18648@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Functional Programming HowTo, near the end, has a section
Small functions and the lambda expression
http://docs.python.org/3/howto/functional.html#small-functions-and-the-lambda-expression

To illustrate, it starts with
  adder = lambda x, y: x+y
  print_assign = lambda name, value: name + '=' + str(value)
which are now proscribed by PEP 8. "Always use a def statement instead of an assignment statement that binds a lambda expression directly to a name."

The text goes on to give the def equivalents and to discourage lambdas. "Which alternative is preferable? That?s a style question; my usual course is to avoid using lambda." But I think the section should instead start with lambda examples that would be acceptable in the stdlib.

----------
messages: 194301
nosy: akuchling, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: FP Howto and the PEP 8 lambda guildline
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Aug  4 00:00:42 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 03 Aug 2013 22:00:42 +0000
Subject: [New-bugs-announce] [issue18649] list2cmdline function in
	subprocess module handles \"	sequence wrong
Message-ID: <1375567242.02.0.673942606159.issue18649@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

According to the docstring of list2cmdline function in subprocess module the sequence of a backslash followed by a double quote mark should denote double quote mark in the output string. However it's not the case

Python 2.7.4 (default, Apr  6 2013, 19:55:15) [MSC v.1500 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import subprocess
    >>> print subprocess.list2cmdline(r'\"1|2\"')
    \ \" 1 | 2 \ \"

The same behavior is in Python 3.3.1.

See "On Windows, how can I protect arguments to shell scripts using Python 2.7 subprocess?"(http://stackoverflow.com/q/4970194/95735) question on Stack Overflow.

----------
components: Library (Lib)
messages: 194307
nosy: Arve.Knudsen, exarkun, piotr.dobrogost, r.david.murray
priority: normal
severity: normal
status: open
title: list2cmdline function in subprocess module handles \" sequence wrong
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Aug  4 00:06:03 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Aug 2013 22:06:03 +0000
Subject: [New-bugs-announce] [issue18650] intermittent test_pydoc failure on
	3.4.0a1
Message-ID: <1375567563.7.0.0482703899635.issue18650@psf.upfronthosting.co.za>


New submission from Ned Deily:

Testing the 3.4.0a1 OS X 10.6 installer on OS X 10.8, I've now seen test_pydoc fail twice when the tests are run in order but then passing when the test is automatically rerun.  I've not seen this failure previously.

/usr/local/bin/python3.4 -m test -w -uall,-largefile== CPython 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug 3 2013, 14:03:34) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
==   Darwin-12.5.0-x86_64-i386-32bit little-endian
==   /private/var/folders/42/hjgpmmxd2wbcrzh4r9vsk_6h0000gr/T/test_python_3742
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)
[  1/376] test_grammar
...
[250/376] test_pyclbr
[251/376] test_pydoc
test test_pydoc failed -- Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_pydoc.py", line 624, in test_url_requests
    self.assertEqual(result, title, text)
AssertionError: 'Pydoc: Error - ' != 'Pydoc: Index of Modules'
- Pydoc: Error -
+ Pydoc: Index of Modules
 : <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Pydoc: Error - </title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link rel="stylesheet" type="text/css" href="pydoc_data/_pydoc.css"></head><body bgcolor="#f0f0f8">
            <div style='float:left'>
                Python 3.4.0a1 [v3.4.0a1:46535f65e7f3, GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]<br>Darwin-12.5.0
            </div>
            <div style='float:right'>
                <div style='text-align:center'>
                  <a href="index.html">Module Index</a>
                  : <a href="topics.html">Topics</a>
                  : <a href="keywords.html">Keywords</a>
                </div>
                <div>
                    <form action="get" style='display:inline;'>
                      <input type=text name=key size=15>
                      <input type=submit value="Get">
                    </form>&nbsp;
                    <form action="search" style='display:inline;'>
                      <input type=text name=key size=15>
                      <input type=submit value="Search">
                    </form>
                </div>
            </div>
            <div style="clear:both;padding-top:.5em;">
<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="heading">
<tr bgcolor="#7799ee">
<td valign=bottom>&nbsp;<br>
<font color="#ffffff" face="helvetica, arial">&nbsp;<br><big><big><strong>Error</strong></big></big></font></td
><td align=right valign=bottom
><font color="#ffffff" face="helvetica, arial">&nbsp;</font></td></tr></table>
    <p>
<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="section">
<tr bgcolor="#bb0000">
<td colspan=3 valign=bottom>&nbsp;<br>
<font color="#ffffff" face="helvetica, arial"><big><strong></strong></big></font></td></tr>

<tr><td bgcolor="#bb0000"><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</tt></td><td>&nbsp;</td>
<td width="100%">KeyError: '/Users/pyi/Library/Python/3.4/lib/python/site-packages/setuptools-0.9.8-py3.4.egg'
</td></tr></table></div>
</body></html>

[252/376/1] test_pyexpat
...
Re-running failed tests in verbose mode
Re-running test 'test_pydoc' in verbose mode
...
test_url_requests (test.test_pydoc.PydocUrlHandlerTest) ... ok
test_keywords (test.test_pydoc.TestHelper) ... ok

----------------------------------------------------------------------
Ran 25 tests in 2.253s

OK

----------
components: Tests
messages: 194309
nosy: ned.deily
priority: normal
severity: normal
status: open
title: intermittent test_pydoc failure on 3.4.0a1
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  4 12:07:05 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 04 Aug 2013 10:07:05 +0000
Subject: [New-bugs-announce] [issue18651] test failures on KFreeBSD
Message-ID: <1375610825.98.0.456814475805.issue18651@psf.upfronthosting.co.za>


New submission from Matthias Klose:

Some tests fail on KFreeBSD, attaching a first patch from Petr Salinger. 

see http://bugs.debian.org/708653 for further issues.

Ronald, could you check if that this works for OSX too?

----------
components: Tests
files: kfreebsd.diff
keywords: patch
messages: 194336
nosy: doko, ronaldoussoren
priority: normal
severity: normal
status: open
title: test failures on KFreeBSD
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31148/kfreebsd.diff

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

From report at bugs.python.org  Sun Aug  4 12:08:54 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 04 Aug 2013 10:08:54 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue18652=5D_Add_a_=E2=80=9Cfir?=
 =?utf-8?q?st=E2=80=9D_function_to_the_stdlib?=
Message-ID: <1375610934.97.0.503658757825.issue18652@psf.upfronthosting.co.za>


New submission from Hynek Schlawack:

Let met try to get you sold on adding the ?first? function I released on PyPI roughly a year ago:

https://github.com/hynek/first

It?s a very nice complement to functions like `any()` or itertools. I consists effectively of 9 lines of code but it proved extremely handy in production.

***

It returns the first true value from an iterable or a default:

>>> first([0, None, False, [], (), 42])
42

>>> first([0, None, False, [], ()], default=42)
42

Additionally it also allows for a key function:

>>> first([1, 1, 3, 4, 5], key=lambda x: x % 2 == 0)
4

***

First happens to be especially useful together with the re module:

import re

from first import first


re1 = re.compile('b(.*)')
re2 = re.compile('a(.*)')

m = first(regexp.match('abc') for regexp in [re1, re2])
if not m:
   print('no match!')
elif m.re is re1:
   print('re1', m.group(1))
elif m.re is re2:
   print('re2', m.group(1))


All the knee-jerk alternatives to it have some shortcomings:

next(itertools.ifilter(None, (regexp.match('abc') for regexp in [re1, re2])), None)
next((regexp.match('abc') for regexp in [re1, re2] if regexp.match('abc')), None)

None of them is Pythonic and the second one even has to call match() twice, which is *not* a cheap method to call.

Here the first version for comparison again:

first(regexp.match('abc') for regexp in [re1, re2])

It doesn?t even exhaust the iterator if not necessary.

***

I don?t cling to neither the name or the exact function signature (although it got polished with the help of several people, two of them core developers).  I also don?t really care whether it gets added along of any() or put into itertools.  I just know that I and several other people would appreciate to have such a handy function in the stdlib ? I even got an e-mail from OpenStack folks asking when it will be added because they would like to use it and there?s even a debian package by now: http://packages.debian.org/unstable/python-first

There?s also this question on StackOverflow: http://stackoverflow.com/questions/1077307/why-is-there-no-firstiterable-built-in-function-in-python which is nice but doesn?t fix the subtleties like when there is no true value etc which makes it useless for production code and one has to write boilerplate code every single time.

It was even one of five Python packages Lukasz Langa deemed worthy to be highlighted in his PyCon 2013 lightning talk: http://youtu.be/1vui-LupKJI?t=20m40s

FWIW, SQL has a similar function called COALESCE ( https://en.wikipedia.org/wiki/Null_(SQL)#COALESCE ) which only handles NULL though.

***

I?ll happily respond to any questions or concerns that may arise and supply a patch as soon as we agree on a place to add it.

----------
assignee: hynek
components: Library (Lib)
messages: 194338
nosy: hynek, lukasz.langa, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Add a ?first? function to the stdlib
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  4 14:35:20 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 12:35:20 +0000
Subject: [New-bugs-announce] [issue18653] mingw-meta: build core modules
Message-ID: <1375619720.06.0.766677441218.issue18653@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

split of issue3871 - this is meta issue only for part related to build core. Remark: build of interpreter core is in issue17605 .

Now split is:
- 01 issue13756 : Python make fail on cygwin
- 02 issue17219 : add current dir in library path if building python standard extensions
- 03 issue6672   : Add Mingw recognition to pyport.h to allow building extensions
- 04 issue18485 : configure for shared build
- 05 issue18486 : dynamic loading support
- 06 issue18487 : implement exec prefix
- 07 issue18495 : ignore main program for frozen scripts
- 08 issue18496 : setup exclude termios module
- 09 issue18497 : setup _multiprocessing module
- 10 issue18498 : setup select module
- 11 issue18499 : setup _ctypes module with system libffi
- 12 issue18500 : defect winsock2 and setup _socket module
- 13 issue18630 : exclude unix only modules
- 14 issue18631 : setup msvcrt and _winapi modules
- 15 issue18632 : build extensions with GCC
- 16 issue18633 : use Mingw32CCompiler as default compiler for mingw* build
- 17 issue18634 : find import library
- 18 issue18636 : setup _ssl module
- 19 issue18637 : export _PyNode_SizeOf as PyAPI for parser module
- 20 issue18638 : generalization of posix build in sysconfig.py
- 21 issue18639 : avoid circular dependency from time module during native build of extentions
- 22 issue18640 : generalization of posix build in distutils/sysconfig.py
- 23 issue18641 : customize site
- 24 after above patches user must regenerate configure script.

Hints:
a) at configure time define environment variable CPPFLAGS with minimum supported version like this   "-DWINVER=0x501 -D_WIN32_WINNT=0x501  -DMS_COREDLL=1", i.e XP is now minimum. MS_COREDLL is required for ctype module
b) at configure time define environment variable CCSHARED with minimum supported version like this: "-DWINVER=0x501 -D_WIN32_WINNT=0x501". Remark use same values as CPPFLAGS
c) use --without-libm
d) use --enable-shared
e) use --with-system-ffi

----------
components: Build, Cross-Build, Extension Modules
messages: 194358
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw-meta: build core modules
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug  4 15:05:00 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 04 Aug 2013 13:05:00 +0000
Subject: [New-bugs-announce] [issue18654] modernize mingw&cygwin compiler
	classes
Message-ID: <1375621500.14.0.511859388859.issue18654@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Python mingw and cygwin compiler classes tests for outdated features. Also python code set some flags like zero optimization level and etc. that prevent users to build optimized python or even worse build to fail.

This issue is part of split of issue3871 with clean-up and enhancements:
- archive contain set of 10 patches - remove of outdated (15 years old !!!!) features one by one.
- enhance unix compiler customization with mingw and cygwin compilers

----------
assignee: eric.araujo
components: Build, Cross-Build, Distutils
files: modernize-mingw+cygwin-compiler-class.tar.gz
messages: 194363
nosy: eric.araujo, rpetrov, tarek
priority: normal
severity: normal
status: open
title: modernize mingw&cygwin compiler classes
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31151/modernize-mingw+cygwin-compiler-class.tar.gz

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

From report at bugs.python.org  Sun Aug  4 15:49:14 2013
From: report at bugs.python.org (netrick)
Date: Sun, 04 Aug 2013 13:49:14 +0000
Subject: [New-bugs-announce] [issue18655] GUI apps take long to launch on
	Windows
Message-ID: <1375624154.73.0.44206476328.issue18655@psf.upfronthosting.co.za>


New submission from netrick:

On both Python 2 or 3, when you have GUI app (for example something in pygame or pyside or tk), when you launch it on Windows it takes about 4-6 seconds to display the Window for the first run. The next runs are faster, but only untill you reboot the PC.

The thing is that on Linux even when launching the script for first time ever, the GUI Window shows instantly. 

Something how Python displays windows on Windows is wrong, there is something that causes the serious lag.

You can see it very easy with IDLE. On Linux it launches instantly, on Windows XP on the same PC takes about 6 seconds to launch. I asked other people with different config and they have the same issue on Windows.

----------
components: Windows
messages: 194374
nosy: netrick
priority: normal
severity: normal
status: open
title: GUI apps take long to launch on Windows
type: performance
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Aug  4 18:55:25 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Aug 2013 16:55:25 +0000
Subject: [New-bugs-announce] [issue18656] setting function.__name__ doesn't
	affect repr()
Message-ID: <1375635325.22.0.0227611021818.issue18656@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

In Python 3.2 and earlier:

>>> def f(): pass
...
>>> f.__name__ = 'g'
>>> f
<function g at 0x100487628>

However in Python 3.3 and later, the last line shows 'f' instead of 'g'.

----------
components: Interpreter Core
messages: 194394
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: setting function.__name__ doesn't affect repr()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Aug  4 21:31:04 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 04 Aug 2013 19:31:04 +0000
Subject: [New-bugs-announce] [issue18657] Remove duplicate ACKS entries
Message-ID: <1375644664.94.0.607349544003.issue18657@psf.upfronthosting.co.za>


New submission from Madison May:

The title says it all.  I used collections.Counter to check for duplicates in ACKS and cleaned up a few double entries.

----------
assignee: docs at python
components: Documentation
messages: 194410
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Remove duplicate ACKS entries
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Aug  5 03:48:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 01:48:24 +0000
Subject: [New-bugs-announce] [issue18658] Mercurial CPython log ticket link
	is broken
Message-ID: <1375667304.35.0.50370358918.issue18658@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Go to http://hg.python.org/cpython.

All ticket links (number preceded by #), such as #18567 refer to bugs in jython.

For example:
5 hours ago 	R David Murray 	Merge: #18657: remove duplicate entries from Misc/ACKS.default tip
5 hours ago 	R David Murray 	#18657: remove duplicate entries from Misc/ACKS.3.3

The "Merge" link refers to correct place. But "#18657" goes to http://bugs.jython.org/issue18657.

It happens to *all ticket links*.

----------
messages: 194444
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Mercurial CPython log ticket link is broken

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

From report at bugs.python.org  Mon Aug  5 10:03:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 08:03:10 +0000
Subject: [New-bugs-announce] [issue18659] test_precision in test_format.py
	is not executed and has	unused variable
Message-ID: <1375689790.25.0.721615428383.issue18659@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is test_precision in Lib/test_format.py which is not being unit tested.

Also, there is a unused variable inside test_precision.

Attached the patch to fix these problems.

----------
components: Tests
files: test_precision.patch
keywords: patch
messages: 194459
nosy: vajrasky
priority: normal
severity: normal
status: open
title: test_precision in test_format.py is not executed and has unused variable
versions: Python 3.4
Added file: http://bugs.python.org/file31162/test_precision.patch

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

From report at bugs.python.org  Mon Aug  5 10:47:31 2013
From: report at bugs.python.org (Louis RIVIERE)
Date: Mon, 05 Aug 2013 08:47:31 +0000
Subject: [New-bugs-announce] [issue18660] os.read behavior on Linux
Message-ID: <1375692451.71.0.0379690285011.issue18660@psf.upfronthosting.co.za>


New submission from Louis RIVIERE:

A call to os.read that used to work on older Linux kernel, doesn't anymore with newer Linux kernel.
As a workaroud we can use libc.read (ctypes) instead of os.read.
But I feel like os.read should work, as it used to.

The code (and comments) can be seen here : http://code.activestate.com/recipes/576375-low-level-inotify-wrapper/

----------
components: IO
messages: 194461
nosy: dugres
priority: normal
severity: normal
status: open
title: os.read behavior on Linux
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug  5 11:43:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 05 Aug 2013 09:43:08 +0000
Subject: [New-bugs-announce] [issue18661] Typo in grpmodule.c
Message-ID: <1375695788.15.0.911930238621.issue18661@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I guess, there is a typo in Modules/grpmodule.c. See the patch below:

diff -r f4f81ebc3de9 Modules/grpmodule.c
--- a/Modules/grpmodule.c	Sun Aug 04 15:50:08 2013 -0400
+++ b/Modules/grpmodule.c	Mon Aug 05 17:40:33 2013 +0800
@@ -10,7 +10,7 @@
    {"gr_name", "group name"},
    {"gr_passwd", "password"},
    {"gr_gid", "group id"},
-   {"gr_mem", "group memebers"},
+   {"gr_mem", "group members"},
    {0}
 };

I am not sure whether the line after typo should be {0} or {0, 0}.

----------
assignee: docs at python
components: Documentation
messages: 194465
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo in grpmodule.c
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug  5 19:10:44 2013
From: report at bugs.python.org (James Laver)
Date: Mon, 05 Aug 2013 17:10:44 +0000
Subject: [New-bugs-announce] [issue18662] re.escape should not escape the
	hyphen
Message-ID: <1375722644.22.0.61356481393.issue18662@psf.upfronthosting.co.za>


New submission from James Laver:

Traceback (most recent call last):
  File "/Users/jlaver/retest.py", line 6, in test_escape
    self.assertEquals(re.escape('-'), '-')
AssertionError: '\\-' != '-'

The only place you can do bad things with hyphens is in a character class. I fail to see how you'd be in the situation of wanting to use escape()d data in a character class. Even if I could think of a reason to do that, it's decidedly not the usual case.

It's http://bugs.python.org/issue2650 all over again, just with a different character (in that case, underscore).

While we're at it, what else shouldn't it be escaping?

----------
components: Regular Expressions
files: rebugtest.py
messages: 194495
nosy: ezio.melotti, jjl, mrabarnett
priority: normal
severity: normal
status: open
title: re.escape should not escape the hyphen
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31166/rebugtest.py

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

From report at bugs.python.org  Mon Aug  5 19:53:10 2013
From: report at bugs.python.org (py.user)
Date: Mon, 05 Aug 2013 17:53:10 +0000
Subject: [New-bugs-announce] [issue18663] In
	unittest.TestCase.assertAlmostEqual doc specify the	delta
	description
Message-ID: <1375725190.79.0.442588525807.issue18663@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual
"If delta is supplied instead of places then the difference between first and second must be less (or more) than delta."

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 194498
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestCase.assertAlmostEqual doc specify the delta description
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31167/issue.diff

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

From report at bugs.python.org  Tue Aug  6 00:19:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Aug 2013 22:19:25 +0000
Subject: [New-bugs-announce] [issue18664] occasional test_threading failure
Message-ID: <1375741165.75.0.0273425053979.issue18664@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1021

======================================================================
FAIL: test_finalize_with_trace (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\test_threading.py", line 323, in test_finalize_with_trace
    """)
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\script_helper.py", line 54, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\script_helper.py", line 46, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 3, stderr follows:
Assertion failed: !PyErr_Occurred(), file ..\Objects\object.c, line 451
Fatal Python error: Aborted

Thread 0x00000e14:
  File "<string>", line 8 in killer
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\threading.py", line 599 in run
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\threading.py", line 642 in _bootstrap_inner
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\threading.py", line 619 in _bootstrap

Current thread 0x000006c4:

----------
components: Interpreter Core, Tests
messages: 194517
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: occasional test_threading failure
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 06:53:20 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 04:53:20 +0000
Subject: [New-bugs-announce] [issue18665] Typos in frame object related code
Message-ID: <1375764800.58.0.482122024787.issue18665@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

See the patch for details:

diff -r 438cdc97d8ee Include/frameobject.h
--- a/Include/frameobject.h	Mon Aug 05 23:35:43 2013 +0200
+++ b/Include/frameobject.h	Tue Aug 06 12:38:15 2013 +0800
@@ -36,7 +36,7 @@
            non-generator frames. See the save_exc_state and swap_exc_state
            functions in ceval.c for details of their use. */
     PyObject *f_exc_type, *f_exc_value, *f_exc_traceback;
-    /* Borrowed referenced to a generator, or NULL */
+    /* Borrowed reference to a generator, or NULL */
     PyObject *f_gen;
 
     PyThreadState *f_tstate;
diff -r 438cdc97d8ee Lib/test/test_frame.py
--- a/Lib/test/test_frame.py	Mon Aug 05 23:35:43 2013 +0200
+++ b/Lib/test/test_frame.py	Tue Aug 06 12:38:15 2013 +0800
@@ -93,7 +93,7 @@
 
     @support.cpython_only
     def test_clear_refcycles(self):
-        # .clear() doesn't leave any refcycle behin
+        # .clear() doesn't leave any refcycle behind.
         with support.disable_gc():
             class C:
                 pass


About the second comment, I am not sure to put dot or not. In that file, I saw some comments use dot, others don't.

----------
assignee: docs at python
components: Documentation
messages: 194523
nosy: docs at python, pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Typos in frame object related code
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 07:01:37 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 05:01:37 +0000
Subject: [New-bugs-announce] [issue18666] Unused variable in test_frame.py
Message-ID: <1375765297.44.0.682936392521.issue18666@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is a unused variable in Lib/test/test_frame.py.

    def test_clear_executing_generator(self):
        # Attempting to clear an executing generator frame is forbidden.
        endly = False
        def g():
            nonlocal endly
            try:
                1/0
            except ZeroDivisionError as e:
                f = e.__traceback__.tb_frame
                with self.assertRaises(RuntimeError):
                    f.clear()
                with self.assertRaises(RuntimeError):
                    f.f_back.clear()
                yield f
            finally:
                endly = True
        gen = g()
        f = next(gen)
        self.assertFalse(endly)

The variable f is hanging without any purpose.

Attached the patch to give purpose to variable f.

----------
components: Tests
files: test_frame.patch
keywords: patch
messages: 194524
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Unused variable in test_frame.py
versions: Python 3.4
Added file: http://bugs.python.org/file31170/test_frame.patch

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

From report at bugs.python.org  Tue Aug  6 08:54:47 2013
From: report at bugs.python.org (Petr.Salinger)
Date: Tue, 06 Aug 2013 06:54:47 +0000
Subject: [New-bugs-announce] [issue18667] missing HAVE_FCHOWNAT
Message-ID: <1375772087.0.0.361755653525.issue18667@psf.upfronthosting.co.za>


New submission from Petr.Salinger:

During test on kfreebsd:

test_chown_dir_fd (test.test_posix.PosixTester) ... skipped 'test needs dir_fd support in os.chown()'

But all *AT syscalls are supported.
It looks like posixmodule.c misses propagation of that fact.

--- a/Modules/posixmodule.c
+++ b/Modules/posixmodule.c
@@ -12004,6 +12004,10 @@
     "HAVE_FCHOWN",
 #endif
 
+#ifdef HAVE_FCHOWNAT
+    "HAVE_FCHOWNAT",
+#endif
+
 #ifdef HAVE_FEXECVE
     "HAVE_FEXECVE",
 #endif

----------
components: Extension Modules
messages: 194529
nosy: Petr.Salinger
priority: normal
severity: normal
status: open
title: missing HAVE_FCHOWNAT
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 15:20:46 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Aug 2013 13:20:46 +0000
Subject: [New-bugs-announce] [issue18668] Properly document setting m_size
	in PyModuleDef
Message-ID: <1375795246.61.0.949649493069.issue18668@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

docs.python.org/dev/c-api/module.html Currently doesn't say much about m_size, except that setting it to -1 means "no memory needed".

m_size == -1 has a much more important use that is not documented: it signals the import machinery that the module should not be ever re-initialized. This has to be documented explicitly.

----------
assignee: eli.bendersky
components: Documentation, Extension Modules
messages: 194542
nosy: eli.bendersky, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Properly document setting m_size in PyModuleDef
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug  6 16:42:50 2013
From: report at bugs.python.org (productivememberofsociety666)
Date: Tue, 06 Aug 2013 14:42:50 +0000
Subject: [New-bugs-announce] [issue18669] curses.chgat() moves cursor,
	documentation says it shouldn't
Message-ID: <1375800170.73.0.20062232661.issue18669@psf.upfronthosting.co.za>


New submission from productivememberofsociety666:

According to docs.python.org/2/library/curses.html#chgat (or any other version), curses.chgat() is not supposed to move the cursor at all.

This is true if you don't give it x,y coordinates, but if you do, the cursor does in fact move to those coordinates, since it then uses C curses's mvchgat() internally and doesn't correct the position afterwards.

See included file for demonstration:

Expected output is:
one
two

Actual output is:
two

Fix the documentation or fix the code :-)

----------
assignee: docs at python
components: Documentation, Extension Modules
files: chgat-bug.py
messages: 194552
nosy: docs at python, productivememberofsociety666
priority: normal
severity: normal
status: open
title: curses.chgat() moves cursor, documentation says it shouldn't
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31175/chgat-bug.py

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

From report at bugs.python.org  Tue Aug  6 17:31:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 06 Aug 2013 15:31:44 +0000
Subject: [New-bugs-announce] [issue18670] Using read_mime_types function
	from mimetypes module	gives resource warning
Message-ID: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

[sky at localhost cpython]$ cat /tmp/a.txt
x-application/mimea mimea
application/mimeb mimeb
[sky at localhost cpython]$ cat /tmp/a.py
import warnings
warnings.simplefilter('default')
import mimetypes

mimetypes.read_mime_types('/tmp/a.txt')
[sky at localhost cpython]$ python3 /tmp/a.py
/tmp/a.py:7: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/a.txt' mode='r' encoding='UTF-8'>
  mimetypes.read_mime_types('/tmp/a.txt')



Attached the patch to fix the resource warning problem.

----------
components: Library (Lib)
files: fix_resource_warning_read_mime_types.patch
keywords: patch
messages: 194557
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Using read_mime_types function from mimetypes module gives resource warning
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31176/fix_resource_warning_read_mime_types.patch

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

From report at bugs.python.org  Tue Aug  6 17:57:49 2013
From: report at bugs.python.org (M. Dietrich)
Date: Tue, 06 Aug 2013 15:57:49 +0000
Subject: [New-bugs-announce] [issue18671] enhance formatting in logging
	package
Message-ID: <1375804669.84.0.0477385788117.issue18671@psf.upfronthosting.co.za>


New submission from M. Dietrich:

in logging/__init__.py line 328 there is a simple line:

     msg = msg % self.args

if that line fails this failure will be logged, not the line itself. i suggest to change the line to something like:

    try: msg = msg % self.args
    except TypeError: msg = 'logging formatting error with "%s" %% %s' % (
        msg, self.args, )

to be able to pinpoint the actual wrong formatting string (the stack trace doesnt help here).

----------
components: Extension Modules
messages: 194559
nosy: mdt
priority: normal
severity: normal
status: open
title: enhance formatting in logging package
type: enhancement

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

From report at bugs.python.org  Tue Aug  6 18:11:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Aug 2013 16:11:58 +0000
Subject: [New-bugs-announce] [issue18672] Fix format specifiers for debug
	output in _sre.c
Message-ID: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When the VERBOSE macro name is defined in _sre.c the TRACE macro prints regex processing trace. It use the %d format specifier for Py_ssize_t values. This can crash on 64-bit. Proposed patch fixes format strings.

----------
components: Regular Expressions
files: re_trace_format.patch
keywords: patch
messages: 194561
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix format specifiers for debug output in _sre.c
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31177/re_trace_format.patch

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

From report at bugs.python.org  Tue Aug  6 21:43:40 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Aug 2013 19:43:40 +0000
Subject: [New-bugs-announce] [issue18673] Add and use O_TMPFILE for Linux
	3.11
Message-ID: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Linux 3.11 gets a new flag for open():

Quote from http://lwn.net/Articles/557314/
---
The new O_TMPFILE option to the open() and openat() system calls allows filesystems to optimize the creation of temporary files ? files which need not be visible in the filesystem. When O_TMPFILE is present, the provided pathname is only used to locate the containing directory (and thus the filesystem where the temporary file should be). So, among other things, programs using O_TMPFILE should have fewer concerns about vulnerabilities resulting from symbolic link attacks.
---

Tasks:

- add O_TEMPFILE to posixmodule.c
- use O_TEMPFILE in tempfile module when it's supported by the current kernel

----------
components: Extension Modules, Library (Lib)
messages: 194569
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add and use O_TMPFILE for Linux 3.11
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug  6 22:38:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Aug 2013 20:38:51 +0000
Subject: [New-bugs-announce] [issue18674] Store weak references in
	modules_by_index
Message-ID: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

modules_by_index is a near-eternal store for extension modules. It is only collected at the end of interpreter shutdown, which is much too late for regular garbage collection. This patch proposes instead to store weak references in modules_by_index, so that extension modules can be collected in a normal way when they are removed from sys.modules.

The only gotcha is that PyState_FindModule returns a borrowed reference. With this change, it becomes really important to incref the returned reference as soon as possible.

----------
components: Interpreter Core
files: wr_module_state.patch
keywords: patch
messages: 194571
nosy: brett.cannon, eric.snow, loewis, ncoghlan, pitrou, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Store weak references in modules_by_index
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31180/wr_module_state.patch

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

From report at bugs.python.org  Wed Aug  7 11:23:16 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 07 Aug 2013 09:23:16 +0000
Subject: [New-bugs-announce] [issue18675] Daemon Threads can seg fault
Message-ID: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

This is a documentation bug: Since #1856  is not solved for Python2, it needs to be documented.

Daemon Threads on Python2 can seg fault.

Work arounds: http://stackoverflow.com/questions/18098475/detect-interpreter-shut-down-in-daemon-thread

----------
assignee: docs at python
components: Documentation
messages: 194601
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: Daemon Threads can seg fault
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Aug  7 15:52:08 2013
From: report at bugs.python.org (Zhongyue Luo)
Date: Wed, 07 Aug 2013 13:52:08 +0000
Subject: [New-bugs-announce] [issue18676] Queue: zero should not be accepted
	as timeout value
Message-ID: <1375883528.55.0.275850242187.issue18676@psf.upfronthosting.co.za>


New submission from Zhongyue Luo:

The docstring of methods put() and get() in Queue.py states

get(): If 'timeout' is a positive number, it blocks at most 'timeout' seconds and raises the Full exception if no free slot was available within that time.

put(): If 'timeout' is a positive number, it blocks at most 'timeout' seconds and raises the Empty exception if no item was available within that time.

Additionally the ValueError both methods raise is

 raise ValueError("'timeout' must be a positive number")

However the logic checks if 'timeout' is non-negative.

 elif timeout < 0:
     raise ValueError("'timeout' must be a positive number")

The logic should change as

 elif timeout <= 0:
     raise ValueError("'timeout' must be a positive number")

----------
components: Library (Lib)
messages: 194611
nosy: zyluo
priority: normal
severity: normal
status: open
title: Queue: zero should not be accepted as timeout value
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  7 16:22:07 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 07 Aug 2013 14:22:07 +0000
Subject: [New-bugs-announce] [issue18677] Enhanced context managers with
	ContextManagerExit and	None
Message-ID: <1375885327.18.0.790620363467.issue18677@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

A proposed patch adds two features to context managers:

1)It has always irked me that it was impossible to assemble nested context managers in the python language. See issue #5251.
The main problem, that exceptions in __enter__ cannot be properly handled, is fixed by introducing a new core exception, ContextManagerExit.  When raised by __enter__(), the body that the context manager protects is skipped.  This exception is in the spirit of other semi-internal exceptions such as GeneratorExit and StopIteration.  Using this exception, contextlib.nested can properly handle the case where the body isn't run because of an internal __enter__ exception which is handled by an outer __exit__.

2) The mechanism used in implementing ContextManagerExit above is easily extended to allowing a special context manager: None.  This is useful for having _optional_ context managers.  E.g. code like this:
    with performance_timer():
        do_work()

    def performance_timer():
        if profiling:
            return accumulator
        return None

None becomes the trivial context manager and its __enter__ and __exit__ calls are skipped, along with their overhead.

This patch implements both features.
In addition, it:
1) reintroduces contextlib.nested, which is based on nested_delayed
2) introduces contextlib.nested_delayed, which solves the other problem with previous versions of nested, that an inner context manager expression shouldn't be evaluated early.  contextlib.nested evaluates callables returning context managers, rather than managers directly.
3) Allows contextlib.contextmanager decorated functions to not yield, which amounts to skipping the protected body (implicitly raising ContextManagerExit)
4) unittests for the whole thing.

I'll introduce this stuff on python-ideas as well.

----------
components: Interpreter Core
files: contextmanagerexit.patch
keywords: patch
messages: 194615
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Enhanced context managers with ContextManagerExit and None
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31182/contextmanagerexit.patch

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

From report at bugs.python.org  Wed Aug  7 16:50:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 07 Aug 2013 14:50:00 +0000
Subject: [New-bugs-announce] [issue18678] Wrong struct members name for spwd
	module
Message-ID: <1375887000.77.0.620898445025.issue18678@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Both python2 and python3 have this behaviour.

>>> import os; os.getuid()
0
>>> 'I am root'
'I am root'
>>> import spwd
>>> spwd.getspnam('bin')
spwd.struct_spwd(sp_nam='bin', sp_pwd='*', sp_lstchg=15558, sp_min=0, sp_max=99999, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1)
>>> spwd.getspnam.__doc__
'getspnam(name) -> (sp_namp, sp_pwdp, sp_lstchg, sp_min, sp_max,\n                    sp_warn, sp_inact, sp_expire, sp_flag)\nReturn the shadow password database entry for the given user name.\nSee spwd.__doc__ for more on shadow password database entries.'

The documentation tells the function getspnam will give struct which has member sp_namp and sp_pwdp. But as you can see, the function getspnam gives me a tuple with has member sp_nam (without p) and sp_pwd (without p).

If you "man spwd", you can see the documentation is correct:
Structure
       The shadow password structure is defined in <shadow.h> as follows:

           struct spwd {
               char *sp_namp;     /* Login name */
               char *sp_pwdp;     /* Encrypted password */
               long  sp_lstchg;   /* Date of last change (measured
                                     in days since 1970-01-01 00:00:00 +0000 (UTC)) */
               long  sp_min;      /* Min # of days between changes */
               long  sp_max;      /* Max # of days between changes */
               long  sp_warn;     /* # of days before password expires
                                     to warn user to change it */
               long  sp_inact;    /* # of days after password expires
                                     until account is disabled */
               long  sp_expire;   /* Date when account expires (measured
                                     in days since 1970-01-01 00:00:00 +0000 (UTC)) */
               unsigned long sp_flag;  /* Reserved */
           };

For curious souls who do not have unix box:
http://linux.die.net/man/3/getspnam

I have contemplated about whether this behaviour is intended as it is, but I guess this is just a bug. Typo.

Attached the patch to fix this inconsistency. I also fixed some documentation about sp_inact and sp_expire.

I only marked this as Python 3.4 fix because I am not sure whether we should backport it to previous python versions. Some programs that expect sp_nam and sp_pwd names could break.

----------
components: Extension Modules
files: spwd_struct_members_name_fix.patch
keywords: patch
messages: 194618
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Wrong struct members name for spwd module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31183/spwd_struct_members_name_fix.patch

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

From report at bugs.python.org  Wed Aug  7 23:22:45 2013
From: report at bugs.python.org (Derek Wilson)
Date: Wed, 07 Aug 2013 21:22:45 +0000
Subject: [New-bugs-announce] [issue18679] include a codec to handle escaping
	only control	characters but not any others
Message-ID: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za>


New submission from Derek Wilson:

Escaping strings for serialization or display is a common problem. Currently, in python3, in order to escape a sting, you need to do this:

'my\tstring'.encode('unicode_escape').decode('ascii')

This would give you a string that was represented like this:

'my\\tstring'

But this does not present a suitable representation when the string contains unicode characters. Consider this example:

s = '?\t?'

There is no method to write this string this with only the control character escaped.

Even python itself recognizes this as a problem and implemented a "solution" for it.

>>> s = '?\t?'
>>> print(s)
?	?
>>> print(repr(s))
'?\t?'
>>> print(s.encode('unicode_escape').decode('ascii'))
\u0391\t\u03a9

What I want is public exposure of the functionality to represent control characters with their common \ escape sequences (or \x## for control characters where necessary - for instance unit and record separators).

I have numerous use cases for this and python's own str.__repr__ implementation shows that the functionality is valuable. I would bet that the majority of cases where people use unicode_escape something like a control_escape is more along the lines of what is desired.

And while we're at it, it would be great if this were a unicode->unicode codec like the rot_13 codec. My desired soluiton would look like this:

>>> import codecs
>>> s = '?\t?'
>>> e = codecs.encode(s, 'control_escape'))
>>> print(e)
?\t?
>>> print(codecs.decode(e, 'control_escape'))
?	?

If this is something that could be included in python 3.4, that would be awesome. I am willing to work on this if so.

----------
components: Library (Lib)
messages: 194625
nosy: underrun
priority: normal
severity: normal
status: open
title: include a codec to handle escaping only control characters but not any others
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  8 00:06:31 2013
From: report at bugs.python.org (Corey Farwell)
Date: Wed, 07 Aug 2013 22:06:31 +0000
Subject: [New-bugs-announce] [issue18680] JSONDecoder should document that
	it raises a ValueError	for malformed data
Message-ID: <1375913191.45.0.0174536581066.issue18680@psf.upfronthosting.co.za>


New submission from Corey Farwell:

Before someone comes in and tries to correct me, I know Python documentation is different than Javadocs. It is common to test if the JSON is malformed using a try...catch. What if I want to catch something more specific than Exception? The only way a user would know what to catch is to `python -c "import json; json.loads('FAIL')"`. Many other Python modules document which exception is raised on invalid input/parameters.

----------
assignee: docs at python
components: Documentation
messages: 194628
nosy: corey, docs at python
priority: normal
severity: normal
status: open
title: JSONDecoder should document that it raises a ValueError for malformed data
type: enhancement
versions: Python 2.6, 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/issue18680>
_______________________________________

From report at bugs.python.org  Thu Aug  8 05:22:22 2013
From: report at bugs.python.org (Weizhao Li)
Date: Thu, 08 Aug 2013 03:22:22 +0000
Subject: [New-bugs-announce] [issue18681] typo in imp.reload
Message-ID: <1375932142.75.0.662721125733.issue18681@psf.upfronthosting.co.za>


New submission from Weizhao Li:

just a typo:

270c270
<             raise ImportError(msg.format(parentname), name=parent_name)
---
>             raise ImportError(msg.format(parent_name), name=parent_name)

----------
components: Library (Lib)
messages: 194641
nosy: felloak
priority: normal
severity: normal
status: open
title: typo in imp.reload
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  8 10:29:26 2013
From: report at bugs.python.org (Michal Vyskocil)
Date: Thu, 08 Aug 2013 08:29:26 +0000
Subject: [New-bugs-announce] [issue18682] [PATCH] remove bogus codepath from
	pprint._safe_repr
Message-ID: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>


New submission from Michal Vyskocil:

pprint._safe_repr for type str uses much slower codepath by default, which does not makes a sense in Python3 context. Instead of simply using repr, it check the existence of 'locale' in sys.modules and if found, it goes one-by-one-char call str.isalpha() on each and apply the quoting for non-alpha chars. This is extremely slow, but as locale is usually in sys.modules, it's used by default.

The point of such code was because in python2, str.isalpha() depends on locale, so for locale-aware Python builds, there was a different path needed. But this does not apply for Python3, where all strings are unicode, so .isaplha() is not locale sensitive anymore.

----------
components: Library (Lib)
files: pprint-remove-bogus-code.patch
keywords: patch
messages: 194652
nosy: mvyskocil
priority: normal
severity: normal
status: open
title: [PATCH] remove bogus codepath from pprint._safe_repr
type: performance
Added file: http://bugs.python.org/file31193/pprint-remove-bogus-code.patch

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

From report at bugs.python.org  Thu Aug  8 13:41:21 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 08 Aug 2013 11:41:21 +0000
Subject: [New-bugs-announce] [issue18683] Core dumps on CentOS
Message-ID: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>


New submission from Marc Schlaich:

I'm running unittests on a CentOS 6.4 Virtual Box slave via Jenkins on a 
Windows host. Randomly I get core dumps for no obvious reason. I don't
use any C extension in my code and don't use ctypes. The (proprietary)
software is plain Python with a multi-threaded architecture.

There might be a threading race condition in the code but according
to http://stackoverflow.com/a/13654489/851737 this shouldn't result
in a segfault. So it might be a bug in Python.

I appended one log (I have various others if you wish to see them) with 
faulthandler enabled by https://pypi.python.org/pypi/nose-faulthandler.

----------
files: crash.log
messages: 194660
nosy: schlamar
priority: normal
severity: normal
status: open
title: Core dumps on CentOS
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file31196/crash.log

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

From report at bugs.python.org  Thu Aug  8 13:56:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 11:56:24 +0000
Subject: [New-bugs-announce] [issue18684] Pointers point out of array bound
	in _sre.c
Message-ID: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In _sre.c pointers can point out of boundaries of array. This is an undefined behavior and is one of causes of a bug in issue17998 (end-ptr can be negative). The proposed patch change code to check if pointers will point out of boundaries before their changing.

----------
components: Regular Expressions
files: sre_ptr_out_of_bounds.patch
keywords: patch
messages: 194661
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pointers point out of array bound in _sre.c
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31197/sre_ptr_out_of_bounds.patch

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

From report at bugs.python.org  Thu Aug  8 15:10:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 13:10:17 +0000
Subject: [New-bugs-announce] [issue18685] Restore re performance to
	pre-PEP393 level
Message-ID: <1375967417.95.0.0303828296889.issue18685@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Before PEP 393 the regex functions scanned an array of char or Py_UNICODE and character testing was cheap. After PEP 393 they checks a kind of an unicode string for every tested character and processing of unicode strings becomes slower. _sre.c already generates two sets of functions from one source -- for byte and unicode strings. The proposed patch uses same technique to generate three sets of functions -- for byte/UCS1, UCS2 and UCS4 strings. This simplifies the code (now it more similar to pre-PEP393 version) and makes characters testing faster.

Benchmark example:

Python 3.2:
$ python3.2 -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
1000 loops, best of 3: 613 usec per loop
$ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
1000 loops, best of 3: 232 usec per loop
$ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
1000 loops, best of 3: 217 usec per loop

Python 3.4.0a1+ unpatched:
$ ./python -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
1000 loops, best of 3: 485 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
1000 loops, best of 3: 790 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
1000 loops, best of 3: 1.09 msec per loop

Python 3.4.0a1+ patched:
$ ./python -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*100000"  "f(x)"
1000 loops, best of 3: 250 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*100000"  "f(x)"
1000 loops, best of 3: 250 usec per loop
$ ./python -m timeit -s "import re; f = re.compile('abc').search; x = '\u20ac'*100000"  "f(x)"
1000 loops, best of 3: 256 usec per loop

I also propose for simplicity extract a template part of _sre.c to separated file (i.e. srelib.h) and get rid of recursion.

----------
assignee: serhiy.storchaka
components: Regular Expressions, Unicode
files: sre_optimize.patch
keywords: patch
messages: 194669
nosy: ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Restore re performance to pre-PEP393 level
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file31198/sre_optimize.patch

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

From report at bugs.python.org  Thu Aug  8 18:55:42 2013
From: report at bugs.python.org (Jeffrey Goeders)
Date: Thu, 08 Aug 2013 16:55:42 +0000
Subject: [New-bugs-announce] [issue18686] Tkinter focus_get on menu causes
	crash
Message-ID: <1375980942.46.0.944431245569.issue18686@psf.upfronthosting.co.za>


New submission from Jeffrey Goeders:

I am experiencing a crash when calling focus_get() when a Tk Menu has focus.  Here is sample code, just click the menu and it will crash.


import Tkinter as tk

class App(tk.Tk):
    def __init__(self, *args, **kw):
        tk.Tk.__init__(self, *args, **kw)
        
        self.entry = tk.Entry(self)
        self.entry.grid(padx=20, pady=20)
        self.entry.focus_set()
        self.entry.bind("<FocusOut>", self.entry_focus_lost)
        
        self.menubar = tk.Menu(self)
        self["menu"] = self.menubar
        
        self.menufile = tk.Menu(self.menubar, tearoff=False)
        self.menubar.add_cascade(menu=self.menufile, label="File")

    def entry_focus_lost(self, event):
        widget_with_focus = self.focus_get()


app = App()
app.mainloop()


Here is the error stack:
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1410, in __call__
    return self.func(*args)
  File "/home/jgoeders/workspace/tester/test_menu_focus.py", line 19, in entry_focus_lost
    widget_with_focus = self.focus_get()
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 446, in focus_get
    return self._nametowidget(name)
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1079, in nametowidget
    w = w.children[n]
KeyError: '#140030874747536'

----------
components: Tkinter
messages: 194693
nosy: jgoeders
priority: normal
severity: normal
status: open
title: Tkinter focus_get on menu causes crash
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  8 20:05:16 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Thu, 08 Aug 2013 18:05:16 +0000
Subject: [New-bugs-announce] [issue18687] Lib/test/leakers/test_ctypes.py
	still mentions the need	to update Misc/build.sh
Message-ID: <1375985116.56.0.149122259336.issue18687@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

"# When this leak is fixed, remember to remove from Misc/build.sh LEAKY_TESTS." -> Misc/build.sh got removed 19 months ago, this should be updated.

----------
assignee: docs at python
components: Documentation
files: patch.diff
keywords: patch
messages: 194703
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Lib/test/leakers/test_ctypes.py still mentions the need to update Misc/build.sh
versions: Python 3.4
Added file: http://bugs.python.org/file31200/patch.diff

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

From report at bugs.python.org  Thu Aug  8 21:12:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Aug 2013 19:12:46 +0000
Subject: [New-bugs-announce] [issue18688] Document undocumented Unicode
	object API
Message-ID: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Include/unicodeobject.h contains followed names which are declared as public but are not documented in Doc/c-api/unicode.rst.

PyUnicodeIter_Type
Py_UNICODE_REPLACEMENT_CHARACTER
PyUnicode_Resize
PyUnicode_InternImmortal
PyUnicode_CHECK_INTERNED
PyUnicode_FromOrdinal
PyUnicode_GetDefaultEncoding
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap
PyUnicode_DecodeCodePageStateful
PyUnicode_Append
PyUnicode_AppendAndDel
PyUnicode_Partition
PyUnicode_RPartition
PyUnicode_RSplit
PyUnicode_IsIdentifier
_PyUnicode_FromId
_PyUnicode_ClearStaticStrings

They should be either documented or declared as private.

PyUnicode_AsEncodedObject only mentioned in Doc/whatsnew/3.3.rst as recomended replacement of PyUnicode_Encode.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 194705
nosy: docs at python, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Document undocumented Unicode object API
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  8 22:15:37 2013
From: report at bugs.python.org (Derek Wilson)
Date: Thu, 08 Aug 2013 20:15:37 +0000
Subject: [New-bugs-announce] [issue18689] add argument for formatter to
	logging.Handler and	subclasses in logging module
Message-ID: <1375992937.35.0.58426954587.issue18689@psf.upfronthosting.co.za>


New submission from Derek Wilson:

It is common when setting up a logger to create both a handler and a formatter. Nice format strings make logging better. Like this:

>>> fmt_string = "%(asctime)s [%(levelname)-9s] %(name)s: %(message)s"

We would use it like so: 

>>> from logging import getLogger, StreamHandler, Formatter
>>> logger = getLogger('mypackage.mymodule')
>>> handler = StreamHandler()
>>> formatter = Formatter(fmt_string)
>>> handler.setFormatter(formatter)
>>> logger.addHandler(handler)
>>> logger.warning('she called out a warning...')

But its nice to separate adding handlers from using loggers. so in mymodule I might do:

>>> logger = getLogger('mypackage.mymodule')
>>> logger.warning('do not pass go...')

and in whatever entry point cares about logging from mypackage (like a cli or another module importing my package that wants log data) I would do:

>>> base_logger = getLogger('mypackage')
>>> handler = StreamHandler()
>>> formatter = Formatter(fmt_string)
>>> handler.setFormatter(formatter)
>>> base_logger.addHandler(handler)

but usually, at this point, i don't care about this base_logger at all and i've got a bunch of refs to things i don't need anymore - the only purpose of all this code is to handle any logging that may be done elsewhere in the package.

If handlers allowed passing in a formatter into __init__, then we could reduce the above to something like this:

>>> getLogger('mypackage').addHandler(StreamHandler(
        fmt=Formatter(fmt_string)))

Using a kwarg would make it so we don't need to worry about existing argument order so that should be completely backward compatible.

It'd be extra friendly if Handler could introspect fmt and see if it is an instance str and if so create a Formatter in itself ... that way we could do:

>>> getLogger('mypackage').addHandler(StreamHandler(fmt=fmt_string))

This would reduce the barrier to entry to customizing logging functionality and might go a long way toward increasing effective use of the same.

----------
components: Library (Lib)
messages: 194706
nosy: underrun
priority: normal
severity: normal
status: open
title: add argument for formatter to logging.Handler and subclasses in logging module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug  8 22:38:26 2013
From: report at bugs.python.org (Simon Feltman)
Date: Thu, 08 Aug 2013 20:38:26 +0000
Subject: [New-bugs-announce] [issue18690] memoryview not considered a
	sequence
Message-ID: <1375994306.09.0.288774044914.issue18690@psf.upfronthosting.co.za>


New submission from Simon Feltman:

This was a bit unexpected as memoryviews support all the methods of the Sequence abstract base class:

>>> import collections
>>> b = bytearray(b'asdf')
>>> isinstance(b, collections.Sequence)
True
>>> m = memoryview(b)
>>> isinstance(m, collections.Sequence)
False

It would be nice if memoryview was registered with the Sequence ABC and MutableSequence for writeable memoryviews.

----------
components: Library (Lib)
messages: 194707
nosy: sfeltman
priority: normal
severity: normal
status: open
title: memoryview not considered a sequence
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/issue18690>
_______________________________________

From report at bugs.python.org  Fri Aug  9 00:22:52 2013
From: report at bugs.python.org (Andrew Myers)
Date: Thu, 08 Aug 2013 22:22:52 +0000
Subject: [New-bugs-announce] [issue18691] sqlite3.Cursor.execute expects
	sequence as second	argument.
Message-ID: <1376000572.11.0.481266307811.issue18691@psf.upfronthosting.co.za>


New submission from Andrew Myers:

Sorry if this isn't the place for this, it is my first python bug report.

In PEP 249 Python database API specifiction 2.0 the Cursor execute method[1] is described as taking a variable number of arguments for substitution of '?' in the SQL string.  In the documentation of the sqlite3 module the Cursor execute method is also described this way[2].

However, the actual method requires a sequence, in the same way that the executemany method does.  This does not match the execute method in (for instance) pyodbc and means one cannot write code that is (fully) agnostic to the connection type.

[1]: http://www.python.org/dev/peps/pep-0249/#id15
[2]: http://docs.python.org/2/library/sqlite3.html#sqlite3.Cursor.execute

Pasted below is an example of this from python 3.3

In [1]: import sqlite3
In [2]: con = sqlite3.connect(":memory:")
In [4]: con.execute('create table foo (bar int, baz int)')
Out[4]: <sqlite3.Cursor at 0x7fe622286730>

In [5]: con.execute('insert into foo values (?, ?)', 4, 5)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-a0ea5e3e7a03> in <module>()
----> 1 con.execute('insert into foo values (?, ?)', 4, 5)

TypeError: function takes at most 2 arguments (3 given)

In [6]: con.execute('insert into foo values (?, ?)', (4, 5))
Out[6]: <sqlite3.Cursor at 0x7fe622201880>

In [7]:

----------
components: Library (Lib)
messages: 194710
nosy: Andrew.Myers
priority: normal
severity: normal
status: open
title: sqlite3.Cursor.execute expects sequence as second argument.
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Aug  9 02:02:19 2013
From: report at bugs.python.org (INNA)
Date: Fri, 09 Aug 2013 00:02:19 +0000
Subject: [New-bugs-announce] [issue18692] Connection change in compiled code
Message-ID: <1376006539.81.0.90020007488.issue18692@psf.upfronthosting.co.za>


New submission from INNA:

Hi,

I have a compiled code, which currently uses SQLITE connection (datastore). I was wondering if it is possible to change the connection string to use SQL Server database.

I would like to export the datastore to SQL server database, as we are having issues with the limit.

Thank you.
Inna

----------
components: Windows
messages: 194711
nosy: INNESSA
priority: normal
severity: normal
status: open
title: Connection change in compiled code
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  9 03:59:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 09 Aug 2013 01:59:52 +0000
Subject: [New-bugs-announce] [issue18693] help() not helpful with enum
Message-ID: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>


New submission from Ethan Furman:

help(), when used on an enum member or class, returns almost nothing.  I suspect the custom __dir__ is at fault, but whatever is causing the problem needs fixing.

----------
assignee: ethan.furman
messages: 194714
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: help() not helpful with enum
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  9 06:55:33 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 09 Aug 2013 04:55:33 +0000
Subject: [New-bugs-announce] [issue18694] getxattr on Linux ZFS native
	filesystem happily returns	partial values
Message-ID: <1376024133.74.0.379846700659.issue18694@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The getxattr() system call retrieves an "extended attribute" on a file.  When you call it you pass in a buffer and a size.  The expected behavior is, if you pass in a buffer that's too small, the function returns -1 and sets errno to ERANGE.

On a ZFS filesystem on Linux, using the "ZFS On Linux" port:
    http://zfsonlinux.org/

getxattr() does not behave this way.  Instead, it fills the buffer with the first buffer-size bytes of data (without a zero terminator).

Python's implementation of getxattr() interprets this as success.  Which means that, the way it's implemented, if you call getxattr() to retrieve a value that's > 128 bytes in length, you only get the first 128 bytes.  (Happily, we already have a regression test that finds this!)

Attached is a patch fixing this behavior.  It checks the return value of getxattr() to see if the buffer was filled to 100%.  If so, it retries with a larger buffer.

----------
assignee: larry
components: Library (Lib)
files: larry.setxattr.zfs.patch.1.txt
messages: 194716
nosy: larry
priority: normal
severity: normal
stage: patch review
status: open
title: getxattr on Linux ZFS native filesystem happily returns partial values
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31203/larry.setxattr.zfs.patch.1.txt

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

From report at bugs.python.org  Fri Aug  9 14:06:43 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 09 Aug 2013 12:06:43 +0000
Subject: [New-bugs-announce] [issue18695] os.statvfs() not working well with
	unicode paths
Message-ID: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

From: https://code.google.com/p/psutil/issues/detail?id=416


# -*- coding: utf-8 -*-
from __future__ import unicode_literals
import os, errno
name = "???"
try:
    os.mkdir(name)
except OSError as err:
    if err.errno != errno.EEXIST:
        raise
os.statvfs(name)


The script above works fine on Python 3.3 but on 2.7 you'll get:

Traceback (most recent call last):
  File "foo.py", line 10, in <module>
    os.statvfs(name)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)

Patch in attachment fixes the issue.

----------
components: Unicode
files: statvfs.patch
keywords: needs review, patch
messages: 194726
nosy: ezio.melotti, giampaolo.rodola
priority: normal
severity: normal
status: open
title: os.statvfs() not working well with unicode paths
versions: Python 2.7
Added file: http://bugs.python.org/file31207/statvfs.patch

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

From report at bugs.python.org  Fri Aug  9 17:58:07 2013
From: report at bugs.python.org (py.user)
Date: Fri, 09 Aug 2013 15:58:07 +0000
Subject: [New-bugs-announce] [issue18696] In unittest.TestCase.longMessage
	doc remove a redundant	sentence
Message-ID: <1376063887.45.0.331340035557.issue18696@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestCase.longMessage
"If set to True then any explicit failure message you pass in to the assert methods will be appended to the end of the normal failure message. The normal messages contain useful information about the objects involved, for example the message from assertEqual shows you the repr of the two unequal objects. Setting this attribute to True allows you to have a custom error message in addition to the normal one."

the last sentence duplicates the first one

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 194748
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestCase.longMessage doc remove a redundant sentence
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31208/issue.diff

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

From report at bugs.python.org  Fri Aug  9 20:48:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Aug 2013 18:48:46 +0000
Subject: [New-bugs-announce] [issue18697] Unify arguments names in Unicode
	object C API	documentation
Message-ID: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In declarations of Unicode object C API functions in Doc/c-api/unicode.rst the first Unicode object argument has different names: "unicode", "str", "u", "s". It will be good to unify these names.

Of course there is no need to change reasonable argument names for such functions as PyUnicode_Concat() or PyUnicode_CopyCharacters().

----------
assignee: docs at python
components: Documentation, Unicode
keywords: easy
messages: 194755
nosy: docs at python, ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Unify arguments names in Unicode object C API documentation
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 10 01:27:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 09 Aug 2013 23:27:18 +0000
Subject: [New-bugs-announce] [issue18698] importlib.reload() does not return
	the module in	sys.modules
Message-ID: <1376090838.27.0.832453640234.issue18698@psf.upfronthosting.co.za>


New submission from Eric Snow:

Currently reload() returns the module that loader.load_module() returns, rather than returning the one in sys.modules.  This is different from what happens during normal import.  I would expect reload() to return what's in sys.modules.  Perhaps this got overlooked when we moved reload()?  I haven't had a chance to verify, but I do recall that the switch to importlib-based import in 3.3 exposed a bug where importlib wasn't returning the module in sys.modules during normal import.

----------
components: Library (Lib)
messages: 194776
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
status: open
title: importlib.reload() does not return the module in sys.modules
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 10 01:48:38 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Aug 2013 23:48:38 +0000
Subject: [New-bugs-announce] [issue18699] What is Future.running() for in
	PEP 3148 /	concurrent.futures.Future?
Message-ID: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

>From glyph (in a particularly snarky mood):

"""
P.S.: I realize that this isn't really within the scope of this message, but as I was reviewing Future's documentation while writing it, I realized what Future.running() does.  Wow.  What a completely pointless bug magnet.  Why does this method even exist?  It seems like the only possible use would be to introduce look-before-you-leap bugs into concurrent code, like 'if not my_future.running(): my_future.cancel()'.  If it were for tracking the state of long-running Future operations for UI purposes or something, then 'my_future.add_start_callback(callback)' would be a much more useful interface, which at least has a hope of being used correctly.  Independently of the rest of stuff in this message, it would be great if that could be deprecated and removed.
"""

Despite the snarkiness, he does have a point.  Perhaps it was copied mindlessly from Java?

----------
components: Library (Lib)
messages: 194777
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: What is Future.running() for in PEP 3148 / concurrent.futures.Future?
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 10 04:25:56 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 10 Aug 2013 02:25:56 +0000
Subject: [New-bugs-announce] [issue18700] test_cgi raises ResourceWarning
Message-ID: <1376101556.78.0.0722365020142.issue18700@psf.upfronthosting.co.za>


New submission from Madison May:

I'm currently running the tests on a 64-bit Ubuntu 13.04 laptop using the default branch of python.

``/home/mmay/cpython/Lib/test/test_cgi.py:276: ResourceWarning: unclosed file <_io.BufferedRandom name=3>``

----------
components: Tests
messages: 194782
nosy: madison.may
priority: normal
severity: normal
status: open
title: test_cgi raises ResourceWarning
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 10 12:21:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 10:21:53 +0000
Subject: [New-bugs-announce] [issue18701] Remove outdated PY_VERSION_HEX
	checks
Message-ID: <1376130113.84.0.145821919316.issue18701@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which removes PY_VERSION_HEX checks in Modules/_ctypes/_ctypes.c, Modules/_sre.c, Objects/stringlib/unicodedefs.h and removes the Modules/_sqlite/sqlitecompat.h file.

_sre.c checks support Python versions <2.2, <2.2 or <1.6 which doesn't made sense because the code overall uses Unicode object API available only in Python >=3.3.

unicodedefs.h contains code to support Python <3.0, but stringlib code can't be shared with Python <3.3.

_ctypes.c and sqlitecompat.h contain code to support Python <2.5 which is not supported version.

----------
assignee: serhiy.storchaka
components: Extension Modules, Interpreter Core
files: no_version_checks.patch
keywords: patch
messages: 194789
nosy: amaury.forgeotdarc, belopolsky, benjamin.peterson, ezio.melotti, ghaering, haypo, lemburg, meador.inge, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove outdated PY_VERSION_HEX checks
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31212/no_version_checks.patch

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

From report at bugs.python.org  Sat Aug 10 13:09:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Aug 2013 11:09:26 +0000
Subject: [New-bugs-announce] [issue18702] Report skipped tests as skipped
Message-ID: <1376132966.91.0.713996712724.issue18702@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some tests in Python testsuite are silently skipped if requirements is not satisfied. The proposed patch adds explicit "skipUnless()" and "raise SkipTest()" so that these tests now reported as skipped.

I.e. the code like

    if not condition:
        def test_foo(self):
            ...

is replaced by

    @unittest.skipUnless(condition, "requires foo")
    def test_foo(self):
        ...

and the code like

    def test_foo(self):
        ...
        if not condition:
            return
        ...

is replaced by

    def test_foo(self):
        ...
        if not condition:
            raise unittest.SkipTest("requires foo")
        ...

----------
components: Tests
files: skip_tests.patch
keywords: patch
messages: 194790
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Report skipped tests as skipped
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31213/skip_tests.patch

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

From report at bugs.python.org  Sat Aug 10 20:01:15 2013
From: report at bugs.python.org (madan ram)
Date: Sat, 10 Aug 2013 18:01:15 +0000
Subject: [New-bugs-announce] [issue18703] To change the doc of
	html/faq/gui.html
Message-ID: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>


New submission from madan ram:

"Qt 4.5 upwards is licensed under the LGPL license; also, commercial licenses are available from Nokia."

Since new version of Qt 5 is realsed and Licenced under Digia.

So i am fixing this issue .

i am going to write it as 

PyQt5 is licensed on all platforms under a commercial license and the GPL v3. Your PyQt5 license must be compatible with your Qt license.
If you use the GPL version then your own code must also use a compatible license.

Note:-PyQt5, unlike Qt, is not available under the LGPL.

You can purchase a commercial PyQt5 license here.

----------
assignee: docs at python
components: Documentation
files: gui.rst
messages: 194824
nosy: docs at python, madan.ram
priority: normal
severity: normal
status: open
title: To change the doc of html/faq/gui.html
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31218/gui.rst

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

From report at bugs.python.org  Sun Aug 11 00:17:20 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Sat, 10 Aug 2013 22:17:20 +0000
Subject: [New-bugs-announce] [issue18704] IDLE: PEP8 Style Check Integration
Message-ID: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>


New submission from R. Jayakrishnan:

This is to create an IDLE extension that would integrate PEP8 (Syntax Style Checker https://pypi.python.org/pypi/pep8 ) into the IDLE editor window,so the developer who is using the IDLE editor can quickly and frequently check the PEP8 standards of the code which is being developed in an IDLE editor window. Many modern IDE's have not only syntax highlighting but on the fly syntax checking.

Python ensures the quality of code with its own standards implemented as PEP8. The tool pep8 checks Python code against some of the style conventions in PEP8. Also the PEP8 standardization should not be a ?must emphasizing? for a python developer, therefore configuring pep8 to enable/disable errors and warning in various levels should be implemented.

The implementation work is started by Todd at https://bitbucket.org/rovitotv/pythonpatches/src/fae1fdab936043ec35db541808f5789325762fb3/PEP8CheckExtension.patch?at=default

The submitted patch is an effort started from Todd's patch as an example. 
The IDLE with this patch will show PEP8 style check toggle menu in Options.
Once PEP8 check enabled the current module is checked by pep8 tool and the defects will be shown in a extended left pane. 
Defect codes will be listed as a Buttons, button click leads to highlighting the line and column of the defect and scroll editor window if needed. 
It is expected that the developer will correct the defect with the help of the message and eventually press the Resolve button,which refresh the pane.

This is an initial work and I am looking forward for suggestions on improvements and mistakes of this patch.

----------
components: IDLE
files: PEP8Extension_1.patch
keywords: patch
messages: 194841
nosy: JayKrish
priority: normal
severity: normal
status: open
title: IDLE: PEP8 Style Check Integration
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31221/PEP8Extension_1.patch

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

From report at bugs.python.org  Sun Aug 11 01:45:17 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Sat, 10 Aug 2013 23:45:17 +0000
Subject: [New-bugs-announce] [issue18705] Fix arround 100 typos/spelling
	mistakes
Message-ID: <1376178317.79.0.772879564661.issue18705@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

In issue 18466 I had said I was planning to write a tool that checks python source code to see if they are spelling mistakes in comments/strings. As it was said there, the big issue was the fact that python has so many non-english words and that docstrings often had variable names in them, so I had to work arround the issue and add a personal word list.

I only applied the tool to Lib/*.py yet, as it takes some time to check false-positives and I didn't want to end with patches too big to be reviewed.

----------
assignee: docs at python
components: Documentation
files: spelling_Lib.diff
keywords: patch
messages: 194850
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Fix arround 100 typos/spelling mistakes
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31223/spelling_Lib.diff

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

From report at bugs.python.org  Sun Aug 11 02:03:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Aug 2013 00:03:15 +0000
Subject: [New-bugs-announce] [issue18706] test failure in test_codeccallbacks
Message-ID: <1376179395.42.0.0457635695026.issue18706@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Since issue #18681, the following test sequence fails:

./python -m test -v test_codecencodings_kr test_imp test_codeccallbacks

[...]

======================================================================
ERROR: test_xmlcharnamereplace (test.test_codeccallbacks.CodecCallbackTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_codeccallbacks.py", line 112, in test_xmlcharnamereplace
    self.assertEqual(sin.encode("ascii", "test.xmlcharnamereplace"), sout)
  File "/home/antoine/cpython/default/Lib/test/test_codeccallbacks.py", line 102, in xmlcharnamereplace
    l.append("&%s;" % html.entities.codepoint2name[ord(c)])
AttributeError: 'module' object has no attribute 'entities'

----------
assignee: ezio.melotti
components: Tests
messages: 194854
nosy: ezio.melotti, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: test failure in test_codeccallbacks
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Aug 11 08:37:04 2013
From: report at bugs.python.org (madan ram)
Date: Sun, 11 Aug 2013 06:37:04 +0000
Subject: [New-bugs-announce] [issue18707] the readme should also talk about
	how to build doc.
Message-ID: <1376203024.02.0.197448582438.issue18707@psf.upfronthosting.co.za>


New submission from madan ram:

Since most of and also I faced problem of building Doc initially then later i found out how to build Doc.

So i thought to include details on how to build Doc in README.

----------
assignee: docs at python
components: Build, Devguide, Documentation, Installation
files: README.diff
keywords: patch
messages: 194866
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, madan.ram
priority: normal
severity: normal
status: open
title: the readme should also talk about how to build doc.
versions: Python 3.4
Added file: http://bugs.python.org/file31227/README.diff

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

From report at bugs.python.org  Sun Aug 11 08:47:16 2013
From: report at bugs.python.org (madan ram)
Date: Sun, 11 Aug 2013 06:47:16 +0000
Subject: [New-bugs-announce] [issue18708] Change required in python 3.4
	interpretor .
Message-ID: <1376203636.29.0.712075241068.issue18708@psf.upfronthosting.co.za>


New submission from madan ram:

As I observed when using python 3.4 Interpretor  is that it would be able to distinguish between char by '' and string by ""

>>> input()    
a
'a'

and 

>>> input()
aa
'aa'

it would be better if output was
"aa"

but if i want to fix this which file to edit.

----------
components: Interpreter Core
messages: 194867
nosy: madan.ram, rhettinger
priority: normal
severity: normal
status: open
title: Change required in python 3.4 interpretor .
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 12 13:32:52 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Aug 2013 11:32:52 +0000
Subject: [New-bugs-announce] [issue18709] SSL module fails to handle NULL
	bytes inside	subjectAltNames general names (CVE-2013-4073)
Message-ID: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Ryan Sleevi of the Google Chrome Security Team has informed us that Python's SSL module doesn't handle NULL bytes inside subjectAltNames general names. It's related to Ruby's CVE-2013-4073 http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/

Although Python uses a slightly different OpenSSL API to parse a X.509 certificate and turn its fields into a dictionary, our implementation eventually uses an OpenSSL function that fails to handle NULL bytes. This could lead to a breach when an application uses ssl.match_hostname() to match the hostname againt the certificate's subjectAltName's dNSName general names.

When the Ruby issues was announced publicly I already suspected that our code may suffer from the same issue. But I was unable to generate a X.509 certificate with a NULL byte in its X509v3 subjectAltName extension, only in subject and issuer. OpenSSL's config file format just didn't support NULL bytes. But Our code handled the NULL byte in subject in issuer just fine so I gave up. In the light of the bug report I went a different path and eventually I came up with a malicious certificate that showed the reported bug.

----------
components: Extension Modules
messages: 194944
nosy: christian.heimes
priority: critical
severity: normal
stage: patch review
status: open
title: SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4073)
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Aug 12 14:40:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 12:40:41 +0000
Subject: [New-bugs-announce] [issue18710] Add PyState_GetModuleAttr
Message-ID: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Attached patch adds PyState_GetModuleAttr() and converts the _csv module to use it (as an example).

As you can see, the _csv module grows a little but it now has proper error handling (previously, it didn't check for PyState_FindModule() returning NULL).

(A few lines would be removed if we added PyErr_FormatV as well...)

----------
components: Extension Modules, Interpreter Core
files: getmodattr.patch
keywords: patch
messages: 194949
nosy: eli.bendersky, loewis, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add PyState_GetModuleAttr
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31244/getmodattr.patch

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

From report at bugs.python.org  Mon Aug 12 14:50:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 12:50:03 +0000
Subject: [New-bugs-announce] [issue18711] Add PyErr_FormatV
Message-ID: <1376311803.97.0.992272560955.issue18711@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PyErr_FormatV can be useful to write third-party helper functions. Patch attached.

----------
components: Interpreter Core
files: pyerr_formatv.patch
keywords: patch
messages: 194952
nosy: pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Add PyErr_FormatV
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31246/pyerr_formatv.patch

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

From report at bugs.python.org  Mon Aug 12 16:09:38 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Aug 2013 14:09:38 +0000
Subject: [New-bugs-announce] [issue18712] Pure Python operator.index doesn't
	match the C version.
Message-ID: <1376316578.03.0.462256957334.issue18712@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Nitpick: the pure Python version of operator.index (new in Python 3.4, introduced in issue #16694) doesn't match the C version, in that it looks up __index__ on the object rather than the class.


iwasawa:cpython mdickinson$ ./python.exe
Python 3.4.0a1+ (default:9e61563edb67+, Aug 12 2013, 14:45:12) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from test import support
>>> py_operator = support.import_fresh_module('operator', blocked=['_operator'])
>>> c_operator = support.import_fresh_module('operator', fresh=['_operator'])
>>> class A(int): pass
... 
>>> a = A(42); a.__index__ = lambda: 1729
>>> 
>>> py_operator.index(a)
1729
>>> c_operator.index(a)
42

----------
components: Extension Modules
messages: 194966
nosy: mark.dickinson, zach.ware
priority: normal
severity: normal
status: open
title: Pure Python operator.index doesn't match the C version.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 12 17:19:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Aug 2013 15:19:34 +0000
Subject: [New-bugs-announce] [issue18713] Enable surrogateescape on stdin
	and stdout when	appropriate
Message-ID: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

One problem with Unicode in 3.x is that surrogateescape isn't normally enabled on stdin and stdout. This means the following code will fail with UnicodeEncodeError in the presence of invalid filesystem metadata:

    print(os.listdir())

We don't really want to enable surrogateescape on sys.stdin or sys.stdout unilaterally, as it increases the chance of data corruption errors when the filesystem encoding and the IO encodings don't match.

Last night, Toshio and I thought of a possible solution: enable surrogateescape by default for sys.stdin and sys.stdout on non-Windows systems if (and only if) they're using the same codec as that returned by sys.getfilesystemencoding() (allowing for codec aliases rather than doing a simple string comparison)

This means that for full UTF-8 systems (which includes most modern Linux installations), roundtripping will be enabled by default between the standard streams and OS facing APIs, while systems where the encodings don't match will still fail noisily.

A more general alternative is also possible: default to errors='surrogatescape' for *any* text stream that uses the filesystem encoding. It's primarily the standard streams we're interested in fixing, though.

----------
messages: 194968
nosy: abadger1999, benjamin.peterson, ezio.melotti, haypo, lemburg, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable surrogateescape on stdin and stdout when appropriate
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 12 21:05:21 2013
From: report at bugs.python.org (Kevin Jing Qiu)
Date: Mon, 12 Aug 2013 19:05:21 +0000
Subject: [New-bugs-announce] [issue18714] Add tests for pdb.find_function
Message-ID: <1376334321.42.0.844383208785.issue18714@psf.upfronthosting.co.za>


New submission from Kevin Jing Qiu:

PyConCA 2013 sprint task

----------
components: Tests
messages: 194986
nosy: Kevin.Jing.Qiu
priority: normal
severity: normal
status: open
title: Add tests for pdb.find_function
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Aug 12 21:15:32 2013
From: report at bugs.python.org (Seydou Dia)
Date: Mon, 12 Aug 2013 19:15:32 +0000
Subject: [New-bugs-announce] [issue18715] Tests fail when run with coverage
Message-ID: <1376334932.92.0.162234474623.issue18715@psf.upfronthosting.co.za>


New submission from Seydou Dia:

When I run the tests suit with coverage (e.g, ./python COVERAGEDIR run --pylib Lib/test/regrtest.py test_frame), the following tests fails:

 * test_frame
 * test_xml_etree
 * test_threading_local
 * test_super
 * test_importlib

 The tracebacks are available here : http://pastebin.com/j6ScCibV

----------
components: Tests
messages: 194988
nosy: seydou
priority: normal
severity: normal
status: open
title: Tests fail when run with coverage
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 12 21:16:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Aug 2013 19:16:08 +0000
Subject: [New-bugs-announce] [issue18716] Deprecate the formatter module
Message-ID: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Turns out the formatter module isn't really used by anyone. Pydoc uses it, but it could easily use textwrap. Searching on Github shows a usage by someone who simply re-exposes it as part of their own public API but has no actual usage themselves (https://github.com/search?q=%22import+formatter%22&ref=searchresults&type=Code and https://github.com/search?q=%22from+formatter%22&type=Code&ref=searchresults) . A Google search only turns up references in books (https://www.google.ca/search?{google:acceptedSuggestion}oq=%22import+formatter%22&{google:instantFieldTrialGroupParameter}sourceid=chrome&ie=UTF-8&q=%22import+formatter%22&qscrl=1#bav=on.2,or.r_cp.r_qf.&fp=7bfd11bde90d01cb&q=%22import+formatter%22+OR+%22from+formatter%22&qscrl=1).

The attached patch deprecated formatter for removal in Python 3.6.

----------
components: Library (Lib)
files: deprecate_formatter.diff
keywords: patch
messages: 194989
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Deprecate the formatter module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31252/deprecate_formatter.diff

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

From report at bugs.python.org  Mon Aug 12 21:36:54 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 19:36:54 +0000
Subject: [New-bugs-announce] [issue18717] test for request.urlretrieve
Message-ID: <1376336214.18.0.793709816185.issue18717@psf.upfronthosting.co.za>


New submission from Muhammad Jehanzeb:

As part of pyconca sprints, this is my first patch for urlcleanup test

----------
components: Tests
files: test_urllib.py
messages: 194996
nosy: mjehanzeb
priority: normal
severity: normal
status: open
title: test for request.urlretrieve
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31253/test_urllib.py

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

From report at bugs.python.org  Mon Aug 12 22:29:36 2013
From: report at bugs.python.org (David Wolever)
Date: Mon, 12 Aug 2013 20:29:36 +0000
Subject: [New-bugs-announce] [issue18718] datetime documentation
	contradictory on leap second	support
Message-ID: <1376339376.74.0.0279691228671.issue18718@psf.upfronthosting.co.za>


New submission from David Wolever:

The documentation for the `%S` formatter suggests that it supports leap seconds, but the footnote contradicts that:

> The range really is 0 to 61; according to the Posix standard this
> accounts for leap seconds and the (very rare) double leap seconds.
> The time module may produce and does accept leap seconds since it is
> based on the Posix standard, but the datetime module does not accept
> leap seconds in strptime() input nor will it produce them in
> strftime() output.

I propose that the documentation be updated to mirror the 3.X documentation: no leap second in the example and a footnote which makes note of that and suggests using the time module.

----------
assignee: wolever
messages: 195008
nosy: wolever
priority: normal
severity: normal
status: open
title: datetime documentation contradictory on leap second support
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug 12 22:33:24 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Aug 2013 20:33:24 +0000
Subject: [New-bugs-announce] [issue18719] Remove false optimizaton for
	equality comparison of	hashed strings
Message-ID: <1376339604.75.0.978082056671.issue18719@psf.upfronthosting.co.za>


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


----------
components: Interpreter Core
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Remove false optimizaton for equality comparison of hashed strings
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 12 23:10:49 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 12 Aug 2013 21:10:49 +0000
Subject: [New-bugs-announce] [issue18720] Switch suitable constants in the
	socket module to IntEnum
Message-ID: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

As part of original plan and since issue #18264 has been resolved, it's time to dust off some old patches I have for the socket.* module. The socket.AF_* and socket.SOCK_* constants are good candidates for IntEnum conversion.

I'm attaching an initial patch that handles socket.AF_* (as a proof-of-concept; socket.SOCK_* should get identical treatment); it only touches Lib/socket.py and all regrtest tests pass without changes. Result:

>>> import socket
>>> socket.AF_INET
<AddressFamily.AF_INET: 2>
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.family
<AddressFamily.AF_INET: 2>
>>> '{}'.format(s.family)
'AddressFamily.AF_INET'

The code in the patch is pretty well commented, and I also want to point out a couple of decision points that came up:

1. The underlying socketmodule.c has no idea of IntEnums, and neither IMHO it should. These constants are essentially one-way, going from Python into C. They are only exposed back through read-only accessors (e.g. s.family above), at which point the Python code can wrap them back into the enum. The alternative, making socketmodule.c use enums is probably way more complicated than really necessary.
2. As a followup to (1), the constants are actually wrapped into an IntEnum at the Python level and exposed back to the user. My hacking of globals() there may be a bit rough - suggestions for a better way are welcome.
3. A bunch of AF_* constants exported by Python built on my x64 Ubuntu are not documented in socket.rst; I'm still wrapping them all in enums; I basically went over all PyModule_AddIntMacro(m, AF_*) in PyInit__socket.

PTAL

----------
assignee: eli.bendersky
components: Library (Lib)
files: socket-intenum-af.1.patch
keywords: patch
messages: 195018
nosy: barry, eli.bendersky, ethan.furman, gvanrossum, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Switch suitable constants in the socket module to IntEnum
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31261/socket-intenum-af.1.patch

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

From report at bugs.python.org  Mon Aug 12 23:43:36 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Mon, 12 Aug 2013 21:43:36 +0000
Subject: [New-bugs-announce] [issue18721] test for FTP cwd function
Message-ID: <1376343816.8.0.615732489322.issue18721@psf.upfronthosting.co.za>


New submission from Muhammad Jehanzeb:

Test coverage for cwd function of ftplib directory.

----------
components: Tests
messages: 195023
nosy: mjehanzeb
priority: normal
severity: normal
status: open
title: test for FTP cwd function
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug 12 23:46:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 12 Aug 2013 21:46:11 +0000
Subject: [New-bugs-announce] [issue18722] Remove uses of the register keyword
Message-ID: <1376343971.9.0.52964508892.issue18722@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Attached patch removes all uses of the C "register" keyword in the CPython sources.

----------
components: Interpreter Core
files: remove_register.patch
keywords: patch
messages: 195024
nosy: pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Remove uses of the register keyword
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31262/remove_register.patch

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

From report at bugs.python.org  Tue Aug 13 08:26:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 13 Aug 2013 06:26:52 +0000
Subject: [New-bugs-announce] [issue18723] shorten function of textwrap
	module is susceptible to	non-normalized whitespaces
Message-ID: <1376375212.1.0.637444277248.issue18723@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In shorten function of textwrap module, the placeholder becomes a hole where we can inject non-normalized whitespaces to the text.

>>> text = "Hello there, how are you this fine day? I'm glad to hear it!"
>>> from textwrap import shorten
>>> shorten(text, 40, placeholder="              ")
'Hello there, how are you'

We normalize the only-whitespaces placeholder.

But....

>>> shorten(text, 17, placeholder="  \n\t(...)  \n\t[...]  \n\t")
'(...)  \n\t[...]'
>>> shorten(text, 40, placeholder="  \n\t(...)  \n\t[...]  \n\t")
'Hello there, how  \n\t(...)  \n\t[...]'

Attached the patch to normalize the non-normalized whitespaces in placeholder.

----------
components: Library (Lib)
files: fix_for_non_normalized_whitespaces_in_placeholder.patch
keywords: patch
messages: 195045
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: shorten function of textwrap module is susceptible to non-normalized whitespaces
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31271/fix_for_non_normalized_whitespaces_in_placeholder.patch

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

From report at bugs.python.org  Tue Aug 13 09:42:27 2013
From: report at bugs.python.org (Susan Tan)
Date: Tue, 13 Aug 2013 07:42:27 +0000
Subject: [New-bugs-announce] [issue18724] Typo in docs.python.org: smtplib
	python2.7
Message-ID: <1376379747.75.0.914823707462.issue18724@psf.upfronthosting.co.za>


New submission from Susan Tan:

http://docs.python.org/2.7/library/smtplib.html#smtplib.SMTPException 

"exception smtplib.SMTPException
The base exception class for all the other excpetions provided by this module."

The word "exceptions" is spelled incorrectly in the in "other excpetions".

----------
assignee: docs at python
components: Documentation
messages: 195049
nosy: Susan, docs at python
priority: normal
severity: normal
status: open
title: Typo in docs.python.org: smtplib python2.7
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug 13 12:12:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 10:12:58 +0000
Subject: [New-bugs-announce] [issue18725] Multiline shortening
Message-ID: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Functions in the textwrap module works with multiline text except a newly added (in issue18585) the shorten() function. Wrapping and shortening a multiline text using existing textwrap function is not a trivial job.

I propose to add two new parameters to the TextWrap class and wrap() and fill() functions: max_lines and placeholder. If the max_lines argument is specified then wrapped text truncated to max_lines and the last line shortened to the width argument.

>>>print(textwrap('Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.', width=40, max_lines=3))
Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor
incididunt ut labore et dolore (...)

The shorten() function then will be just a particular case of fill() with max_lines=1.

----------
components: Library (Lib)
messages: 195065
nosy: barry, ezio.melotti, georg.brandl, pitrou, python-dev, r.david.murray, serhiy.storchaka, stevenjd, vajrasky
priority: normal
severity: normal
status: open
title: Multiline shortening
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 13 13:18:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Aug 2013 11:18:14 +0000
Subject: [New-bugs-announce] [issue18726] json functions have too many
	positional parameters
Message-ID: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The json module functions have too many positional parameters:

dump() -- 11
dumps() -- 10
load() -- 9
loads() -- 8

In most time only small part of these options is specified so users call these functions with keyword arguments for all parameters except mandatory ones.

Even worse, the simplejson module (an ancestor and an alternative to standard json module) have a very similar interface but with difference sequences of parameters (the second parameter of loads() and the ninth parameter of dumps() in simplejson is encoding). So in any case portable application should specify all but basic arguments as keyword arguments. If json will incorporate some features from simplejson in future positions of new parameters will be different.

I propose to deprecate specifying all but mandatory parameters of json functions as positional arguments in 3.4 and then forbid it in 3.5.

I.e. dumps() should be implemented in 3.4 as:

def dumps(obj, *args, **kwargs):
    if args:
        warnings.warn("The positional arguments are deprecated.",
                     DeprecationWarning, stacklevel=2)
    return _dumps(obj, *args, **kwargs)

def _dumps(obj, skipkeys=False, ensure_ascii=True, check_circular=True,
        allow_nan=True, cls=None, indent=None, separators=None,
        default=None, sort_keys=False, **kwargs):
    ...

and in 3.5 as:

def dumps(obj, *, skipkeys=False, ensure_ascii=True, check_circular=True,
        allow_nan=True, cls=None, indent=None, separators=None,
        default=None, sort_keys=False, **kwargs):
    ...

----------
components: Library (Lib)
messages: 195068
nosy: bob.ippolito, ezio.melotti, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: json functions have too many positional parameters
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 13 18:01:15 2013
From: report at bugs.python.org (Muhammad Jehanzeb)
Date: Tue, 13 Aug 2013 16:01:15 +0000
Subject: [New-bugs-announce] [issue18727] test for writing dictionary rows
	to CSV
Message-ID: <1376409675.57.0.271656920796.issue18727@psf.upfronthosting.co.za>


New submission from Muhammad Jehanzeb:

Test for writing dictionary rows to further enhance the test coverage of CSV lib.

----------
components: Tests
messages: 195083
nosy: brett.cannon, mjehanzeb
priority: normal
severity: normal
status: open
title: test for writing dictionary rows to CSV
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug 13 18:34:54 2013
From: report at bugs.python.org (Alex Volkov)
Date: Tue, 13 Aug 2013 16:34:54 +0000
Subject: [New-bugs-announce] [issue18728] Increased test coverage for
	test_filecmp
Message-ID: <1376411694.99.0.620922615046.issue18728@psf.upfronthosting.co.za>


New submission from Alex Volkov:

I increased test coverage from 68% to 74% of filecmp.py by adding test cases in test_filecmp.py in functions phase2 & phase4 in dircmp class.

----------
components: Tests
files: test_filecmp.patch
keywords: patch
messages: 195085
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for test_filecmp
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31280/test_filecmp.patch

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

From report at bugs.python.org  Tue Aug 13 20:24:47 2013
From: report at bugs.python.org (py.user)
Date: Tue, 13 Aug 2013 18:24:47 +0000
Subject: [New-bugs-announce] [issue18729] In unittest.TestLoader.discover
	doc select the name of	load_tests function
Message-ID: <1376418287.73.0.835584535115.issue18729@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestLoader.discover
"If load_tests exists then discovery does not recurse into the package"

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 195092
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestLoader.discover doc select the name of load_tests function
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31283/issue.diff

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

From report at bugs.python.org  Tue Aug 13 22:54:00 2013
From: report at bugs.python.org (Dan Loewenherz)
Date: Tue, 13 Aug 2013 20:54:00 +0000
Subject: [New-bugs-announce] [issue18730] suffix parameter in
	NamedTemporaryFile silently fails	when not prepending with a period
Message-ID: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>


New submission from Dan Loewenherz:

Basically, when creating a NamedTemporaryFile, passing a value to the "suffix" parameter has no effect unless it's prepended with a period.

IMO, there are three options here...

1. Add a note in the documentation that this parameter only accepts period-prepended values (not ideal but better than the status quo).
2. Change the behavior to throw an exception when a non-period prepended value is provided (probably bad since it would break stuff).
3. Strip invalid values from this input and silently fail if the resulting string is of length 0 (might also break stuff).

----------
components: Library (Lib)
messages: 195097
nosy: dloewenherz
priority: normal
severity: normal
status: open
title: suffix parameter in NamedTemporaryFile silently fails when not prepending with a period
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug 13 23:04:22 2013
From: report at bugs.python.org (Alex Volkov)
Date: Tue, 13 Aug 2013 21:04:22 +0000
Subject: [New-bugs-announce] [issue18731] Increased test coverage for uu and
	telnet
Message-ID: <1376427862.02.0.743044696464.issue18731@psf.upfronthosting.co.za>


Changes by Alex Volkov <avolkov at gmail.com>:


----------
components: Tests
files: telnet_uu_tests.patch
keywords: patch
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for uu and telnet
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31284/telnet_uu_tests.patch

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

From report at bugs.python.org  Tue Aug 13 23:20:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Aug 2013 21:20:31 +0000
Subject: [New-bugs-announce] [issue18732] IdleHistory.History: eliminate
	unused parameter; other cleanup.
Message-ID: <1376428831.4.0.308828193599.issue18732@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

idlelib.IdleHistory is only imported in PyShell.PyShell. History is only instantiated once, with output_sep defaulting to \n. This constant parameter and the consequence splitting and joining with \n in ._get_source and ._put_source are useless. After the tests for this class are committed in #18425, I plan to eliminate the unneeded parameter, splits, joins, and methods and inline the remaining text.get and .insert in .fetch. I want to do a few other transparent modernizations in the .fetch code, such as replacing 4 of the lines with
 pointer += -1 if reverse else 1

----------
assignee: terry.reedy
components: IDLE
messages: 195099
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IdleHistory.History: eliminate unused parameter; other cleanup.
type: performance
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug 14 01:58:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Aug 2013 23:58:20 +0000
Subject: [New-bugs-announce] [issue18733] elementtree: stop the parser more
	quickly on error
Message-ID: <1376438300.88.0.235284556503.issue18733@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When a Python handler of a XML tag fails, the ElementTree parser continues to parse the whole document. It would be nice to stop the parser more quickly.

The pyexpat module unregisters all handlers to fail more quickly. ElementTree may do something similar.

Or does the expat library have a function or attribute to stop the XML parser?

See also the issue #18501 (_elementtree.c calls Python callbacks while a Python exception is set).

----------
components: XML
messages: 195110
nosy: fdrake, haypo
priority: normal
severity: normal
status: open
title: elementtree: stop the parser more quickly on error
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 14 05:15:23 2013
From: report at bugs.python.org (Eddie Stanley)
Date: Wed, 14 Aug 2013 03:15:23 +0000
Subject: [New-bugs-announce] [issue18734] Berkeley DB versions 4.4-4.9 are
	not discovered by	setup.py
Message-ID: <1376450123.08.0.865805118992.issue18734@psf.upfronthosting.co.za>


New submission from Eddie Stanley:

Support for Berkeley DB up to 5.3 was introduced in Python 2.7.4 (see issue #17477) however I'm having problems with the detection code in setup.py.

I'm working on RHEL4, I've got Berkeley DB 4.7.25 installed in /opt/db-4.7.25

When I try and "make" Python, it can't build _bsddb because no suitable version of db.h was found. 

The function gen_db_minor_ver_nums(major) looks as though it's supposed to spit out all the minor versions for a given major, however it doesn't appear to work properly for 4.x - surely 4.3, 4.4, 4.5 ... all the way to 4.9 (or whatever) should be generated. 

It only generates minor version "3" though. The end result is that 4.3 is the only working version in the 4.x series.

----------
components: Build
messages: 195120
nosy: Eddie.Stanley
priority: normal
severity: normal
status: open
title: Berkeley DB versions 4.4-4.9 are not discovered by setup.py
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 14 13:21:30 2013
From: report at bugs.python.org (raymontag)
Date: Wed, 14 Aug 2013 11:21:30 +0000
Subject: [New-bugs-announce] [issue18735] SSL/TLS pinning for the ssl module
Message-ID: <1376479290.6.0.728586195996.issue18735@psf.upfronthosting.co.za>


New submission from raymontag:

Hello,

I would like to see an implementation for SSL/TLS pinning in the sll module of the standard library.

At this moment it's only possible to give the client a CAcert and check if the server's certificate is signed with this CA by creating a ssl.Context object with ssl.Context("/path/to/cafile"). If I don't know the server's certificate, that is I just have the root certificate, this is okay. But if I implement my own server/client structure I know the server's certificate. And here comes pinning into play: If I know server's certificate I could not only check if it's signed with my CA but also if it is the specific certificate I've signed. This is a better protection against MITM e.g. and would be a great enhancement of the ssl module IMHO.

raymontag

----------
messages: 195130
nosy: raymontag
priority: normal
severity: normal
status: open
title: SSL/TLS pinning for the ssl module
type: enhancement

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

From report at bugs.python.org  Wed Aug 14 13:59:06 2013
From: report at bugs.python.org (Basil Peace)
Date: Wed, 14 Aug 2013 11:59:06 +0000
Subject: [New-bugs-announce] [issue18736] Invalid charset in HTML pages
	inside documentation in	CHM format
Message-ID: <1376481546.2.0.725412367622.issue18736@psf.upfronthosting.co.za>


New submission from Basil Peace:

HTML pages inside CHM documentation use the following tag to set applied character set:
    <meta http-equiv="Content-Type" content="text/html; charset=iso8859_1" />

`iso8859_1` is neither valid character set according to IANA registry nor is recognized by most browsers (I've checked IE, Firefox and Opera).

This isn't notable for text in English. But, in `Python Standard Library` in section `4.7.1 String Methods` there is a documentation for str.casefold(). This paragraph contains German letter `?`.
Without defined character set this letter can be displayed wrongly, depending on user's regional settings. In my Russian I see in CHM `?`. Firefox displays it as `?`.

Fix of charset to `ISO-8859-1` could resolve the problem.

P.S. Use of UTF-8 may be more convenient for preventing future errors.

----------
assignee: docs at python
components: Documentation
messages: 195136
nosy: docs at python, grv87
priority: normal
severity: normal
status: open
title: Invalid charset in HTML pages inside documentation in CHM format
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug 14 15:13:13 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 13:13:13 +0000
Subject: [New-bugs-announce] [issue18737] Get virtual subclasses of an ABC
Message-ID: <1376485993.36.0.633495217077.issue18737@psf.upfronthosting.co.za>


New submission from Christian Heimes:

ABCs are missing one important introspection feature. They have no API to get registered virtual subclasses. The patch implements a new method get_virtual_subclasses(recurse=False).

ABC.get_virtual_subclasses() returns the direct virtual subclasses of an ABC. ABC.get_virtual_subclasses(recuse=True) also takes subclasses of the ABC as well as subclasses of registered virtual classes into account.

Example:
>>> import numbers
>>> numbers.Number.get_virtual_subclasses()
set()
>>> numbers.Number.get_virtual_subclasses(True)
{<class 'float'>, <class 'bool'>, <class 'int'>, <class 'complex'>}
>>> numbers.Integral.get_virtual_subclasses()
{<class 'int'>}
>>> numbers.Integral.get_virtual_subclasses(True)
{<class 'int'>, <class 'bool'>}

----------
components: Library (Lib)
files: virtual_subclasses.patch
keywords: patch
messages: 195150
nosy: christian.heimes, rhettinger, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Get virtual subclasses of an ABC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31290/virtual_subclasses.patch

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

From report at bugs.python.org  Wed Aug 14 15:48:56 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 14 Aug 2013 13:48:56 +0000
Subject: [New-bugs-announce] [issue18738] % formatting incomplete for Enum
Message-ID: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>


New submission from Ethan Furman:

While `.format()` works fine with enum, %-formatting does not:

--> class AF(enum.IntEnum):
...   IPv4 = 1
...   IPv6 = 2
... 

--> AF.IPv4
<AF.IPv4: 1>

--> '%s' % AF.IPv4
'AF.IPv4'

--> '%r' % AF.IPv4
'<AF.IPv4: 1>'

--> '%d' % AF.IPv4
'AF.IPv4'

--> '%i' % AF.IPv4
'AF.IPv4'

--> '%x' % AF.IPv4
'1'

--> '%o' % AF.IPv4
'1'

Hex and octal work, decimal and integer do not.

----------
messages: 195160
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
status: open
title: % formatting incomplete for Enum
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 14 17:04:47 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 14 Aug 2013 15:04:47 +0000
Subject: [New-bugs-announce] [issue18739] math.log of a long returns a
	different value of math.log	of an int
Message-ID: <1376492687.31.0.627121997874.issue18739@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

This is a very odd inconsistency in math.log behavior.  That said, it is probably only a single bit imprecision at the end of the float result.  Still, 10 == 10L so I'd expect math.log of both to give the same result.

oss/cpython/2.7:LOAS$ ./python
Python 2.7.5+ (2.7:395ac61ebe1a, Aug 14 2013, 07:11:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(10) - math.log(10L)
4.440892098500626e-16
>>> math.log(10)
2.302585092994046
>>> math.log(10L)
2.3025850929940455
>>> 

In Python 3.3 things seem fine and match the int behavior from 2.7 above despite the internal number implementation being a PyLong in 3.x:

>>> math.log(10)
2.302585092994046

----------
messages: 195175
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: math.log of a long returns a different value of math.log of an int
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 14 18:55:43 2013
From: report at bugs.python.org (Ron Adam)
Date: Wed, 14 Aug 2013 16:55:43 +0000
Subject: [New-bugs-announce] [issue18740] str is number methods don't
	recognize '.'
Message-ID: <1376499343.4.0.632911217056.issue18740@psf.upfronthosting.co.za>


New submission from Ron Adam:

Shouldn't at least isdecimal return True?

>>> '123.0'.isdecimal()
False
>>> '123.0'.isalnum()
False
>>> '123.0'.isnumeric()
False
>>> '123.0'.isdigit()
False

----------
components: Interpreter Core
messages: 195186
nosy: ron_adam
priority: normal
severity: normal
status: open
title: str is number methods don't recognize '.'
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 14 23:21:24 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Wed, 14 Aug 2013 21:21:24 +0000
Subject: [New-bugs-announce] [issue18741] Fix typos/spelling mistakes in
	Lib/*/*/.py files
Message-ID: <1376515284.41.0.228001908428.issue18741@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

Using the same tool described in issue 18705, I fixed more typos.

----------
assignee: docs at python
components: Documentation
files: another_typo_patch.diff
keywords: patch
messages: 195216
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Fix typos/spelling mistakes in Lib/*/*/.py files
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31294/another_typo_patch.diff

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

From report at bugs.python.org  Thu Aug 15 00:31:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 14 Aug 2013 22:31:12 +0000
Subject: [New-bugs-announce] [issue18742] Abstract base class for hashlib
Message-ID: <1376519472.63.0.753349393836.issue18742@psf.upfronthosting.co.za>


New submission from Christian Heimes:

All hashlib types provide a common interfaces but there is no common super class. The patch implements provides hashlib.CryptoHash abstract base class as common virtual class for all hash types.

The patch also exposes all internal types of the internal hash C modules so I don't have to jump throw the type(constructor()) hoop.

I have also changed __get_builtin_constructor() to use a lookup cache instead of importing the module every time. It is necessary to avoid multiple calls to CryptoHash.register().

----------
files: hashlib_abc.patch
keywords: patch
messages: 195226
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Abstract base class for hashlib
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31295/hashlib_abc.patch

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

From report at bugs.python.org  Thu Aug 15 07:01:51 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 15 Aug 2013 05:01:51 +0000
Subject: [New-bugs-announce] [issue18743] References to non-existant
	"StringIO" module
Message-ID: <1376542911.78.0.658455842148.issue18743@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Doing a "grep StringIO Doc/library/*.rst" shows a handful of references to the old StringIO library. Notably:

gzip.rst
mailbox.rst
tempfile.rst
test.rst
unittest.mock.rst
xml.dom.minidom.rst

----------
assignee: docs at python
components: Documentation
messages: 195231
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: References to non-existant "StringIO" module
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug 15 07:20:25 2013
From: report at bugs.python.org (K Richard Pixley)
Date: Thu, 15 Aug 2013 05:20:25 +0000
Subject: [New-bugs-announce] [issue18744] pathological performance using
	tarfile
Message-ID: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>


New submission from K Richard Pixley:

There's a problem with tarfile.  Write a program to traverse the contents of a modest sized tar archive.  Make sure your tar archive is compressed.  Then read the tar archive with your program.

I'm finding that allowing tarfile to read a compressed archive costs me somewhere on the order of a 60x performance penalty by comparison to opening the file with gzip, then passing the gzip contents to tarfile.  Programs that could take a few minutes are literally taking a few hours when using tarfile.

This seems stupid.  The tarfile library could do the same thing I'm doing manually, in fact, I had assumed that it would and was surprised by the performance I was seeing, so I ran with the profiler and saw millions of decompression calls.  It's almost as though the tarfile library is decompressing the entire archive for every member extraction.

Note, you can get even worse performance if you sort the member names and then extract in that order.  I'm not sure whether this "should" matter since the tar file order is sequential.

----------
components: Library (Lib)
messages: 195232
nosy: teamnoir
priority: normal
severity: normal
status: open
title: pathological performance using tarfile
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 15 09:59:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 15 Aug 2013 07:59:00 +0000
Subject: [New-bugs-announce] [issue18745] Test enum in test_json is ignorant
	of infinity value
Message-ID: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Test enum json in Lib/test/test_json/test_enum.py is ignorant of infinity values. Also, NaN, but since NaN is a weirdo, let's not take that into account.

The unit test should represent of what will work in every case. For example:

    def test_floats(self):
         for enum in FloatNum:
            self.assertEqual(self.dumps(enum), repr(enum.value))

This will fail if enum is infinity.

This wisdom about infinity was bestowed upon me when I was reading Lib/test/test_json/test_float.py.

    def test_floats(self):
        for num in [1617161771.7650001, math.pi, math.pi**100, math.pi**-100, 3.1]:
            self.assertEqual(float(self.dumps(num)), num)
            self.assertEqual(self.loads(self.dumps(num)), num)

    def test_ints(self):
        for num in [1, 1<<32, 1<<64]:
            self.assertEqual(self.dumps(num), str(num))
            self.assertEqual(int(self.dumps(num)), num)

As you can see, in float case, we don't use str(num) because it does not work with infinity.

Attached the patch to refactor the test to handle infinity value. For the completeness sake, I added the case of negative infinity and NaN as well.

----------
components: Tests
files: add_infinity_to_test_enum_in_json.patch
keywords: patch
messages: 195238
nosy: ethan.furman, vajrasky
priority: normal
severity: normal
status: open
title: Test enum in test_json is ignorant of infinity value
versions: Python 3.4
Added file: http://bugs.python.org/file31298/add_infinity_to_test_enum_in_json.patch

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

From report at bugs.python.org  Thu Aug 15 12:14:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Aug 2013 10:14:20 +0000
Subject: [New-bugs-announce] [issue18746]
	test_threading.test_finalize_with_trace() fails on	FreeBSD buildbot
Message-ID: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The following test fails on FreeBSD buildbot:

    def test_finalize_with_trace(self):
        # Issue1733757
        # Avoid a deadlock when sys.settrace steps into threading._shutdown
        assert_python_ok("-c", """if 1:
            import sys, threading

            # A deadlock-killer, to prevent the
            # testsuite to hang forever
            def killer():
                import os, time
                time.sleep(2)
                print('program blocked; aborting')
                os._exit(2)
            t = threading.Thread(target=killer)
            t.daemon = True
            t.start()

            # This is the trace function
            def func(frame, event, arg):
                threading.current_thread()
                return func

            sys.settrace(func)
            """)

I ran it manually on my FreeBSD 9.1 VM, I get the following error. I don't know if it's the same error than the buildbot.
----
(...)
# clear builtins._
(...)
# restore sys.stderr
# cleanup __main__
# cleanup[1] _sysconfigdata
(...)
# cleanup[1] threading
Exception ignored in: <function WeakSet.__init__.<locals>._remove at 0x801b11058>
Traceback (most recent call last):
  File "/usr/home/haypo/prog/python/default/Lib/_weakrefset.py", line 38, in _remove
  File "x.py", line 17, in func
AttributeError: 'NoneType' object has no attribute 'current_thread'
# cleanup[1] _weakrefset
(...)
# cleanup[3] _codecs
PyThreadState_Clear: warning: thread still has a frame
----

The weakref is probably threading._dangling.

IMO Py_Finalize() should first clear the trace function. Tracing Python exception while Python is dying (exiting) is insane. I'm surprised that it works :-)

----------
messages: 195244
nosy: haypo, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: test_threading.test_finalize_with_trace() fails on FreeBSD buildbot
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 15 14:35:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Aug 2013 12:35:01 +0000
Subject: [New-bugs-announce] [issue18747] Re-seed OpenSSL's PRNG after fork
Message-ID: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A couple of reports and check-in messages like

  Postgres / pgcrypto CVE-2013-1900
  http://bugs.ruby-lang.org/issues/4579
  http://www.exim.org/lurker/message/20130402.171710.92f14a60.fi.html

suggests that OpenSSL's PRNG should be reset or re-seeded after fork(). Otherwise child processes can generate the same or similar pseudo random values.

Python doesn't have an API to run code before and after fork yet. The patch uses pthread_atfork() for the task. It's available on all pthread platforms -- which are all official supported platforms that have fork(), too.

The patch doesn't use RAND_cleanup() like Postgres because child process would hav to initial the PRNG again by opening and reading from /dev/urandom. The atfork prepare hook pulls from random bytes from the PRNG and stores them in a static buffer. The child handler seeds the PRNG from that buffer + pid + current time. PID and current time are mixed into the state to extenuate race conditions.

----------
components: Extension Modules
files: openssl_prng_atfork.patch
keywords: patch
messages: 195247
nosy: christian.heimes, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Re-seed OpenSSL's PRNG after fork
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31300/openssl_prng_atfork.patch

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

From report at bugs.python.org  Thu Aug 15 15:10:42 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Thu, 15 Aug 2013 13:10:42 +0000
Subject: [New-bugs-announce] [issue18748] libgcc_s.so.1 must be installed
	for pthread_cancel to	work
Message-ID: <1376572242.37.0.931026549367.issue18748@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian:

Running the file couple of times will make the interpreter fail with: libgcc_s.so.1 must be installed for pthread_cancel to work

>From what I've seen it is triggered from PyThread_delete_key (tries to load libgcc_s.so at that time).

How does it happen?

The main thread will close fd 4 (because fh object is getting dereferenced to 0) exactly at the same time libpthread will try to open and read libgcc_s.so with the same descriptor (4)

It's fairly obvious that the file handling in bug.py is a bug, but the interpreter should not crash like that !

This doesn't happen on python2.7. Also, python2.7 appears to be linked with libgcc_s.so.1 directly while the 3.x does not (I've tried 3.2 from ubuntu repos, and built 3.3 and 3.4 myself on ubuntu 12.04.2) - at least that's what ldd indicates.

----------
components: Build, Extension Modules
files: bug.py
messages: 195253
nosy: ionel.mc
priority: normal
severity: normal
status: open
title: libgcc_s.so.1 must be installed for pthread_cancel to work
type: crash
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31301/bug.py

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

From report at bugs.python.org  Thu Aug 15 16:24:39 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 15 Aug 2013 14:24:39 +0000
Subject: [New-bugs-announce] [issue18749] [issue 18606] Re: Add statistics
	module to standard	library
In-Reply-To: <20130815125837.25707.49680@psf.upfronthosting.co.za>
Message-ID: <520CE48B.5000809@pearwood.info>


New submission from Steven D'Aprano:

I hope I'm doing the right thing by replying in-line. This is my first code review, please let me know if I'm doing something wrong.

By the way, the email hasn't gone to the tracker again. Is that a bug in the tracker? I've taken the liberty of changing the address to report at bugs.python.org.

On 15/08/13 22:58, ezio.melotti at gmail.com wrote:
>
> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py
> File Lib/statistics.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode113
> Lib/statistics.py:113: __date__ = "2013-08-13"
> Are these still needed after inclusion?

Probably not. Also the licence will need to be changed.

> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode194
> Lib/statistics.py:194: """
> This would be good in the rst docs, but IMHO docstrings should be less
> verbose.
> If you end up copy/pasting all these in the rst file, you will duplicate
> all the docs and they will risk to get out of sync (in addition to have
> to update both every time).

Personally, I like having detailed docs in the docstring, at my fingers in the interactive interpreter. But I'll follow the consensus here.

> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode277
> Lib/statistics.py:277: assert isinstance(x, float) and
> isinstance(partials, list)
> Is this a good idea?

I think so :-) add_partials is internal/private, and so I don't have to worry about the caller providing wrong arguments, say a non-float. But I want some testing to detect coding errors. Using assert for this sort of internal pre-condition is exactly what assert is designed for.

> http://bugs.python.org/review/18606/diff/8927/Lib/statistics.py#newcode524
> Lib/statistics.py:524: """mode(data [, max_modes]) -> mode(s)
> The form "mode(data, max_modes=1) -> mode(s)" is preferred.

Is it? I see plenty of examples in the standard library of that form, e.g. str.find:

find(...)
     S.find(sub [,start [,end]]) -> int

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py
> File Lib/test/test_statistics.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode46
> Lib/test/test_statistics.py:46: 'missing name "%s" in __all__' % name)
> FWIW This should be already covered by test___all__.

Sorry, I don't understand this. test__all__?

[...]
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode144
> Lib/test/test_statistics.py:144: assert data != sorted(data)
> Why not assertNotEqual?
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode385
> Lib/test/test_statistics.py:385: assert x == inf
> Why not assertEqual?

In general, I use bare asserts for testing code logic, even if the code is test code. So if I use self.assertSpam(...) then I'm performing a unit test of the module being tested. If I use a bare assert, I'm asserting something about the test logic itself.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode417
> Lib/test/test_statistics.py:417: self.assertTrue(math.isnan(sum(data)))
> Since you seem to use this quite often, it might be better to define a
> assertIsNaN (and possibly assertIsNotNaN) in NumericTestCase and provide
> a better error message in case of failure.
> The same could apply for assertIsInf.
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics.py#newcode913
> Lib/test/test_statistics.py:913: self.assertTrue(isinstance(result,
> Decimal))
> assertIsInstance

I used to be able to remember all the unittest assert* methods... there are so many now, 31 not including deprecated aliases.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py
> File Lib/test/test_statistics_approx.py (right):
>
> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode1
> Lib/test/test_statistics_approx.py:1: """Numeric approximated equal
> comparisons and unit testing.
> Do I understand correctly that this is just an helper module used in
> test_statistics and that it doesn't actually test anything from the
> statistics module?

Correct. It does, however, test itself.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode137
> Lib/test/test_statistics_approx.py:137: # and avoid using
> TestCase.almost_equal, because it sucks :-)
> Could you elaborate on this?

Ah, I misspelled "TestCase.AlmostEqual".

- Using round() to test for equal-to-some-tolerance is quite an idiosyncratic way of doing approx-equality tests. I've never seen anyone do it that way before. It surprises me.

- It's easy to think that ``places`` means significant figures, not decimal places.

- There's now a delta argument (when was that added?) that is the same as my absolute error tolerance ``tol``, but no relative error argument.

- You can't set a  per-instance error tolerance.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode241
> Lib/test/test_statistics_approx.py:241: assert len(args1) == len(args2)
> Why not assertEqual?

As above, I use bare asserts to test the test logic, and assertSpam methods to perform the test. In this case, I'm confirming that I haven't created dodgy test data.

> http://bugs.python.org/review/18606/diff/8927/Lib/test/test_statistics_approx.py#newcode255
> Lib/test/test_statistics_approx.py:255: self.assertTrue(approx_equal(b,
> a, tol=0, rel=rel))
> Why not assertApproxEqual?

Because I'm testing the approx_equal function. I can't use assertApproxEqual to test its own internals :-)

----------
messages: 195257
nosy: stevenjd
priority: normal
severity: normal
status: open
title: [issue 18606] Re: Add statistics module to standard library

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

From report at bugs.python.org  Thu Aug 15 19:10:56 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 15 Aug 2013 17:10:56 +0000
Subject: [New-bugs-announce] [issue18750] ''' % [1] doens't fail
Message-ID: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

I think this is a bug.
Can be reproduced on all Pythons (from 2.6 to 3.4a).
Maybe should be fixed for 3.4 only as backward incompatible change.

----------
messages: 195263
nosy: asvetlov
priority: normal
severity: normal
status: open
title: ''' % [1] doens't fail

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

From report at bugs.python.org  Thu Aug 15 20:13:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Aug 2013 18:13:16 +0000
Subject: [New-bugs-announce] [issue18751] A manager's server never joins its
	threads
Message-ID: <1376590396.18.0.712968689777.issue18751@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The Server class in multiprocessing.managers creates daemon threads and never joins them. This is in contrast with e.g. the Pool class, which creates daemon threads but uses util.Finalize to join them.

(not joining daemon threads may have adverse effects such as resource leaks or otherwise unexpected glitches)

Issue spawned from http://bugs.python.org/issue8713#msg195178.

----------
components: Library (Lib)
messages: 195267
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: A manager's server never joins its threads
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 15 23:05:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Aug 2013 21:05:59 +0000
Subject: [New-bugs-announce] [issue18752] Make chain.from_iterable an alias
	for a new	chain_iterable.
Message-ID: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

It has become apparent from various discussions in recent months that chain.from_iterable is at least as useful as chain. In fact, I now think that 'chain' should have been what chain.from_iterable is, with current chain(a,b,c) done as chain((a,b,d)). But too late for that.

Based on today's pydev post* by Eric Smith, I propose that chain_iterable (or chain_from_iterable, but I think the 'from' is not needed) be added to itertools and listed in the index table and documented as a function in its own right. 

This would make the long discussion of how to properly document chain.from_iterable (#18301) moot, as the method could be simply mentioned as a (deprecated) alias of chain_iterable.

* "I think that [itertools.chain.from_iterable] was a mistake, too. As a
recent discussion showed, it's not exactly discoverable. The fact that
it's not mentioned in the list of functions at the top of the
documentation doesn't help. And "chain" is documented as a "module
function", and "chain.from_iterable" as a "classmethod" making it all
the more confusing.

I think itertools.combinations and itertools.combinations_with_replacement is the better example of related
functions that should be followed. Not nested, no special parameters
trying to differentiate them: just two different function names."

If this proposal is rejected, then chain.iterable should be added to the index table. That would make it more discoverable, but not less confusing.

----------
messages: 195290
nosy: eric.smith, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Make chain.from_iterable an alias for a new chain_iterable.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 16 10:31:03 2013
From: report at bugs.python.org (Kees Bos)
Date: Fri, 16 Aug 2013 08:31:03 +0000
Subject: [New-bugs-announce] [issue18753] [c]ElementTree.fromstring fails to
	parse	<value>]]></value>
Message-ID: <1376641863.98.0.614514582932.issue18753@psf.upfronthosting.co.za>


New submission from Kees Bos:

ElementTree.fromstring and cElementTree.fromstring fail on parsing
"<value>]]></value>", but do parse "<value>]]&gt;</value>"

$ python
Python 2.7.3 (default, Apr 10 2013, 05:09:49) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree import cElementTree as ET
>>> ET.fromstring("<value>]]></value>").text
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 124, in XML
cElementTree.ParseError: not well-formed (invalid token): line 1, column 9
>>> ET.fromstring("<value>]]&gt;</value>").text
']]>'
>>> from xml.etree import ElementTree as ET
>>> ET.fromstring("<value>]]></value>").text
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1301, in XML
    parser.feed(text)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1643, in feed
    self._raiseerror(v)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1507, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 1, column 9
>>> ET.fromstring("<value>]]&gt;</value>").text
']]>'
>>>

----------
components: XML
messages: 195315
nosy: kees
priority: normal
severity: normal
status: open
title: [c]ElementTree.fromstring fails to parse <value>]]></value>
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 16 15:40:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Aug 2013 13:40:04 +0000
Subject: [New-bugs-announce] [issue18754] Run Python child processes in
	isolated mode in the test	suite?
Message-ID: <1376660404.79.0.733501229055.issue18754@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 3.4 has a new command line option to run Python in isolated mode: -I.

IMO it would be nice to use this option to make the test suite more independant of the user configuration and the environment.

Attached patch modifies the test.script_helper module to use the new -I option.

Some tests rely on the current directory added to sys.path, so I had to add a python_isolated=False option to script_helper for these tests.

----------
components: Tests
files: test_isolated.patch
keywords: patch
messages: 195331
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: Run Python child processes in isolated mode in the test suite?
versions: Python 3.4
Added file: http://bugs.python.org/file31314/test_isolated.patch

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

From report at bugs.python.org  Fri Aug 16 16:34:55 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 16 Aug 2013 14:34:55 +0000
Subject: [New-bugs-announce] [issue18755] imp read functions do not try to
	re-open files that have	been closed from previous reads
Message-ID: <1376663695.08.0.173153451138.issue18755@psf.upfronthosting.co.za>


New submission from Brett Cannon:

imp._HackedGetData doesn't check if the file it cached from its constructor is still open or not. Since the path had previously been stored it would make sense to try re-opening the file if the file object has already been closed.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 195334
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: imp read functions do not try to re-open files that have been closed from previous reads
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 16 17:21:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Aug 2013 15:21:38 +0000
Subject: [New-bugs-announce] [issue18756] os.urandom() fails under high load
Message-ID: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I have seen complains from e.g. Tarek that os.urandom() fails under high load: https://twitter.com/tarek_ziade/status/362281268215418880

The problem is caused by file descriptor limits. os.urandom() opens /dev/urandom for every call. How about os.urandom() uses a persistent file descriptor? That should eliminate the error. It may alsos speed up os.urandom() because a persistent FD gets rid of open() and close() syscalls.

* open /dev/urandom on first call of os.urandom() and store the fd in a static var
* invalidate, close fd on read() -> EINVAL; open /dev/urandom again
* close fd when interpreter shuts down

----------
components: Extension Modules
messages: 195338
nosy: christian.heimes, haypo, hynek, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: os.urandom() fails under high load
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 16 19:43:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 17:43:35 +0000
Subject: [New-bugs-announce] [issue18757] Fix internal references for
	concurrent modules
Message-ID: <1376675015.24.0.101209198038.issue18757@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of concurrent modules: threading, multiprocessing, concurrent.futures, subprocess, queue, and select.

----------
assignee: docs at python
components: Documentation
messages: 195378
nosy: bquinlan, docs at python, jnoller, pitrou, rhettinger, sbt, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal references for concurrent modules
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 16 20:38:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 18:38:58 +0000
Subject: [New-bugs-announce] [issue18758] Fix internal references in the
	documentation
Message-ID: <1376678338.7.0.979265810368.issue18758@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is a meta issue for fixing broken references in the documentation. I will open a child issues for some groups of modules and finally provide a patch for rest files.

----------
assignee: docs at python
components: Documentation
messages: 195392
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix internal references in the documentation
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 16 21:22:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:22:34 +0000
Subject: [New-bugs-announce] [issue18759] Fix internal doc references for
	logging package
Message-ID: <1376680954.66.0.549191685954.issue18759@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the logging package.

----------
assignee: docs at python
components: Documentation
files: refs.logging.diff
keywords: patch
messages: 195401
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal doc references for logging package
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31324/refs.logging.diff

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

From report at bugs.python.org  Fri Aug 16 21:38:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:38:19 +0000
Subject: [New-bugs-announce] [issue18760] Fix internal doc references for
	the xml package
Message-ID: <1376681899.06.0.47911099673.issue18760@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes internal references in the documentation of the xml package.

----------
assignee: docs at python
components: Documentation
messages: 195404
nosy: christian.heimes, docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl, scoder, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal doc references for the xml package
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 16 21:47:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Aug 2013 19:47:31 +0000
Subject: [New-bugs-announce] [issue18761] Fix internal doc references for
	the email package
Message-ID: <1376682451.08.0.523486132403.issue18761@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a preliminary patch (long lines are not wrapped yet) which fixes internal references in the documentation of the email package.

----------
assignee: docs at python
components: Documentation
files: refs.email.diff
keywords: patch
messages: 195406
nosy: barry, docs at python, eric.araujo, ezio.melotti, georg.brandl, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix internal doc references for the email package
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31326/refs.email.diff

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

From report at bugs.python.org  Fri Aug 16 22:19:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 16 Aug 2013 20:19:40 +0000
Subject: [New-bugs-announce] [issue18762] error in
	test_multiprocessing_forkserver
Message-ID: <1376684380.66.0.0393627862698.issue18762@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

One buildbot has exhibited (sporadic?) errors in test_multiprocessing_forkserver:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/4823/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 195410
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: error in test_multiprocessing_forkserver
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 17 00:23:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Aug 2013 22:23:55 +0000
Subject: [New-bugs-announce] [issue18763] subprocess: file descriptors
	should be closed after	preexec_fn is called
Message-ID: <1376691835.07.0.666456900735.issue18763@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, when passed close_fds=True, the subprocess module closes FDs before calling preexec_fn (if provided). This can be an issue if preexec_fn opens some file descriptors, which would then be inherited in the child process.
Here's a patch with test.

----------
components: Library (Lib)
keywords: needs review, patch
messages: 195434
nosy: gregory.p.smith, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: subprocess: file descriptors should be closed after preexec_fn is called
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 17 01:16:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Aug 2013 23:16:30 +0000
Subject: [New-bugs-announce] [issue18764] The pdb print command prints repr
	instead of str in	python3
Message-ID: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>


New submission from R. David Murray:

In 2.7:

>>> import pdb
>>> from email import message_from_string as m
>>> x = m("To: me\nfrom: you\n\ntest\n")
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) print x
>From nobody Fri Aug 16 19:06:58 2013
To: me
from: you

test


In 3.4:

>>> import pdb
>>> from email import message_from_string as m
>>> x = m("To: me\nfrom: you\n\ntest\n")
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) print x
<email.message.Message object at 0xb707b92c>


Since the print command masks the print function, it is difficult (though
not impossible) to actually get the print representation of something:

(Pdb) print(str(x))
'To: me\nfrom: you\n\ntest\n'
(Pdb) not print(x)
To: me
from: you

test

True


Because print is a function rather than a statement in python3, it might be better to just drop the print command from pdb.  Someone working in Python3 is likely to type "print(...)" at the python3 pdb command line and expect it to work like the print function.

----------
components: Library (Lib)
keywords: easy
messages: 195439
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The pdb print command prints repr instead of str in python3
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 17 01:45:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 16 Aug 2013 23:45:52 +0000
Subject: [New-bugs-announce] [issue18765] unittest needs a way to launch
	pdb.post_mortem or other	debug hooks
Message-ID: <1376696752.64.0.473845221037.issue18765@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

A few times now I've seen people write something that overrides and re-implements the unittest.TestCase run() method, copying most of the implementation but adding one feature:

The ability for pdb.post_mortem() to be called after every phase of execution iff an exception/error was caught (setUp(), the testMethod() call itself and tearDown()).

I really hate seeing people have to copy the run method implementation and modify it.

We could support this either by adding another debugHook() method to the TestCase API.  Proposal: it gets called within the except: clause surrounding each phase of test execution.

Turning on support for automatic pdb.post_mortem(), typically controlled via a flag or other environment configurable as it isn't desirable during automation:

  def debugHook(self):
    if SOMETHING_SAYS_TO_ENABLE_THIS:
      pdb.post_mortem()

no more copy and pasting the run() method.

----------
components: Library (Lib)
messages: 195444
nosy: gregory.p.smith, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest needs a way to launch pdb.post_mortem or other debug hooks
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 17 03:39:46 2013
From: report at bugs.python.org (Phil Webster)
Date: Sat, 17 Aug 2013 01:39:46 +0000
Subject: [New-bugs-announce] [issue18766] IDLE: Autocomplete in editor
	doesn't work for	un-imported modules
Message-ID: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za>


New submission from Phil Webster:

If you open a new editor window in IDLE, some modules will autocomplete (re, os, other common modules used by IDLE) and others will not (textwrap, datetime, ...). The current solution is to run your module or type the imports into the shell window to get completions working, which is not very intuitive. I created a patch that checks the namespace and attempts to import the module automatically if it is not found.

----------
components: IDLE
files: autocomplete_unimported_1.patch
keywords: patch
messages: 195446
nosy: Todd.Rovito, philwebster, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Autocomplete in editor doesn't work for un-imported modules
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31332/autocomplete_unimported_1.patch

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

From report at bugs.python.org  Sat Aug 17 04:24:13 2013
From: report at bugs.python.org (Brian McLaughlin)
Date: Sat, 17 Aug 2013 02:24:13 +0000
Subject: [New-bugs-announce] [issue18767] csv documentation does not note
	default quote constant
Message-ID: <1376706253.43.0.482794872786.issue18767@psf.upfronthosting.co.za>


New submission from Brian McLaughlin:

Documentation should note default quoting behavior of the csv module is csv.QUOTE_MINIMAL

http://hg.python.org/cpython/file/tip/Modules/_csv.c#l420

----------
assignee: docs at python
components: Documentation
files: doc.patch
keywords: patch
messages: 195448
nosy: bemclaugh, docs at python
priority: normal
severity: normal
status: open
title: csv documentation does not note default quote constant
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31333/doc.patch

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

From report at bugs.python.org  Sat Aug 17 17:15:39 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 17 Aug 2013 15:15:39 +0000
Subject: [New-bugs-announce] [issue18768] Wrong documentation of RAND_egd
	function in ssl module
Message-ID: <1376752539.41.0.731008742763.issue18768@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> import ssl
>>> ssl.RAND_egd.__doc__
"RAND_egd(path) -> bytes\n\nQueries the entropy gather daemon (EGD) on the socket named by 'path'.\nReturns number of bytes read.  Raises SSLError if connection to EGD\nfails or if it does provide enough data to seed PRNG."

Compare it to documentation about RAND_egd() function from openssl website (https://www.openssl.org/docs/crypto/RAND_egd.html):

RAND_egd() and RAND_egd_bytes() return the number of bytes read from the daemon on success, and -1 if the connection failed or the daemon did not return enough data to fully seed the PRNG. 

Attached the patch to fix the documentation. I am not sure whether we should put the word "fully" or not.

On the side note:
In line 813 in Modules/_ssl.c (the same file where my patch fixed the documentation about RAND_egd function):

gntype = name-> type;

The space between "->" and "type" irritates my eyes. Maybe we can fix this while we fix the documentation? Anyway, this is not really important. I just want to expose it to public and think this does not deserve a dedicated ticket.

----------
assignee: docs at python
components: Documentation
files: fix_documentation_on_rand_egd_function.patch
keywords: patch
messages: 195482
nosy: christian.heimes, docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Wrong documentation of RAND_egd function in ssl module
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31338/fix_documentation_on_rand_egd_function.patch

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

From report at bugs.python.org  Sat Aug 17 18:30:40 2013
From: report at bugs.python.org (Michael Bikovitsky)
Date: Sat, 17 Aug 2013 16:30:40 +0000
Subject: [New-bugs-announce] [issue18769] argparse remove subparser
Message-ID: <1376757040.66.0.700111900917.issue18769@psf.upfronthosting.co.za>


New submission from Michael Bikovitsky:

It might be useful in some circumstances to be able to remove a subparser, however the module does not provide such functionality.

The proposed method takes the same arguments as the add_parser method and removes the matching subparser from the map (including aliases).

----------
components: Library (Lib)
files: argparse_remove_parser.patch
keywords: patch
messages: 195494
nosy: Michael.Bikovitsky, bethard
priority: normal
severity: normal
status: open
title: argparse remove subparser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31341/argparse_remove_parser.patch

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

From report at bugs.python.org  Sat Aug 17 20:03:06 2013
From: report at bugs.python.org (Vivek Ratnaparkhi)
Date: Sat, 17 Aug 2013 18:03:06 +0000
Subject: [New-bugs-announce] [issue18770] Python insert operation on list
Message-ID: <1376762586.13.0.388208537821.issue18770@psf.upfronthosting.co.za>


New submission from Vivek Ratnaparkhi:

Example 1:

mylist = ['a','b','c','d','e']
mylist.insert(len(mylist),'f')
print(mylist)

Output: ['a', 'b', 'c', 'd', 'e', 'f']

Example 2:

mylist = ['a','b','c','d','e']
mylist.insert(10,'f')
print(mylist)

Output: ['a', 'b', 'c', 'd', 'e', 'f']

Why should mylist.insert(len(mylist), x) be equivalent to mylist.insert(len(mylist)+1000000000, x)

Excepted Output: Should give index error.

----------
messages: 195497
nosy: vivek.ratnaparkhi
priority: normal
severity: normal
status: open
title: Python insert operation on list
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 17 20:57:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Aug 2013 18:57:58 +0000
Subject: [New-bugs-announce] [issue18771] Reduce the cost of hash collisions
	for set objects
Message-ID: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

I'm working on a patch for the lookkey() functions in Object/setobject.c.  The core idea is to follow the probe sequence as usual but to also check an adjacent entry for each probe (i.e. check &table[i & mask] as usual and then check &table[(i & mask) ^ 1] before going on the next probes which are scattered around memory).

On modern processors (anything in the last decade), this is likely to reduce the cost of hash collisions and reduce the number of cache lines fetched from memory.

+ Cache line benefit:  improves the odds that the adjacent probe will be on the same cache line, thereby reducing the total number of cache lines fetched.  This benefit will work for set insertions as well as set lookups (a partial write to a cache line requires that a full cache line be read prior to writing, so it is helpful if we've just examined another slot on the same cache line).

+ Parallel execution:  because the second lookup has no data dependency on the first lookup, some of its instructions can be executed in parallel by the out-of-order engine.

+ Reduced loop overhead:  the second lookup doesn't require a new computation of the index *i* (we just do a XOR 1), a new perturb shift, a new masking of *i*, or a jump to the top of the loop.  In other words, it has all the usual benefits of loop unrolling.

- On the downside, even this partial unrolling when increase the total code size which has the negative effect of blowing other code out of the I-cache (typically 32kb).

? I'm unsure whether the additional if-statements will have a net positive or net negative effect on branch prediction rates (positive because each branch can be tracked separately or negative because additional branches use up more space in the branch prediction tables).  Once the patch is ready, I'll run CacheGrind to get a better sense of what is happening.

----------
components: Interpreter Core
messages: 195506
nosy: haypo, rhettinger
priority: normal
severity: normal
status: open
title: Reduce the cost of hash collisions for set objects
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 17 21:18:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Aug 2013 19:18:11 +0000
Subject: [New-bugs-announce] [issue18772] Fix test_gdb for new sets dummy
	object
Message-ID: <1376767091.28.0.570833332467.issue18772@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Changeset 2c9a2b588a89 broke the pretty-printing of sets by the gdb plugin.
Here is a temptative patch. It works, but I don't know enough to know whether that's the right coding style for a gdb plugin. Dave?

----------
components: Demos and Tools, Interpreter Core
files: gdb_sets_repr.patch
keywords: patch
messages: 195509
nosy: larry, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: Fix test_gdb for new sets dummy object
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31343/gdb_sets_repr.patch

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

From report at bugs.python.org  Sun Aug 18 02:14:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 00:14:01 +0000
Subject: [New-bugs-announce] [issue18773] When a signal handler fails to
	write to the file	descriptor registered with
	``signal.set_wakeup_fd()``,
	an exception does not report the file descriptor
Message-ID: <1376784841.45.0.79172750551.issue18773@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

When a signal handler fails to write to the file descriptor registered with ``signal.set_wakeup_fd()``, an exception does not report which the file descriptor is the problematic one.

Attached the patch to put the file descriptor in the aforementioned exception and modify the unit test accordingly.

----------
components: Extension Modules
files: add_file_descriptor_to_exception_signal_set_wakeup_fd.patch
keywords: patch
messages: 195534
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: When a signal handler fails to write to the file descriptor registered with ``signal.set_wakeup_fd()``, an exception does not report the file descriptor
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31346/add_file_descriptor_to_exception_signal_set_wakeup_fd.patch

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

From report at bugs.python.org  Sun Aug 18 06:58:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 18 Aug 2013 04:58:00 +0000
Subject: [New-bugs-announce] [issue18774] There is still last bit of GNU Pth
	code in signalmodule.c
Message-ID: <1376801880.96.0.197365143686.issue18774@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I read this commit:
http://hg.python.org/cpython/rev/1d5f644b9241

But I noticed there is still GNU Pth code lingering around in Modules/signalmodule.c.

Beside of that the WITH_PTH code (in the same file) is expired already. If you configure python with this option (--with-pth), the configure process will complain that it does not recognize the option.

Attached the patch to clean up this last bit of GNU Pth code.

----------
components: Extension Modules
files: remove_gnu_pth.patch
keywords: patch
messages: 195542
nosy: christian.heimes, vajrasky
priority: normal
severity: normal
status: open
title: There is still last bit of GNU Pth code in signalmodule.c
versions: Python 3.4
Added file: http://bugs.python.org/file31351/remove_gnu_pth.patch

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

From report at bugs.python.org  Sun Aug 18 18:35:57 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 18 Aug 2013 16:35:57 +0000
Subject: [New-bugs-announce] [issue18775] name attribute for HMAC
Message-ID: <1376843757.16.0.673413061043.issue18775@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In issue #18532 name attribute was officially documented and tested for hashing objects. PEP 247 considers HMAC as keyed hashing algorithm. Therefore I suggest that HMAC object should provide the same interface.

It's a bit unfortunate that HMAC has a blocksize attribute for the default blocksize but the API defines a block_size attribute.

----------
components: Library (Lib)
files: hmac_name.patch
keywords: patch
messages: 195570
nosy: christian.heimes, gregory.p.smith, jason.coombs
priority: normal
severity: normal
stage: patch review
status: open
title: name attribute for HMAC
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31360/hmac_name.patch

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

From report at bugs.python.org  Mon Aug 19 01:07:59 2013
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 18 Aug 2013 23:07:59 +0000
Subject: [New-bugs-announce] [issue18776] atexit error display behavior
	changed in python 3
Message-ID: <1376867279.76.0.423082412526.issue18776@psf.upfronthosting.co.za>


New submission from Doug Hellmann:

Under python 2 when an atexit callback raised an exception the full traceback was displayed. Under python 3, only the summary of the exception is shown.

Input file:

import atexit


def exit_with_exception(message):
    raise RuntimeError(message)

atexit.register(exit_with_exception, 'Registered first')
atexit.register(exit_with_exception, 'Registered second')


Python 2:

$ python2.7 source/atexit/atexit_exception.py
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "source/atexit/atexit_exception.py", line 36, in exit_with_exception
    raise RuntimeError(message)
RuntimeError: Registered second
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "source/atexit/atexit_exception.py", line 36, in exit_with_exception
    raise RuntimeError(message)
RuntimeError: Registered first
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "source/atexit/atexit_exception.py", line 36, in exit_with_exception
    raise RuntimeError(message)
RuntimeError: Registered first

Python 3:

$ python3.3 source/atexit/atexit_exception.py
Error in atexit._run_exitfuncs:
RuntimeError: Registered second
Error in atexit._run_exitfuncs:
RuntimeError: Registered first

----------
messages: 195586
nosy: doughellmann
priority: normal
severity: normal
status: open
title: atexit error display behavior changed in python 3
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Aug 19 07:31:27 2013
From: report at bugs.python.org (Vitaly Murashev)
Date: Mon, 19 Aug 2013 05:31:27 +0000
Subject: [New-bugs-announce] [issue18777] Cannot compile _ssl.c using
	openssl > 1.0
Message-ID: <1376890287.78.0.562230025847.issue18777@psf.upfronthosting.co.za>


New submission from Vitaly Murashev:

Cannot compile _ssl module when openssl version > 1.0 and it is configured with turned on macro OPENSSL_NO_DEPRECATED

Everything looks like in recent versions of openssl routine 'CRYPTO_set_id_callback' has gone away.

Patch suggested.

----------
components: Build
files: ssl.patch
keywords: patch
messages: 195602
nosy: vmurashev
priority: normal
severity: normal
status: open
title: Cannot compile _ssl.c using openssl > 1.0
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file31368/ssl.patch

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

From report at bugs.python.org  Mon Aug 19 09:20:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 07:20:20 +0000
Subject: [New-bugs-announce] [issue18778] email docstrings and comments say
	about Unicode strings
Message-ID: <1376896820.36.0.260467198244.issue18778@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

email docstrings and comments uses the "Unicode string" term and refer to the unicode() built-in. In 3.x this should be corrected to "string" and "str()". Perhaps some code (for example coercing a charset name to Unicode) is not needed more.

----------
components: email
messages: 195605
nosy: barry, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: email docstrings and comments say about Unicode strings
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Aug 19 09:45:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 19 Aug 2013 07:45:16 +0000
Subject: [New-bugs-announce] [issue18779] Misleading documentations and
	comments in regular	expression about alphanumerics and underscore
Message-ID: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

According to:

http://oald8.oxfordlearnersdictionaries.com/dictionary/alphanumeric
http://en.wikipedia.org/wiki/Alphanumeric

Alphanumeric is defined as [A-Za-z0-9]. Underscore (_) is not one of them. One of the documentation in Python (Doc/tutorial/stdlib2.rst) differentiates them very clearly:

"The format uses placeholder names formed by ``$`` with valid Python identifiers
(alphanumeric characters and underscores).  Surrounding the placeholder with
braces allows it to be followed by more alphanumeric letters with no intervening
spaces.  Writing ``$$`` creates a single escaped ``$``::"

Yet, in documentations as well as comments in regex, we implicitely assumes underscore belongs to alphanumeric.

Explicit is better than implicit!

Attached the patch to differentiate alphanumeric and underscore in documentations and comments in regex.

This is important in case someone is confused with this code:
>>> import re
>>> re.split('\W', 'haha$hihi*huhu_hehe hoho')
['haha', 'hihi', 'huhu_hehe', 'hoho']

On the side note:
In Python code base, sometimes we write "alphanumerics" and "underscores", yet sometimes we write "alphanumeric characters" and "underscore characters". Which one again is the true way?

----------
assignee: docs at python
components: Documentation
files: fix_alphanumeric_and_underscore_doc_in_regex.patch
keywords: patch
messages: 195611
nosy: akuchling, docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Misleading documentations and comments in regular expression about alphanumerics and underscore
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31371/fix_alphanumeric_and_underscore_doc_in_regex.patch

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

From report at bugs.python.org  Mon Aug 19 16:10:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 14:10:34 +0000
Subject: [New-bugs-announce] [issue18780] SystemError when formatting int
	subclass
Message-ID: <1376921434.69.0.557024484243.issue18780@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> class I(int):
...     def __str__(self):
...         return 'spam'
... 
>>> '%i' % (I(42),)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/unicodeobject.c:13595: bad argument to internal function

This issue is related to issue18738 and will be fixed when use PyNumber_ToBase() for any int subclass (not only for bool).

----------
messages: 195631
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: SystemError when formatting int subclass
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Aug 19 17:05:40 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 19 Aug 2013 15:05:40 +0000
Subject: [New-bugs-announce] [issue18781] re.escape escapes underscore
	(Python 2.7)
Message-ID: <1376924740.46.0.92680141708.issue18781@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python --version
Python 2.7.5+
$ ./python
Python 2.7.5+ (2.7:062533327ad2, Aug 19 2013, 22:44:52) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.escape('_')
'\\_'

Python 3.3 and 3.4 got it right and don't escape the underscore.

Because many people are still doing their livelihoods with Python 2.7 and I am a compassionate person, here is the patch to fix the bug in Python 2.7.

----------
components: Regular Expressions
files: dont_escape_underscore_in_regex_27.patch
keywords: patch
messages: 195638
nosy: ezio.melotti, mrabarnett, vajrasky
priority: normal
severity: normal
status: open
title: re.escape escapes underscore (Python 2.7)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31373/dont_escape_underscore_in_regex_27.patch

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

From report at bugs.python.org  Mon Aug 19 17:33:25 2013
From: report at bugs.python.org (Timothy O'Keefe)
Date: Mon, 19 Aug 2013 15:33:25 +0000
Subject: [New-bugs-announce] [issue18782] sqlite3 row factory and
	multiprocessing map
Message-ID: <1376926405.17.0.0447575429203.issue18782@psf.upfronthosting.co.za>


New submission from Timothy O'Keefe:

If you run this code, you will get a segfault. If you a) remove the row factory from the following code or b) use the standard library map() instead of multiprocessing.Pool.map, then the code does not crash.

#!/usr/bin/env python

import sqlite3
import multiprocessing as mp

def main():
    ## --- create a database
    conn = sqlite3.connect(':memory:')
    conn.row_factory = sqlite3.Row
    c = conn.cursor()

    ## --- create example table similar to python docs
    c.execute('''CREATE TABLE stocks (date text, trans text, symbol text, qty real, price real)''')
    c.execute("INSERT INTO stocks VALUES ('2006-01-05','BUY','GOOG',100,869.29)")
    c.execute("INSERT INTO stocks VALUES ('1992-01-06','SELL','AAPL',20,512.99)")
    c.execute("SELECT * FROM stocks")

    ## --- map fun over cursor iterable (fun does nothing)
    pool = mp.Pool(processes=mp.cpu_count())
    features = pool.map(fun, c)

def fun(row):
    return row

if __name__ == "__main__":
    main()

----------
messages: 195641
nosy: tokeefe
priority: normal
severity: normal
status: open
title: sqlite3 row factory and multiprocessing map
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug 19 19:35:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Aug 2013 17:35:23 +0000
Subject: [New-bugs-announce] [issue18783] No more refer to Python "long"
Message-ID: <1376933723.97.0.818285065385.issue18783@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which removes (almost all) mentions of Python long type from docstrings, exception messages and comments.

----------
files: no_long.patch
keywords: patch
messages: 195650
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: No more refer to Python "long"
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31376/no_long.patch

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

From report at bugs.python.org  Mon Aug 19 19:49:28 2013
From: report at bugs.python.org (Evgeny Sologubov)
Date: Mon, 19 Aug 2013 17:49:28 +0000
Subject: [New-bugs-announce] [issue18784] minor uuid.py loading optimization
Message-ID: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za>


New submission from Evgeny Sologubov:

Please see the patch attached.
It quite is primitive and self-explanatory: the code wouldn't attempt to load *libc* via ctypes.CDLL, if all necessary functions are already found in *libuuid*.

This patch also can serve as a work-around solution to issue #17213 
(which I encountered on cygwin+python27)

----------
components: Library (Lib), Windows, ctypes
files: uuid.patch
keywords: patch
messages: 195653
nosy: eugals
priority: normal
severity: normal
status: open
title: minor uuid.py loading optimization
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file31377/uuid.patch

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

From report at bugs.python.org  Mon Aug 19 23:24:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Aug 2013 21:24:42 +0000
Subject: [New-bugs-announce] [issue18785] Add get_body and iter_attachments
	to provisional email	API
Message-ID: <1376947482.78.0.757583569107.issue18785@psf.upfronthosting.co.za>


New submission from R. David Murray:

I'm working on completing the API changes for the email package for 3.4.  This means I'm adding some more stuff to the current provisional API, which I will then aim to make non-provisional in 3.5.

I've made a complete proposal to the email-sig, and have gotten some positive feedback but no detailed reviews yet.

One part of the new API proposal is independent of the rest, and I've documented that part and implemented it.  I'm posting the patch for that part.  The patch includes some of the documentation for the rest, though not all of it...you can ignore all the doc changes in the new doc page except for the docs for the three new methods implemented by the patch for the purposes of reviewing this patch, though of course feedback on the (incomplete) rest is welcome.

I'm posting this now because this part of the enhancement can be reviewed independently of the other changes.

Note: I'm aware that MIMEMessage duplicates the name of a class in the mime subpackage.  By the time I'm done that class will be deprecated (in 3.5).  I haven't got that approved by the SIG yet, though, so it may change :)

----------
components: email
files: get_body_iter_attachments.patch
keywords: patch
messages: 195669
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add get_body and iter_attachments to provisional email API
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31379/get_body_iter_attachments.patch

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

From report at bugs.python.org  Mon Aug 19 23:33:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Aug 2013 21:33:37 +0000
Subject: [New-bugs-announce] [issue18786] test_multiprocessing_spawn crashes
	under PowerLinux
Message-ID: <1376948017.66.0.62278437821.issue18786@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x

[319/379] test_multiprocessing_spawn
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 2 leaked semaphores to clean up at shutdown
  len(cache))
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:133: UserWarning: semaphore_tracker: '/mp-t89tlie_': [Errno 2] No such file or directory
  warnings.warn('semaphore_tracker: %r: %s' % (name, e))
make: *** [buildbottest] User defined signal 1
Process PoolWorker-777:
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/pool.py", line 123, in worker
    put((job, i, result))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/queues.py", line 368, in put
    self._writer.send_bytes(obj)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 202, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 401, in _send_bytes
    self._send(struct.pack("!i", n))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 371, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/process.py", line 255, in _bootstrap
    self.run()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/process.py", line 92, in run
    self._target(*self._args, **self._kwargs)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/pool.py", line 128, in worker
    put((job, i, (False, wrapped)))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/queues.py", line 368, in put
    self._writer.send_bytes(obj)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 202, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 401, in _send_bytes
    self._send(struct.pack("!i", n))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py", line 371, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 4 leaked semaphores to clean up at shutdown
  len(cache))
program finished with exit code 2
elapsedTime=4624.019498

----------
assignee: sbt
components: Library (Lib), Tests
messages: 195673
nosy: David.Edelsohn, pitrou, sbt
priority: critical
severity: normal
status: open
title: test_multiprocessing_spawn crashes under PowerLinux
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 20 06:13:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 20 Aug 2013 04:13:01 +0000
Subject: [New-bugs-announce] [issue18787] Misleading error from getspnam
	function of spwd module
Message-ID: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

As root:

$ sudo python3
[sudo] password for ethan: 
Python 3.2.3 (default, Apr 10 2013, 05:07:54) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import spwd
>>> spwd.getspnam("I_don't_exist")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getspnam(): name not found'
>>> spwd.getspnam("bin")
spwd.struct_spwd(sp_nam='bin', sp_pwd='*', sp_lstchg=15259, sp_min=0, sp_max=99999, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1)

As normal user:

$ python3
Python 3.2.3 (default, Apr 10 2013, 05:07:54) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import spwd
>>> spwd.getspnam("I_don't_exist")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getspnam(): name not found'
>>> spwd.getspnam("bin")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'getspnam(): name not found'

People can be confused. How could the name not found if the name actually exists?

Attached the patch to differentiate the error whether the error is really 'name not found' or 'permission denied'.

I use the error message from the getspnam manual:
http://man7.org/linux/man-pages/man3/getspnam.3.html

There is another error message from getspnam beside EACCES (permission denied), which is ERANGE, but I don't think we need to handle this.

----------
components: Extension Modules
files: fix_error_message_getspnam.patch
keywords: patch
messages: 195678
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Misleading error from getspnam function of spwd module
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31380/fix_error_message_getspnam.patch

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

From report at bugs.python.org  Tue Aug 20 06:59:08 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Aug 2013 04:59:08 +0000
Subject: [New-bugs-announce] [issue18788] Proof of concept: implicit call
	syntax
Message-ID: <1376974748.83.0.329764233469.issue18788@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

After watching one of the presenters at PyTexas struggle painfully with the fact "print value" doesn't work in Python 3, I decided I had to at least *try* to see if a general "implicit call" syntax was feasible within the constraints of the CPython parser.

The attached patch shows that it is, indeed, possible to implement such a syntax by modifying the definition of expr_stmt to allow for an implicit trailing argument list (using the normal argument syntax).

The key benefit of such a feature is that the following would once again be legal Python syntax:

    print "Hello world!"

Ambiguous cases (such as "expr * expr" and "expr ** expr") obey the rule that implicit calls are very *low* precedence, so you have to use parens to force the call interpretation. Similarly, a bare expression is not call - you must still append () to force a call without arguments.

In addition to being a pain at the interactive prompt, the change of print from a statement to a function has also been noted as one of the biggest problems with compatibility of third party user scripts for Linux distros changing the default system Python to Python 3. This change would mean most Python 2 print statements either do nothing (no arguments), produce an unexpected trailing newline (trailing comma) or work exactly as they do in Python 2. Only those that use the Python 2 redirection syntax continue to trigger a syntax error in Python 3.

While the *code* changes to achieve this behaviour turned out to be relatively small (most of the diff is in the autogenerated parser code), the documentation and general pedagogical impact could be substantially larger.

If there's even an outside chance this could be accepted, I'm happy to work up a full PEP for it.

----------
files: implicit_call_statements.diff
keywords: patch
messages: 195679
nosy: gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: Proof of concept: implicit call syntax
Added file: http://bugs.python.org/file31381/implicit_call_statements.diff

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

From report at bugs.python.org  Tue Aug 20 16:22:54 2013
From: report at bugs.python.org (Joe Tennies)
Date: Tue, 20 Aug 2013 14:22:54 +0000
Subject: [New-bugs-announce] [issue18789] XML Vunerability Table Unclear
Message-ID: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za>


New submission from Joe Tennies:

EASY

This is an issue with the 2.x and 3.x documentation.

http://docs.python.org/3.2/library/xml.html#xml-vulnerabilities
http://docs.python.org/dev/library/xml.html#xml-vulnerabilities
http://docs.python.org/2/library/xml.html#xml-vulnerabilities

This section has a table with a bunch of Trues and Falses. This is a bit confusing, especially for something that is trying to describe security concerns. After looking at the table, I'm pretty sure that True means vunerable (only due to the (1), (2), & (3) comments), but it's not clear. All that is needed is a heading stating "Vunerable", or change the "True" to "Vunerable" and "False" to "Not Vunerable" (probably V and NV w/ a legend).

----------
assignee: docs at python
components: Documentation
messages: 195691
nosy: docs at python, joe-tennies
priority: normal
severity: normal
status: open
title: XML Vunerability Table Unclear
type: security
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/issue18789>
_______________________________________

From report at bugs.python.org  Tue Aug 20 20:58:24 2013
From: report at bugs.python.org (purplezephyr)
Date: Tue, 20 Aug 2013 18:58:24 +0000
Subject: [New-bugs-announce] [issue18790] incorrect text in argparse
	add_help example
Message-ID: <1377025104.92.0.641943823333.issue18790@psf.upfronthosting.co.za>


New submission from purplezephyr:

The last example under add_help in the documentation for the argparse module has incorrect text.  It is supposed to demonstrate what happens when prefix_chars doesn't include '-', and add_help is True, but the example has the following:

  usage: PROG [-h]

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

instead of:

  usage: PROG [+h]

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

----------
assignee: docs at python
components: Documentation
messages: 195710
nosy: docs at python, purplezephyr
priority: normal
severity: normal
status: open
title: incorrect text in argparse add_help example
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Aug 20 22:33:44 2013
From: report at bugs.python.org (lolo27)
Date: Tue, 20 Aug 2013 20:33:44 +0000
Subject: [New-bugs-announce] [issue18791] PIL freeze reading Jpeg file
Message-ID: <1377030824.64.0.335322556531.issue18791@psf.upfronthosting.co.za>


New submission from lolo27:

With this Python program and 20070517-152405_lovers_4 (copie).jpg  (this file is ok whith Gimp and others programs).

Program "freeze" ( line print "Done" is not processing).

---------------------------------------------
from PIL import Image
from PIL.ExifTags import TAGS
 
def get_exif(fn):
    ret = {}
    i = Image.open(fn)
    info = i._getexif()
    for tag, value in info.items():
        decoded = TAGS.get(tag, tag)
        ret[decoded] = value
    return ret
    
    
get_exif("./20070517-152405_lovers_4 (copie).jpg")
print "Done"

---------------------------------------------
Console output  :

Traceback (most recent call last):
  File "pil_exif.py", line 14, in <module>
    get_exif("./20070517-152405_lovers_4 (copie).jpg")
  File "pil_exif.py", line 7, in get_exif
    info = i._getexif()
  File "/usr/lib/python2.7/dist-packages/PIL/JpegImagePlugin.py", line 381, in _getexif
    info.load(file)
  File "/usr/lib/python2.7/dist-packages/PIL/TiffImagePlugin.py", line 348, in load
    for i in range(i16(fp.read(2))):
  File "/usr/lib/python2.7/dist-packages/PIL/TiffImagePlugin.py", line 68, in il16
    return ord(c[o]) + (ord(c[o+1])<<8)
IndexError: string index out of range
------------------------------------

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

Linux Mint : Linux mystation 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
Python :  2.7.3rc2 (no additional lib installed)
TiffImagePlugin.py : __version__ = "1.3.5"

----------
files: 20070517-152405_lovers_4 (copie).jpg
messages: 195715
nosy: lolo27
priority: normal
severity: normal
status: open
title: PIL freeze reading Jpeg file
type: crash
Added file: http://bugs.python.org/file31387/20070517-152405_lovers_4 (copie).jpg

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

From report at bugs.python.org  Tue Aug 20 23:01:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 21:01:29 +0000
Subject: [New-bugs-announce] [issue18792] test_ftplib timeouts
Message-ID: <1377032489.22.0.759563431169.issue18792@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Some ftplib tests sometimes time out. Seem they seem to try to connect to "localhost" (rather than "127.0.0.1"), I was wondering if this could be a DNS issue and if we should resolve "localhost" in advance like Charles-Fran?ois did for some other tests (or simply hardcode "127.0.0.1", actually).

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

(example:

======================================================================
ERROR: testTimeoutDefault (test.test_ftplib.TestTimeouts)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ftplib.py", line 953, in testTimeoutDefault
    ftp = ftplib.FTP("localhost")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 115, in __init__
    self.connect(host)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\ftplib.py", line 150, in connect
    source_address=self.source_address)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 454, in create_connection
    raise err
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\socket.py", line 445, in create_connection
    sock.connect(sa)
socket.timeout: timed out

)

----------
components: Tests
messages: 195717
nosy: giampaolo.rodola, neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ftplib timeouts
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug 20 23:59:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 20 Aug 2013 21:59:05 +0000
Subject: [New-bugs-announce] [issue18793] occasional
	test_multiprocessing_forkserver failure on	FreeBSD 10.0
Message-ID: <1377035945.43.0.272426045772.issue18793@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/243

[259/379] test_multiprocessing_forkserver
Process Process-246:
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/process.py", line 255, in _bootstrap
    self.run()
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/process.py", line 92, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/_test_multiprocessing.py", line 3388, in child
    p.start()
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/process.py", line 108, in start
    self._popen = Popen(self)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen.py", line 35, in Popen
    return _Popen(process_obj)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen_forkserver.py", line 36, in __init__
    super().__init__(process_obj)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen_fork.py", line 21, in __init__
    self._launch(process_obj)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/popen_forkserver.py", line 52, in _launch
    self.sentinel, w = forkserver.connect_to_new_process(self._fds)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/forkserver.py", line 67, in connect_to_new_process
    reduction.sendfds(client, allfds)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/reduction.py", line 145, in sendfds
    sock.sendmsg([msg], [(socket.SOL_SOCKET, socket.SCM_RIGHTS, fds)])
OSError: [Errno 9] Bad file descriptor
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/forkserver.py", line 161, in main
    _serve_one(s, listener, alive_r, handler)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/forkserver.py", line 187, in _serve_one
    fds = reduction.recvfds(s, MAXFDS_TO_SEND + 1)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/reduction.py", line 155, in recvfds
    raise EOFError
EOFError
Timeout (1:00:00)!
Thread 0x0000000801c06400:
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/connection.py", line 385 in _recv
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/connection.py", line 408 in _recv_bytes
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/multiprocessing/connection.py", line 252 in recv
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/_test_multiprocessing.py", line 3400 in test_lock
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 496 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 535 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 105 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 67 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1637 in _run_suite
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1671 in run_unittest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1304 in <lambda>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1305 in runtest_inner
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 998 in runtest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 796 in main
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1590 in main_in_temp_cwd
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 195718
nosy: koobs, pitrou, sbt
priority: normal
severity: normal
status: open
title: occasional test_multiprocessing_forkserver failure on FreeBSD 10.0
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 21 00:20:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Aug 2013 22:20:01 +0000
Subject: [New-bugs-announce] [issue18794] select.devpoll objects have no
	close() method
Message-ID: <1377037201.39.0.250253331.issue18794@psf.upfronthosting.co.za>


New submission from STINNER Victor:

select.epoll and select.kqueue objects have a close() method, but not select.poll objects, whereas all these objects store internally a file descriptor.

select.poll lacks also a fileno() method.

I added the fileno() method in my implementation of the PEP 446 (see issue #18571).

----------
messages: 195721
nosy: gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: select.devpoll objects have no close() method
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 21 01:48:11 2013
From: report at bugs.python.org (Alexandre Dias)
Date: Tue, 20 Aug 2013 23:48:11 +0000
Subject: [New-bugs-announce] [issue18795] pstats - allow stats sorting by
	cumulative time per call	and total time per call
Message-ID: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>


New submission from Alexandre Dias:

Me and a couple of colleagues have stumbled upon the need to sometimes sort our profiling stats by time (cumulative and total) per call. I believe this could be useful to other people, and have therefore opened this patch.

Thanks for taking the time to look into it.

-Alexandre

----------
components: Library (Lib)
files: pstats.py
messages: 195731
nosy: alexnvdias
priority: normal
severity: normal
status: open
title: pstats - allow stats sorting by cumulative time per call and total time per call
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file31391/pstats.py

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

From report at bugs.python.org  Wed Aug 21 04:56:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 21 Aug 2013 02:56:59 +0000
Subject: [New-bugs-announce] [issue18796] Wrong documentation of show_code
	function from dis module
Message-ID: <1377053819.02.0.986969704551.issue18796@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python
Python 3.4.0a1+ (default:afb1b4797419, Aug 21 2013, 09:54:46) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> import sys
>>> def spam(x):
...   return x * 2
... 
>>> dis.show_code(spam, file=sys.stderr)
Name:              spam
Filename:          <stdin>
Argument count:    1
Kw-only arguments: 0
Number of locals:  1
Stack size:        2
Flags:             OPTIMIZED, NEWLOCALS, NOFREE
Constants:
   0: None
   1: 2
Variable names:
   0: x
>>> output = open('/tmp/output.txt', 'w')
>>> dis.show_code(spam, file=output)
>>> output.close()
>>> dis.show_code.__doc__
'Print details of methods, functions, or code to stdout.'

Attached the patch to fix the documentation.

----------
assignee: docs at python
components: Documentation
files: fix_doc_show_code.patch
keywords: patch
messages: 195742
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Wrong documentation of show_code function from dis module
versions: Python 3.4
Added file: http://bugs.python.org/file31392/fix_doc_show_code.patch

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

From report at bugs.python.org  Wed Aug 21 09:55:45 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Aug 2013 07:55:45 +0000
Subject: [New-bugs-announce] [issue18797] Don't needlessly change refcounts
	of dummy objects for	sets
Message-ID: <1377071745.56.0.580609331428.issue18797@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

AFAICT, there is no reason for sets to incref and decref dummy objects.  The dummy object address is used as placeholders in the hash table but it is never accessed by set the logic.   As long the one reference is held at the time the dummy object is created, nothing further is served by the increfs and decrefs.

I can take them out entirely or use ifdefs to keep them for debug builds.

Does anyone know of any issues?

----------
components: Interpreter Core
files: no_refcnt_dummy1.diff
keywords: patch
messages: 195751
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Don't needlessly change refcounts of dummy objects for sets
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file31394/no_refcnt_dummy1.diff

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

From report at bugs.python.org  Wed Aug 21 12:29:20 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 21 Aug 2013 10:29:20 +0000
Subject: [New-bugs-announce] [issue18798] Typo and unused variables in test
	fcntl
Message-ID: <1377080960.53.0.565624911125.issue18798@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Typo in line 11:
# Skip test if no fnctl module.

Unused variables rv in test_fcntl_file_descriptor method.

Attached the patch to clean up the test.

----------
components: Tests
files: fix_typo_unused_variables_in_test_fcntl.patch
keywords: patch
messages: 195768
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Typo and unused variables in test fcntl
versions: Python 3.4
Added file: http://bugs.python.org/file31398/fix_typo_unused_variables_in_test_fcntl.patch

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

From report at bugs.python.org  Wed Aug 21 17:57:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 21 Aug 2013 15:57:23 +0000
Subject: [New-bugs-announce] [issue18799] Resurrect and fix test_404 in
	Lib/test/test_xmlrpc.py
Message-ID: <1377100643.52.0.970396135479.issue18799@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is a dormant test in Lib/test/test_xmlrpc.py (line 579):

    # [ch] The test 404 is causing lots of false alarms.
    def XXXtest_404(self):
        # send POST with http.client, it should return 404 header and
        # 'Not Found' message.
        conn = httplib.client.HTTPConnection(ADDR, PORT)
        conn.request('POST', '/this-is-not-valid')
        response = conn.getresponse()
        conn.close()

        self.assertEqual(response.status, 404)
        self.assertEqual(response.reason, 'Not Found')

I decided to test it by removing 'XXX' and adding 'import httplib'. Yes, it hung up.

But then I looked at its sibling:

    def test_partial_post(self):
        # Check that a partial POST doesn't make the server loop: issue #14001.
        conn = http.client.HTTPConnection(ADDR, PORT)
        conn.request('POST', '/RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nbye')
        conn.close()

I tried to use http module instead of httplib. It works. I tested it on Linux and Windows Vista. It works on both platforms.

Attached the patch to fix the resurrect and fix the test_404.

----------
components: Tests
files: fix_test_404.patch
keywords: patch
messages: 195800
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Resurrect and fix test_404 in Lib/test/test_xmlrpc.py
versions: Python 3.4
Added file: http://bugs.python.org/file31401/fix_test_404.patch

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

From report at bugs.python.org  Wed Aug 21 19:05:46 2013
From: report at bugs.python.org (icedream91)
Date: Wed, 21 Aug 2013 17:05:46 +0000
Subject: [New-bugs-announce] [issue18800] Document Fraction's numerator and
	denominator properties
Message-ID: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>


New submission from icedream91:

The document (http://docs.python.org/3/library/fractions.html) doesn't mention Fraction's numerator and denominator properties, I knew these properties from dir().

Since sometimes these two properties are very useful, for example: http://projecteuler.net/problem=33 and http://projecteuler.net/problem=57 , I think document should mention them. 

Thanks.

----------
assignee: docs at python
components: Documentation
messages: 195808
nosy: docs at python, icedream91
priority: normal
severity: normal
status: open
title: Document Fraction's numerator and denominator properties
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug 21 21:51:34 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 21 Aug 2013 19:51:34 +0000
Subject: [New-bugs-announce] [issue18801] inspect.classify_class_attrs()
	misclassifies	object.__new__()
Message-ID: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za>


New submission from Eric Snow:

>>> pprint.pprint(inspect.classify_class_attrs(object))
[Attribute(name='__class__', kind='data', defining_class=<class 'object'>, object=<attribute '__class__' of 'object' objects>),
...
 Attribute(name='__init__', kind='method', defining_class=<class 'object'>, object=<slot wrapper '__init__' of 'object' objects>),
...
 Attribute(name='__new__', kind='data', defining_class=<class 'object'>, object=<built-in method __new__ of type object at 0x8aee20>),
...
]

I haven't had a chance to look into why __new__() falls through the cracks but expect it's due to how __new__() is treated like a staticmethod without being one.  I suppose there could be other similar cases, but __new__() is probably the only oddball here.

An extra test using isbuiltin() fixes this.

         else:
             obj_via_getattr = getattr(cls, name)
             if (ismethod(obj_via_getattr) or
-                ismethoddescriptor(obj_via_getattr)):
+                ismethoddescriptor(obj_via_getattr) or
+                isbuiltin(obj_via_getattr)):
                 kind = "method"
             else:
                 kind = "data"

----------
components: Library (Lib)
messages: 195818
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: inspect.classify_class_attrs() misclassifies object.__new__()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug 21 23:00:57 2013
From: report at bugs.python.org (Jon Foster)
Date: Wed, 21 Aug 2013 21:00:57 +0000
Subject: [New-bugs-announce] [issue18802] ipaddress documentation errors
Message-ID: <1377118857.87.0.169407991036.issue18802@psf.upfronthosting.co.za>


New submission from Jon Foster:

I recently looked at using the ipaddress module in a project, and noticed some discrepencies between the code and the documentation, and some things that weren't documented.  A patch to fix these is attached.

* The IPv4Network.__init__ documentation wrongly claims that "/0.0.0.0"
  would be interpreted as a host mask i.e. "/32".  It's actually
  interpreted as a net mask, i.e. "/0".

* The IPv[46]Network.netmask property is not documented

* The IPv[46]Network.hostmask property is wrongly called "host mask"
  (with a space!) in the docs

* The IPv[46]Network.hostmask property is wrongly documented as a
  string but it's actually an IPv[46]Address

* The IPv6Network.__init__ documentation wrongly claims that a netmask
  can be specified, but this is not supported by the code.  The code
  only supports prefix lengths.

* The documentation should explain how network objects are ordered,
  since it's not obvious.

* The documentation should explain how interface objects are compared,
  both with other interface objects and with address objects, as it's
  not obvious.

* It's probably a good idea to document that you can't always pass a
  IPv4Interface object to a function that expects a IPv4Address.

* It would be nice to mention that address, network and interface objects
  are all hashable.

Kind regards,

Jon

----------
components: Library (Lib)
files: ipaddress_docs_v1.patch
keywords: patch
messages: 195822
nosy: jongfoster
priority: normal
severity: normal
status: open
title: ipaddress documentation errors
versions: Python 3.4
Added file: http://bugs.python.org/file31410/ipaddress_docs_v1.patch

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

From report at bugs.python.org  Wed Aug 21 23:16:04 2013
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Wed, 21 Aug 2013 21:16:04 +0000
Subject: [New-bugs-announce] [issue18803] Fix more typos in .py files
Message-ID: <1377119764.79.0.128935070292.issue18803@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

Just like issue 18741 and 18705.

It also fixes one typo in a C file.

----------
assignee: docs at python
components: Documentation
files: more_typos.diff
keywords: patch
messages: 195823
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Fix more typos in .py files
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31411/more_typos.diff

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

From report at bugs.python.org  Thu Aug 22 01:07:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Aug 2013 23:07:47 +0000
Subject: [New-bugs-announce] [issue18804] pythorun.c: is_valid_fd() should
	not duplicate the file	descriptor
Message-ID: <1377126467.82.0.012503473328.issue18804@psf.upfronthosting.co.za>


New submission from STINNER Victor:

is_valid_fd() of Python/pythorun.c should use fstat() to check if a file descriptor is valid, instead of duplicating it using dup() (and then closing it).

If Windows needs a special check, it would be better to run checks on the handle of the file descriptor.

The function was added by the following changeset:

----------------------------
branch:      3.2
parent:      73773:661fb211f220
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Mon Nov 28 19:08:36 2011 +0100
files:       Lib/test/test_cmd_line.py Misc/NEWS Python/pythonrun.c
description:
Issue #7111: Python can now be run without a stdin, stdout or stderr stream.

It was already the case with Python 2.  However, the corresponding
sys module entries are now set to None (instead of an unusable file object).
----------------------------


See also issue #17797 "Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program".

----------
messages: 195836
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: pythorun.c: is_valid_fd() should not duplicate the file descriptor
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 22 02:38:38 2013
From: report at bugs.python.org (Jon Foster)
Date: Thu, 22 Aug 2013 00:38:38 +0000
Subject: [New-bugs-announce] [issue18805] ipaddress netmask/hostmask parsing
	bugs
Message-ID: <1377131918.88.0.806374780855.issue18805@psf.upfronthosting.co.za>


New submission from Jon Foster:

Short version:
Validation of netmasks and hostmasks in IPv4Network is wrong: it rejects many
valid netmasks, it accepts many invalid netmasks and hostmasks, and it sometimes
throws the wrong exception.  Patch attached.


Long version:


Wrongly rejecting hostmasks
---------------------------

Creating IPv4Network objects using a hostmask only works for 3 of the 31 possible hostmasks.
It works fine for /8, /16, and /24 networks, but anything else fails.  E.g. first let's
calculate the hostmask for a /21 network:

  >>> from ipaddress import IPv4Network
  >>> IPv4Network('0.0.0.0/21').hostmask
  IPv4Address('0.0.7.255')

Then try using it:
  >> IPv4Network('0.0.0.0/0.0.7.255')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "c:\Python33\lib\ipaddress.py", line 1443, in __init__
      % addr[1])
  ipaddress.NetmaskValueError: '0.0.7.255' is not a valid netmask

The problem is that there is a list of "_valid_mask_octets".  Although the values listed
are correct for netmasks, they are wrong for host masks.  In binary, a netmask has 1s
in the most significant <prefixlen> bits and 0s everywhere else; a hostmask has 0s
in the most significant <prefixlen> bits and 1s everywhere else.  So netmasks have
octet values 0b11111111, 0b11111110, 0b11111100, etc, whereas hostmasks have
octet values 0b11111111, 0b01111111, 0b00111111, etc.


Wrongly accepting hostmasks
---------------------------

Once the individual octets have been validated, the hostmask validation just checks
the first octet is less than the last octet.  This accepts values like "0.255.0.255",
which is not a valid hostmask.  The IPv4Network object then has wierd nonsensical
values.


Wrongly accepting netmasks
---------------------------

Once the individual octets have been validated, the netmask validation just checks
each octet is no greater than the one before.  This accepts values like "254.192.128.0",
which is not a valid netmask.  The IPv4Network object then has wierd nonsensical
values.


Inconsistent parsing
--------------------

The existing validation code includes its own parsing code.  If the netmask/hostmask
passes that vaildation, it then goes into _ip_int_from_string() to be parsed and
used.  _ip_int_from_string() checks things that aren't caught by the validation
code, leading to AddressValueError being thrown when NetmaskValueError was expected:

  >>> IPv4Network('1.2.0.0/0.0.0255.255')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "c:\Python33\lib\ipaddress.py", line 1440, in __init__
      self._ip_int_from_string(addr[1]) ^ self._ALL_ONES)
    File "c:\Python33\lib\ipaddress.py", line 1055, in _ip_int_from_string
      raise AddressValueError("%s in %r" % (exc, ip_str)) from None
  ipaddress.AddressValueError: At most 3 characters permitted in '0255' in '0.0.0255.255'

The correct fix for this one is obviously to use the same parser in all the places
we parse the netmask/hostmask.


The patch
---------

I'm attaching a patch, with tests, that fixes these issues.  Reusing the existing
_ip_int_from_string() function to parse the netmask/hostmask simplified the
validation code a lot.

My hope is that this patch is suitable for a backport to 3.3, as well as trunk.

----------
components: Library (Lib)
files: ipaddress_masks_v1.patch
keywords: patch
messages: 195846
nosy: jongfoster, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: ipaddress netmask/hostmask parsing bugs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31415/ipaddress_masks_v1.patch

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

From report at bugs.python.org  Thu Aug 22 07:44:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 05:44:15 +0000
Subject: [New-bugs-announce] [issue18806] socketmodule: fix/improve
	setipaddr() numeric addresses	handling
Message-ID: <1377150255.36.0.551541174341.issue18806@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, setipaddr() has this code to special-case numeric IPv4 addresses and avoid a name resolution:

"""
    if (sscanf(name, "%d.%d.%d.%d%c", &d1, &d2, &d3, &d4, &ch) == 4 &&
        0 <= d1 && d1 <= 255 && 0 <= d2 && d2 <= 255 &&
        0 <= d3 && d3 <= 255 && 0 <= d4 && d4 <= 255) {
        struct sockaddr_in *sin;
        sin = (struct sockaddr_in *)addr_ret;
        sin->sin_addr.s_addr = htonl(
            ((long) d1 << 24) | ((long) d2 << 16) |
            ((long) d3 << 8) | ((long) d4 << 0));
        sin->sin_family = AF_INET;
#ifdef HAVE_SOCKADDR_SA_LEN
        sin->sin_len = sizeof(*sin);
#endif
        return 4;
    }
"""

- it's sub-optimal to hand-parse an IP address while we have inet_pton() and getaddrinfo()
- it doesn't work for IPv6 addresses
- it's also subject to integer overflow due to the scanf formatter

Wouldn't it be better getaddrinfo() with AI_NUMERICHOST instead?

----------
components: Library (Lib)
messages: 195859
nosy: loewis, neologix
priority: normal
severity: normal
status: open
title: socketmodule: fix/improve setipaddr() numeric addresses handling
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 22 15:03:46 2013
From: report at bugs.python.org (Andrea Corbellini)
Date: Thu, 22 Aug 2013 13:03:46 +0000
Subject: [New-bugs-announce] [issue18807] Allow venv to create copies,
	even when symlinks are supported
Message-ID: <1377176626.74.0.056181108419.issue18807@psf.upfronthosting.co.za>


New submission from Andrea Corbellini:

I'd really appreciate if `venv` could create environments without symlinks.

Working on many Python projects, each one with different requirements, I prefer to keep everything I need in a single virtualenv directory, rather than two (one for the virtualenv and one for the built Python).

So I'd like to have a --copies option that lets me force venv not to create symlinks. I can work on a patch if this issue is accepted.

----------
components: Library (Lib)
messages: 195883
nosy: candrea
priority: normal
severity: normal
status: open
title: Allow venv to create copies, even when symlinks are supported
versions: Python 3.5

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

From report at bugs.python.org  Thu Aug 22 15:56:37 2013
From: report at bugs.python.org (Tamas K)
Date: Thu, 22 Aug 2013 13:56:37 +0000
Subject: [New-bugs-announce] [issue18808] Thread.join returns before
	PyThreadState is destroyed
Message-ID: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>


New submission from Tamas K:

When a thread is started in CPython, t_bootstrap [Modules/threadmodule.c] creates a PyThreadState object and then calls Thread.__bootstrap_inner [Lib/threading.py] which calls Thread.run, protected with self.__block, a Condition. Thread.join uses the same __block to block until Thread.run finished.

When Thread.run finished, __bootstrap_inner notifies on __block, so join will return. Here lies a race condition, if a thread switch to Thread.join occures before __bootstrap_inner returns to t_bootstrap. Then join will return before the PyThreadState for the thread is destroyed by t_bootstrap.

It is mostly harmless for general use, as __bootstrap_inner eventually gets scheduled again and PyThreadState is taken care of.

However. Py_EndInterpreter [Python/pythonrun.c] can be called when only the main interpreter thread is running. So when we want to call Py_EndInterpreter, we signal every other thread to stop, and join them. And when Thread.join returns, we call Py_EndInterpreter. Py_EndInterpreter checks if there are any other PyThreadStates still around and does a Py_FatalError.

As a workaround, we now do a sleep after join.

----------
components: Interpreter Core, Library (Lib)
messages: 195891
nosy: Tamas.K
priority: normal
severity: normal
status: open
title: Thread.join returns before PyThreadState is destroyed
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Aug 22 16:42:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Aug 2013 14:42:33 +0000
Subject: [New-bugs-announce] [issue18809] Expose mtime check in
	importlib.machinery.FileFinder
Message-ID: <1377182553.5.0.719157877901.issue18809@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If you have enough control over your environment you really don't need to waste a stat call checking if the directory has been modified. That makes the idea of having the check of whether the directory has changed be exposed publicly a useful idea (code: http://hg.python.org/cpython/file/caf72b44240b/Lib/importlib/_bootstrap.py#l1387).

Maybe a check_mtime(old_mtime) where we guarantee that old_mtime is negative if this is the first check? That way the _path_mtime stays private but the check itself is exposed for people to do things like
``return 0`` so that the cache is built once on first use of find_loader() but otherwise never re-calculated.

----------
components: Library (Lib)
messages: 195898
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Expose mtime check in importlib.machinery.FileFinder
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 22 16:49:46 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 22 Aug 2013 14:49:46 +0000
Subject: [New-bugs-announce] [issue18810] Stop doing stat calls in
	importlib.machinery.FileFinder	to see if something is a file
	or folder
Message-ID: <1377182986.55.0.892405433608.issue18810@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If the check was done based on simply the format what was being searched for (e.g. just assume it's a file if "module.py" exists in the directory) then a couple of stat calls per search could be saved.

If that is deemed to dangerous due to backwards-compatibility, at least extract an API so people can skip the stat calls if they know they are not going to do something as silly as have something named module.py that is not a file.

----------
components: Library (Lib)
messages: 195900
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Stop doing stat calls in importlib.machinery.FileFinder to see if something is a file or folder
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 22 19:04:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Aug 2013 17:04:00 +0000
Subject: [New-bugs-announce] [issue18811] add ssl-based generator to random
	module
Message-ID: <1377191040.61.0.301981053683.issue18811@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Now that the ssl module exposes RAND_bytes() (issue #12049), it might be interesting to implement a SSLRandom generator to the random module, to have a cryptographically strong generator without the os.urandom() overhead.

Thoughts?

----------
messages: 195912
nosy: christian.heimes, haypo, neologix, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: add ssl-based generator to random module
type: enhancement

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

From report at bugs.python.org  Thu Aug 22 21:00:11 2013
From: report at bugs.python.org (Rob Bairos)
Date: Thu, 22 Aug 2013 19:00:11 +0000
Subject: [New-bugs-announce] [issue18812] PyImport_Import redundant calls to
	find module
Message-ID: <1377198011.48.0.462132559828.issue18812@psf.upfronthosting.co.za>


New submission from Rob Bairos:

Why does PyImport_Import (import.c) call __import__ then immediately discard the result, and then look for the module again in the module dictionary?  

It will return the same value in both cases no?

Ive included the relevant portion of the code below.
Its breaking an embedded application we've built where a hierarchy of modules are maintained outside the sys.modules dictionary.


 /* Call the __import__ function with the proper argument list
    Always use absolute import here.
    Calling for side-effect of import. */
 r = PyObject_CallFunction(import, "OOOOi", module_name, globals,
                           globals, silly_list, 0, NULL);
 if (r == NULL)
     goto err;

//-------------------------- WHY IS THIS SECTION NEEDED? --------
 Py_DECREF(r);
 modules = PyImport_GetModuleDict();
 r = PyDict_GetItem(modules, module_name);
 if (r != NULL)
//---------------------------------------------------------------
     Py_INCREF(r);

----------
components: Interpreter Core
messages: 195915
nosy: Rob.Bairos
priority: normal
severity: normal
status: open
title: PyImport_Import redundant calls to find module
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug 22 22:52:52 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 22 Aug 2013 20:52:52 +0000
Subject: [New-bugs-announce] [issue18813] Speed up slice object processing
Message-ID: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The get/set/delitem slicing protocol has replaced the old Py2.x get/set/delslice protocol in Py3.x. This change introduces a substantial overhead due to processing indices as Python objects rather than plain Py_ssize_t values. This overhead should be reduced as much as possible.

This ticket can be seen as a more general follow-up to issue10227.

----------
components: Interpreter Core
messages: 195918
nosy: pitrou, scoder
priority: normal
severity: normal
status: open
title: Speed up slice object processing
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 23 06:02:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 23 Aug 2013 04:02:32 +0000
Subject: [New-bugs-announce] [issue18814] Add tools for "cleaning" surrogate
	escaped strings
Message-ID: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Prompted by issue 18713 and http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/, here are some possible utilities we could add to the codecs module to help deal with/debug issues related to surrogate escaped strings:

    def has_escaped_bytes(s):
        """Returns true if string contains surrogate escaped bytes"""
        ...

    def replace_escaped_bytes(s):
        """Replaces each surrogate escaped byte with a valid code point"""
        ...

    def decode_escaped_bytes(s, nominal_encoding, actual_encoding):
        """Reinterprets incorrectly decoded text using a new encoding"""
        return s.encode(nominal_encoding, 'surrogateescape').decode(actual_encoding)

----------
messages: 195937
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add tools for "cleaning" surrogate escaped strings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 23 06:20:01 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Aug 2013 04:20:01 +0000
Subject: [New-bugs-announce] [issue18815] DOCUMENTATION: "mmap .close()"
	doesn't close the	underlying file
Message-ID: <1377231601.59.0.456805422296.issue18815@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

In documentation http://docs.python.org/3.3/library/mmap.html#mmap.close you can read: "Close the file". I could interpret that it is going to close the file vinculated to the MMAP. But it doesn't. It only close the MMAP object (as it should).

Please, update doc to clear possible misunderstandings. Thanks.

----------
assignee: docs at python
keywords: easy
messages: 195939
nosy: docs at python, jcea
priority: normal
severity: normal
status: open
title: DOCUMENTATION: "mmap .close()" doesn't close the underlying file

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

From report at bugs.python.org  Fri Aug 23 06:55:08 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 23 Aug 2013 04:55:08 +0000
Subject: [New-bugs-announce] [issue18816] "mmap.flush()" is always
	synchronous, hurting performance
Message-ID: <1377233708.52.0.141761715851.issue18816@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Currently, "mmap.flush()" does a synchronous write to the backend file. The call will wait until data is actually flushed to disk, because internally it is doing a "msync(MS_SYNC)".

But the value of "mmap.flush()" is to synchronize file and memory. You don't need a synchronous write in the general case.

I propose to add an optional keyword parameter with default value "SYNC" (compatibility) but that can be "ASYNC", "INVALIDATE" (can be "SYNC|INVALIDATE" and "ASYNC|INVALIDATE" too).

I am talking about UNIX MMAP. No idea about Windows.

Check "man msync" for useful cases.

----------
components: Extension Modules
keywords: easy
messages: 195941
nosy: jcea
priority: normal
severity: normal
status: open
title: "mmap.flush()" is always synchronous, hurting performance
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 23 07:13:15 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 23 Aug 2013 05:13:15 +0000
Subject: [New-bugs-announce] [issue18817] Got resource warning when running
	Lib/aifc.py
Message-ID: <1377234795.91.0.783821607183.issue18817@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

The python is compiled with debug option.

<omitted>cpython$ ./python Lib/aifc.py Lib/test/sndhdrdata/sndhdr.aiff 
Reading Lib/test/sndhdrdata/sndhdr.aiff
nchannels = 2
nframes   = 5
sampwidth = 2
framerate = 44100
comptype  = b'NONE'
compname  = b'not compressed'
sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='Lib/test/sndhdrdata/sndhdr.aiff'>

Attached the patch to close the file automatically and print "Done." message not just with writing mode but for reading mode as well.

----------
components: Library (Lib)
files: fix_resource_warning_aifc.patch
keywords: patch
messages: 195943
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got resource warning when running Lib/aifc.py
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31430/fix_resource_warning_aifc.patch

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

From report at bugs.python.org  Fri Aug 23 08:45:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Aug 2013 06:45:48 +0000
Subject: [New-bugs-announce] [issue18818] Empty PYTHONIOENCODING is not the
	same as nonexistent
Message-ID: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ PYTHONIOENCODING= ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Aborted (core dumped)

As a consequence we can't set only the error handler.

$ PYTHONIOENCODING=:surrogateescape ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Aborted (core dumped)

Here is a patch which allows accepting empty encoding as default encoding.

----------
components: Interpreter Core
files: empty_pythonioencoding.patch
keywords: patch
messages: 195946
nosy: haypo, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Empty PYTHONIOENCODING is not the same as nonexistent
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31432/empty_pythonioencoding.patch

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

From report at bugs.python.org  Fri Aug 23 09:56:10 2013
From: report at bugs.python.org (Nuutti Kotivuori)
Date: Fri, 23 Aug 2013 07:56:10 +0000
Subject: [New-bugs-announce] [issue18819] tarfile fills devmajor and
	devminor fields even for	non-devices
Message-ID: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>


New submission from Nuutti Kotivuori:

when tarfile generates a tar, it uses TarInfo objects which are packed to the binary format. This packing uses "itn" format for filling the "devmajor" and "devminor" fields of the tar file entry, with a default value of zero. The field length is 8 characters, and the formatting will format the values as octal strings, followed by a NUL byte, eg. '0000000\x00'.

However, other common tar tools do not exhibit this behavior, instead leaving the field filled with NUL bytes in case the earlier type field does not indicate a device type. Explicitly, the value generated by other tools is then '\x00\x00\x00\x00\x00\x00\x00\x00'.

This causes no interoperability issues (that I am aware of), but makes it hard to attempt to replicate the tar files generated by other tools exactly.

I am attaching a simple diff fixing this, but there are probably better ways to fix this.

----------
components: Library (Lib)
files: tarfile.py.diff
keywords: patch
messages: 195949
nosy: Nuutti.Kotivuori
priority: normal
severity: normal
status: open
title: tarfile fills devmajor and devminor fields even for non-devices
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31434/tarfile.py.diff

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

From report at bugs.python.org  Fri Aug 23 12:30:30 2013
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 23 Aug 2013 10:30:30 +0000
Subject: [New-bugs-announce] [issue18820] json.dump() ignores its 'default'
	option when	serializing dictionary keys
Message-ID: <1377253830.03.0.463497944995.issue18820@psf.upfronthosting.co.za>


New submission from July Tikhonov:

According to documentation of json.dump(), concerning its 'default' option:

default(obj) is a function that should return a serializable version of obj or raise TypeError. The default simply raises TypeError.

But this function is actually never applied to serialized dictionary keys:

>>> def default(obj):
...  if isinstance(obj, bytes):
...   return obj.decode('ascii')
...  raise ValueError
... 
>>> json.dumps(b'asdf')
Traceback (most recent call last):
...
TypeError: b'asdf' is not JSON serializable
>>> json.dumps(b'asdf', default=default)
'"asdf"'
>>> json.dumps({b'asdf' : 1}, default=default)
Traceback (most recent call last):
...
TypeError: keys must be a string
>>> json.dumps({1 : b'asdf'}, default=default)
'{"1": "asdf"}'

(bytes are used purely for the purpose of example)
Such behavior should be either documented or corrected.
Patch correcting python implementation of json attached.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: json-default-dict-keys.diff
keywords: patch
messages: 195957
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: json.dump() ignores its 'default' option when serializing dictionary keys
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31436/json-default-dict-keys.diff

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

From report at bugs.python.org  Fri Aug 23 14:19:54 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Fri, 23 Aug 2013 12:19:54 +0000
Subject: [New-bugs-announce] [issue18821] Add .lastitem attribute to
	takewhile instances
Message-ID: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

I've often wanted to be able to query a takewhile object to discover the item that failed the predicate but the item is currently discarded.

A usage example:

def sum(items):
    it = iter(items)
    ints = takewhile(Integral.__instancecheck__, it)
    subtotal = sum(ints)
    if not hasattr(ints.lastitem):
        return subtotal
    floats = takewhile(float.__instancecheck__, it)
    subtotalf = fsum(floats)
    if not hasattr(floats.lastitem):
        return subtotal + subtotalf
    # Deal with more types
    ...


Loosely what I'm thinking is this but perhaps with different attribute names:


class takewhile(pred, iterable):
    def __init__(self):
        self.pred = pred
        self.iterable = iterable
        self.failed = False
    def __iter__(self):
        for item in self.iterable:
            if self.pred(item):
                yield item
            else:
                self.failed = True
                self.lastitem = item
                return

----------
components: Library (Lib)
messages: 195962
nosy: oscarbenjamin
priority: normal
severity: normal
status: open
title: Add .lastitem attribute to takewhile instances
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 23 20:29:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Aug 2013 18:29:59 +0000
Subject: [New-bugs-announce] [issue18822] poor proxyval() coverage in
	test_gdb
Message-ID: <1377282599.12.0.212974297013.issue18822@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The proxyval() of many built-in types doesn't seem covered by test_gdb, as write_repr() is specialized for most of them.

(check: add "1/0" to one of those proxyval() implementations and watch test_gdb succeed)

----------
components: Tests
messages: 195998
nosy: dmalcolm, pitrou
priority: normal
severity: normal
status: open
title: poor proxyval() coverage in test_gdb
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 24 01:35:04 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Aug 2013 23:35:04 +0000
Subject: [New-bugs-announce] [issue18823] Idle: use pipes instead of sockets
	to talk with user	subprocess
Message-ID: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Idle once used os.spawnv to open the user subprocess and 2.7 still does. Sockets were then used to interact with the subprocess. Since rev71746, 2011-8-3, 3.2+ use subprocess.Popen but still use sockets. A rare but continual problem is failure to make the socket connection.

In #16123, Amaury Forgeot d'Arc suggested "pipes?" The idea resurfaced again in current Idle-sig thread "Idle does not open on mac" (because socket connection timed out). Guido, who designed the current 2.x system, chimed in with "I would recommend trying to use the subprocess module."

A current python-list thread indicates that there can be problems with
"Running a command line program and reading the result as it runs"
http://mail.python.org/pipermail/python-list/2013-August/654265.html

In particular, "for line in p:" gets lines delayed (buffered) while
Peter Otten discovered that "for line in iter(p.stdout.readline, ''):" gets them as they are produced.
http://mail.python.org/pipermail/python-list/2013-August/654330.html

We first need to experiment running a simple echo server with python(w).exe.  I have not succeeded yet on Windows.

----------
components: IDLE
messages: 196055
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Idle: use pipes instead of sockets to talk with user subprocess
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 24 13:16:56 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 24 Aug 2013 11:16:56 +0000
Subject: [New-bugs-announce] [issue18824] Adding LogRecord attribute
	"traceback"
Message-ID: <1377343016.83.0.299071692967.issue18824@psf.upfronthosting.co.za>


New submission from Sworddragon:

On configuring a logger with logging.basicConfig() and using logging.exception() the traceback is always written implicitly to the end. This makes it not possible to create a formation that writes something beyond the traceback. For example it could be something like that: logging.basicConfig(filename = '/tmp/python.log', format = '%(asctime)s\n%(traceback)s\nSome_text_or_LogRecords_after_the_traceback', datefmt = '%Y-%m-%d %H:%M:%S')

----------
components: Library (Lib)
messages: 196072
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Adding LogRecord attribute "traceback"
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 24 13:33:10 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 24 Aug 2013 11:33:10 +0000
Subject: [New-bugs-announce] [issue18825] Making msg optional on
	logging.exception() and similar	variants
Message-ID: <1377343990.79.0.586156704832.issue18825@psf.upfronthosting.co.za>


New submission from Sworddragon:

For logging.exception() and similar variants the msg argument must be passed but on a formation the LogRecord "message" is not mandatory. In this case wouldn't it be better to make the msg argument optional? At default it could be None or ''.

----------
components: Library (Lib)
messages: 196073
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Making msg optional on logging.exception() and similar variants
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 24 21:08:22 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 24 Aug 2013 19:08:22 +0000
Subject: [New-bugs-announce] [issue18826] reversed() requires a sequence -
	Could work on any	iterator?
Message-ID: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>


New submission from Donald Stufft:

I noticed today that the builtin reversed() requires an explicit sequence and won't work with an iterator instead it throws a TypeError like:

>>> reversed(x for x in [1, 2, 3])
TypeError: argument to reversed() must be a sequence

It would be really great if reversed() worked on iterators too. Currently it requires an explicit list() before you can sent it back into reversed() which seems like it hurts readability.

For what it's worth I discovered this when trying to reverse the output of itertools.dropwhile.

----------
messages: 196090
nosy: dstufft
priority: normal
severity: normal
status: open
title: reversed() requires a sequence - Could work on any iterator?

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

From report at bugs.python.org  Sun Aug 25 00:05:21 2013
From: report at bugs.python.org (Alexander Schier)
Date: Sat, 24 Aug 2013 22:05:21 +0000
Subject: [New-bugs-announce] [issue18827] mistake in the
	timedelta.total_seconds docstring
Message-ID: <1377381921.16.0.995171026465.issue18827@psf.upfronthosting.co.za>


New submission from Alexander Schier:

> Return the total number of seconds contained in the duration. Equivalent to (td.microseconds + (td.seconds + td.days * 24 * 3600) * 10**6) / 10**6 computed with true division enabled.

Should be
> Return the total number of seconds contained in the duration. Equivalent to (td.microseconds / 10**6 + (td.seconds + td.days * 24 * 3600) * 10**6) computed with true division enabled.

At least i hope, the bug is only in the docs and not in the function ;).

----------
assignee: docs at python
components: Documentation
messages: 196100
nosy: allo, docs at python
priority: normal
severity: normal
status: open
title: mistake in the timedelta.total_seconds docstring
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 25 14:52:00 2013
From: report at bugs.python.org (Mher Movsisyan)
Date: Sun, 25 Aug 2013 12:52:00 +0000
Subject: [New-bugs-announce] [issue18828] urljoin behaves differently with
	custom and standard	schemas
Message-ID: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>


New submission from Mher Movsisyan:

>>> urljoin('redis://localhost:6379/0', '/1')
'/1'
>>> urljoin('http://localhost:6379/0', '/1')
'http://localhost:6379/1'

----------
messages: 196125
nosy: mher.movsisyan
priority: normal
severity: normal
status: open
title: urljoin behaves differently with custom and standard schemas
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Aug 25 14:56:23 2013
From: report at bugs.python.org (Thibault Kruse)
Date: Sun, 25 Aug 2013 12:56:23 +0000
Subject: [New-bugs-announce] [issue18829] csv produces confusing error
	message for unexpected	string encoding
Message-ID: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>


New submission from Thibault Kruse:

To reproduce

$ python --version
Python 2.7.3
$ python -c 'from __future__ import unicode_literals; import csv; reader = csv.reader("foo", delimiter=",")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: "delimiter" must be an 1-character string

This is confusing because "," is like a 1-character (unicode) string, while csv requires a 1-character (byte) string. In python3, it's the inverse problem, using bytestring b','

$ python3 --version
Python 3.2.3
$ python3 -c 'import csv; reader = csv.reader("foo", delimiter=b",")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: "delimiter" must be an 1-character string


So I believe csv should state more clearly what went wrong here in each case, or what kind of string csv is willing to accept in the respective python version.

Whether the python3 refusal to use a bytestring is even reasonable I don't know.

This might or might not be related to the issue of multichar delimiters: http://bugs.python.org/issue15158  (just sayin)

----------
components: Library (Lib)
messages: 196126
nosy: Thibault.Kruse
priority: normal
severity: normal
status: open
title: csv produces confusing error message for unexpected string encoding
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Aug 25 16:50:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Aug 2013 14:50:13 +0000
Subject: [New-bugs-announce] [issue18830] Remove duplicates from a result of
	getclasstree()
Message-ID: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

inspect.getclasstree() produces duplicated entities when it's argument contains duplicated classes. This happened when a module contains class aliases. For example `pydoc zipfile` outputs three entities for BadZipFile (BadZipfile and error are aliases of BadZipFile):

CLASSES
    builtins.Exception(builtins.BaseException)
        BadZipFile
        BadZipFile
        BadZipFile
        LargeZipFile
    builtins.object
        ZipFile
            PyZipFile
        ZipInfo
    
The proposed patch removes duplicates from a result of getclasstree().

----------
components: Library (Lib)
files: getclasstree_no_dups.patch
keywords: patch
messages: 196138
nosy: eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove duplicates from a result of getclasstree()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31461/getclasstree_no_dups.patch

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

From report at bugs.python.org  Sun Aug 25 17:16:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Aug 2013 15:16:41 +0000
Subject: [New-bugs-announce] [issue18831] importlib.import_module() bypasses
	builtins.__import__
Message-ID: <1377443801.78.0.926402532335.issue18831@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Not sure if anyone really cares about this (I don't, but I figured I should at least let it be known), but I realized that importlib.import_module() bypasses builtins.__import__ by calling directly into the innards of importlib (specifically _gcd_import() which skips all the extra setup that __import__ entails and which is unnecessary for programmatic imports).

The docs for importlib.import_module() clearly state it uses importlib.__import__, but I'm not sure if anyone would be surprised if they replaced builtins.__import__ and found that importlib.import_module() was doing an end-run around their custom import system, especially since we are promoting importlib.import_module() over calling builtins.__import__ directly.

----------
components: Library (Lib)
messages: 196144
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: importlib.import_module() bypasses builtins.__import__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug 25 19:26:23 2013
From: report at bugs.python.org (Tal Weiss)
Date: Sun, 25 Aug 2013 17:26:23 +0000
Subject: [New-bugs-announce] [issue18832] New regex module degrades re
	performance
Message-ID: <1377451583.44.0.0818025300658.issue18832@psf.upfronthosting.co.za>


New submission from Tal Weiss:

All tests I ran comparing timing of the new regex module relative to the old re module showed significant slower performance.
I'm attaching test code with regular expressions from our production server.
Tested on Python 2.7, 64 bit Linux + 64 bit Windows 7.
regex #0 match success = 0.16530585289 seconds
re    #0 match success = 0.0977821350098 seconds
regex #0 match failure = 0.460994958878 seconds
re    #0 match failure = 0.249558925629 seconds
regex #1 match success = 0.0802597999573 seconds
re    #1 match success = 0.0348429679871 seconds
regex #1 match failure = 0.224385023117 seconds
re    #1 match failure = 0.104065895081 seconds
regex #2 match success = 0.0307199954987 seconds
re    #2 match success = 0.0200390815735 seconds
regex #2 match failure = 0.0253899097443 seconds
re    #2 match failure = 0.0161480903625 seconds

----------
components: Regular Expressions
files: play_regex.py
messages: 196153
nosy: Tal.Weiss, ezio.melotti, haypo, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: New regex module degrades re performance
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31464/play_regex.py

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

From report at bugs.python.org  Sun Aug 25 20:38:21 2013
From: report at bugs.python.org (Alex Volkov)
Date: Sun, 25 Aug 2013 18:38:21 +0000
Subject: [New-bugs-announce] [issue18833] Increased test coverage for
	telnetlib
Message-ID: <1377455901.74.0.558860424398.issue18833@psf.upfronthosting.co.za>


New submission from Alex Volkov:

This issue splits up an unrelated patch from issue 18731
http://bugs.python.org/issue18731

Added a test for telnetlib increasing test coverage.

Updated with the changes from code review of issue 18731
http://bugs.python.org/review/18731/patch/8923/33000

----------
components: Tests
files: test_telnetlib_getter.patch
keywords: patch
messages: 196158
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for telnetlib
versions: Python 3.4
Added file: http://bugs.python.org/file31466/test_telnetlib_getter.patch

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

From report at bugs.python.org  Sun Aug 25 21:33:46 2013
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sun, 25 Aug 2013 19:33:46 +0000
Subject: [New-bugs-announce] [issue18834] Add Clang to distutils to build
	C/C++ extensions
Message-ID: <1377459226.15.0.775642351727.issue18834@psf.upfronthosting.co.za>


New submission from Ryan Gonzalez:

A have created to patches(for ccompiler.py and cygwinccompiler.py) to add Clang as a compiler in distutils. The patches are here:

ccompiler.py: http://pastebin.com/yMGYys0P
cygwinccompiler.py: http://pastebin.com/a49qNP6n

I used the distutils version from Mercurial.

----------
assignee: eric.araujo
components: Distutils
messages: 196160
nosy: Ryan.Gonzalez, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Add Clang to distutils to build C/C++ extensions
type: enhancement

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

From report at bugs.python.org  Mon Aug 26 04:32:51 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 26 Aug 2013 02:32:51 +0000
Subject: [New-bugs-announce] [issue18835] Add aligned memroy variants to the
	suite of PyMem	functions/macros
Message-ID: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Currently, we have little to no control over the alignment of memory returned by the PyMem functions.   

I suggest variants such as PyMem_Alloc32(n) and PyMem_Alloc64(n) to return suitably aligned data blocks.

GNU C provides memalign() for this purpose:  http://www.delorie.com/gnu/docs/glibc/libc_31.html
and the Microsoft C compiler has _aligned_malloc() for the same purpose: http://msdn.microsoft.com/en-us/library/8z34s9c6%28VS.80%29.aspx

A principal use case would be PyObject pointers where we want to keep all or most of the data fields in the same cache line (i.e. the fields for list, tuple, dict, and set objects).

Deques would benefit from having the deque blocks aligned to 64byte boundaries and never crossing page boundaries.  Set entries would benefit from 32byte alignment.

----------
components: Interpreter Core
messages: 196174
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add aligned memroy variants to the suite of PyMem functions/macros
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 26 08:11:49 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 26 Aug 2013 06:11:49 +0000
Subject: [New-bugs-announce] [issue18836] Potential race condition in
	exceptions
Message-ID: <1377497509.71.0.034362539056.issue18836@psf.upfronthosting.co.za>


New submission from Sworddragon:

On a try/except-block if an exception raises (for example KeyboardInterrupt) the except block could cause another exception and if this block tries to catch it too the nested except block could cause another exception again. This goes into an unlimited recursion.

In the attachments is an example of such a problem (race_condition_fast.py). But as it is called a "race condition" it is nearly impossible to reproduce it by a human. For this case I have adjusted the example (race_condition_slow.py). The third CTRL + C will cause a KeyboardInterrupt.

----------
components: Interpreter Core
files: race_condition_fast.py
messages: 196181
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Potential race condition in exceptions
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31469/race_condition_fast.py

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

From report at bugs.python.org  Mon Aug 26 08:56:10 2013
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Mon, 26 Aug 2013 06:56:10 +0000
Subject: [New-bugs-announce] [issue18837] multiprocessing.reduction is
	undocumented
Message-ID: <1377500170.46.0.281746133519.issue18837@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

In older versions (2.x, 3.2, 3.3) multiprocessing.reduction was only mentioned in a one example, with a one comment after it. In the 3.4dev documentation even this was dropped.

----------
assignee: docs at python
components: Documentation
messages: 196184
nosy: docs at python, tpievila
priority: normal
severity: normal
status: open
title: multiprocessing.reduction is undocumented
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 26 11:05:07 2013
From: report at bugs.python.org (Drekin)
Date: Mon, 26 Aug 2013 09:05:07 +0000
Subject: [New-bugs-announce] [issue18838] The order of interactive prompt
	and traceback on Windows
Message-ID: <1377507907.91.0.430796932988.issue18838@psf.upfronthosting.co.za>


New submission from Drekin:

On Windows, Python 3.3.2, when I run Python as a subprocess via Popen("py -i somescript.py", stdin=PIPE, stdout=PIPE, stderr=PIPE).communicate() and somescript.py ends with exception, there is first interactive promt ">>>" in stderr output and then the traceback which is reversed to standard order when somescript.py is run interactively directly.

Corresponding StackOverflow question: http://stackoverflow.com/questions/18419724/position-of-prompt-in-stderr-after-systemexit .

----------
components: Windows
messages: 196192
nosy: Drekin
priority: normal
severity: normal
status: open
title: The order of interactive prompt and traceback on Windows
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug 26 12:51:32 2013
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 26 Aug 2013 10:51:32 +0000
Subject: [New-bugs-announce] [issue18839] Wrong sentence in sys.exit.__doc__
Message-ID: <1377514292.79.0.0321965724475.issue18839@psf.upfronthosting.co.za>


New submission from Marco Buttu:

Python 3.3::

    >>> import sys
    >>> print(sys.exit.__doc__)
    exit([status])

    Exit the interpreter by raising SystemExit(status).
    If the status is omitted or None, it defaults to zero (i.e., success).
    If the status is numeric, it will be used as the system exit status.
    If it is another kind of object, it will be printed and the system
    exit status will be one (i.e., failure).

The sentence "If the status is numeric, it will be used as the system exit status."
is wrong::

    >>> sys.exit(3.33)
    3.33
    $ echo $?
    1


It should be "If the status is an *integer*, it will be used as the system exit status.",
as specified in the SystemExit `doc`.

.. doc: http://docs.python.org/3/library/exceptions.html#SystemExit

----------
assignee: docs at python
components: Documentation
messages: 196195
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Wrong sentence in sys.exit.__doc__
type: behavior

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

From report at bugs.python.org  Mon Aug 26 14:37:58 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 26 Aug 2013 12:37:58 +0000
Subject: [New-bugs-announce] [issue18840] Tutorial recommends pickle module
	without any warning of	insecurity
Message-ID: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>


New submission from Donald Stufft:

The Python tutorial tells, and even recommends, new users that they can use the pickle module to serialize arbitrary objects. However it does not provide any warning about the insecurity of unpickling arbtirary data. The text even goes so far as to mention sending pickled data over a network connection to other machines.

I believe this section should be replaced with using the json module instead of pickle. It is more standard and doesn't present the same security concerns with untrusted data as pickle does. However if it continues to recommend pickle to new users it should at least warn them of the dangers of using pickle.

The section in question is located at http://docs.python.org/3/tutorial/inputoutput.html#the-pickle-module

----------
assignee: docs at python
components: Documentation
messages: 196203
nosy: docs at python, dstufft
priority: normal
severity: normal
status: open
title: Tutorial recommends pickle module without any warning of insecurity

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

From report at bugs.python.org  Mon Aug 26 17:38:40 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Aug 2013 15:38:40 +0000
Subject: [New-bugs-announce] [issue18841] math.isfinite fails with Decimal
	sNAN
Message-ID: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

math.isfinite currently raises ValueError when given a Decimal sNAN (signalling NAN).

I've run into a situation where I'm calling isfinite() on a numeric value which may be a Decimal sNAN, and it would be nice if it returned False.

On the other hand, see the discussion on issue 15544, which possibly leads to the conclusion that raising ValueError is the right thing to do.

http://bugs.python.org/issue15544

Either way, behaviour should be documented.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 196213
nosy: docs at python, stevenjd
priority: normal
severity: normal
status: open
title: math.isfinite fails with Decimal sNAN
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 26 17:59:17 2013
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 26 Aug 2013 15:59:17 +0000
Subject: [New-bugs-announce] [issue18842] Add float.is_finite is_nan
	is_infinite to match Decimal	methods
Message-ID: <1377532757.24.0.123652540945.issue18842@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

On issue 15544 Mark Dickinson suggested adding methods to float to match methods on Decimal, giving type-agnostic ways of testing real numbers that don't rely on converting to float. I don't see any sign that Mark raised a feature request, so I'm taking the liberty of doing so myself.

Note that the math.is* functions convert to float first, which means that they behave differently. Example: math.isnan(Decimal('sNAN')) raises ValueError, rather than returning True.

float.is_nan
float.is_infinity
float.is_finite

would mirror the spelling of Decimal methods, rather than the math module. As float doesn't support signalling NANs, there probably isn't any need to include is_snan and is_qnan.

For what it's worth, I have code that would use this. I currently write something like:

if isinstance(x, Decimal) and x.is_nan() or math.isnan(x): ...

in order to prevent triggering the ValueError on signalling NANs.

----------
messages: 196219
nosy: stevenjd
priority: normal
severity: normal
status: open
title: Add float.is_finite is_nan is_infinite to match Decimal methods
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 26 18:28:31 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 16:28:31 +0000
Subject: [New-bugs-announce] [issue18843] Py_FatalError (msg=0x7f0e3b373232
	"bad leading pad	byte") at Python-2.7.5/Python/pythonrun.c:1689
Message-ID: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Hi,
  it happened to me that using faulthandler and python compiled with --with-pydebug and C*FLAGS=-ggdb I got this stacktrace (will attach longer version as a file):


(gdb) where
#0  0x00007f0e3af8aacb in raise () from /lib64/libpthread.so.0
#1  0x00007f0e3a0b05f6 in faulthandler_fatal_error (signum=6) at faulthandler.c:321
#2  <signal handler called>
#3  0x00007f0e3ac061f5 in raise () from /lib64/libc.so.6
#4  0x00007f0e3ac0766b in abort () from /lib64/libc.so.6
#5  0x00007f0e3b327828 in Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/pythonrun.c:1689
#6  0x00007f0e3b257dc8 in _PyObject_DebugCheckAddressApi (api=111 'o', p=0x449e6900) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1591
#7  0x00007f0e3b257a6c in _PyObject_DebugFreeApi (api=111 'o', p=0x449e6900) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1478
#8  0x00007f0e3b257913 in _PyObject_DebugFree (p=0x449e6900) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/obmalloc.c:1422
#9  0x00007f0e3b34319a in PyObject_GC_Del (op=0x449e6920) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/gcmodule.c:1561
#10 0x00007f0e3b275ef7 in tupledealloc (op=0x449e6920) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/tupleobject.c:235
#11 0x00007f0e3b255bac in _Py_Dealloc (op=(True,)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#12 0x00007f0e3b246d77 in dict_dealloc (mp=0x449b5d80) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1010
#13 0x00007f0e3b255bac in _Py_Dealloc (op=
    {'_label': <unknown at remote 0x449dd4b8>, '_facecolors_original': (<float at remote 0xb65dd38>, <float at remote 0x5034630>, <float at remote 0xb3c6af8>), '_transform': <unknown at remote 0x449e6b50>, 'figure': <Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848704: <KeyedRef at remote 0x40290a80>, 405520480: <KeyedRef at remote 0x29e86b10>, 322803328: <KeyedRef at remote 0x29e86570>, 3585872752: <KeyedRef ...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#14 0x00007f0e3b27ad3d in subtype_dealloc (
    self=<PathCollection(_label=<unknown at remote 0x449dd4b8>, _facecolors_original=(<float at remote 0xb65dd38>, <float at remote 0x5034630>, <float at remote 0xb3c6af8>), _transform=<unknown at remote 0x449e6b50>, figure=<Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848704: <KeyedRef at remote 0x40290a80>, 405520480: <KeyedRef at remote 0x29e86b10>, 322803328: <KeyedRef at remote 0x29e86570>, 3585872752: <KeyedR...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/typeobject.c:1015
#15 0x00007f0e3b255bac in _Py_Dealloc (
    op=<PathCollection(_label=<unknown at remote 0x449dd4b8>, _facecolors_original=(<float at remote 0xb65dd38>, <float at remote 0x5034630>, <float at remote 0xb3c6af8>), _transform=<unknown at remote 0x449e6b50>, figure=<Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848704: <KeyedRef at remote 0x40290a80>, 405520480: <KeyedRef at remote 0x29e86b10>, 322803328: <KeyedRef at remote 0x29e86570>, 3585872752: <KeyedR...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#16 0x00007f0e3b230841 in list_dealloc (op=0x1d1740d8) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/listobject.c:309
#17 0x00007f0e3b255bac in _Py_Dealloc (
    op=[<PathCollection(_label='_collection0', _facecolors_original=(<float at remote 0x5034630>, <float at remote 0xc489d80>, <float at remote 0xc568ab8>), _transform=<IdentityTransform(_invalid=1, _inverted=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d840>, data={}) at remote 0x129fb510>) at remote 0x1201cd10>, figure=<Figure(_label='', _transform=None, figure=None, _axobservers=[], images=[], texts=[], _hold=True, artists=[], _agg_filter=None, patch=<Rectangle(_label='', _transform=<BboxTransformTo(_invalid=2, _inverted=<Affine2D(_invalid=0, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bc6ec0>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xbf7d060>, data={}) at remote 0x129fbdf8>) at remote 0xd5bb0300>, _boxout=<TransformedBbox(_invalid=2, _transform=<Affine2D(_invalid=2, _inverted=None, _mtx=<numpy.ndarray at remote 0xd5bad540>, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0xc166450>, data={741848...(truncated)) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/object.c:2262
#18 0x00007f0e3b245789 in insertdict_by_entry (mp=0x17e2a9c0, key='collections', hash=5674278088882554420, ep=0x103a7dc0, value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:519
#19 0x00007f0e3b245a5b in insertdict (mp=0x17e2a9c0, key='collections', hash=5674278088882554420, value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:556
#20 0x00007f0e3b246326 in dict_set_item_by_hash_or_entry (op=0x0, key='collections', hash=5674278088882554420, ep=0x0, value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:765
#21 0x00007f0e3b2464be in PyDict_SetItem (
    op={'transLimits': <BboxTransformFrom(_invalid=2, _boxin=<TransformedBbox(_invalid=2, _transform=<TransformWrapper(_invalid=0, transform_path_affine=<instancemethod at remote 0xbad73e0>, input_dims=2, transform_path=<instancemethod at remote 0x17f47d60>, transform=<instancemethod at remote 0xd511bee0>, transform_affine=<instancemethod at remote 0x1e0e0260>, inverted=<instancemethod at remote 0x17f47ce0>, _child=<BlendedAffine2D(_invalid=1, _y=<IdentityTransform(_invalid=1, _inverted=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0x10c92648>, data={315699008: <KeyedRef at remote 0xbd63a80>}) at remote 0x350f5df8>) at remote 0x2c360bc0>, _x=<IdentityTransform(_invalid=1, _inverted=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0x145ff990>, data={315699008: <KeyedRef at remote 0xbd63720>}) at remote 0xbfde2b8>) at remote 0x2c36c680>, _inverted=None, _mtx=None, _shorthand_name='', _parents=<WeakValueDictionary(_remove=<function at remote 0x10c...(truncated), key='collections', value=[]) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:818

It was drawing a chart using matplotlib-1.2.1. Is this a python or matplotlib bug? I shortened the gdb stacktrace hoping you don't need the rest.

----------
files: bad_leading_pad_byte_14028_shortened.txt
messages: 196222
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file31474/bad_leading_pad_byte_14028_shortened.txt

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

From report at bugs.python.org  Mon Aug 26 19:23:45 2013
From: report at bugs.python.org (Alan Isaac)
Date: Mon, 26 Aug 2013 17:23:45 +0000
Subject: [New-bugs-announce] [issue18844] allow weights in random.choice
Message-ID: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>


New submission from Alan Isaac:

The need for weighted random choices is so common that it is addressed as a "common task" in the docs:
http://docs.python.org/dev/library/random.html

This enhancement request is to add an optional argument to random.choice, which must be a sequence of non-negative numbers (the weights) having the same length as the main argument.

----------
messages: 196229
nosy: aisaac
priority: normal
severity: normal
status: open
title: allow weights in random.choice
type: enhancement

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

From report at bugs.python.org  Mon Aug 26 21:47:06 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Mon, 26 Aug 2013 19:47:06 +0000
Subject: [New-bugs-announce] [issue18845] 2.7.5-r2: Fatal Python error:
	Segmentation fault
Message-ID: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

While running my app testsuite I have another one which crashed.

Fatal Python error: Segmentation fault

Current thread 0x00007fe8d3527700:
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2370 in get_matrix
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2203 in get_affine
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 2175 in transform_affine
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 1238 in transform
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 1030 in get_points
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 277 in __array__
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 110 in draw_path_collection
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 259 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/collections.py", line 695 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1006 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54 in draw_wrapper
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 440 in draw
  File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 492 in print_png
  File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2096 in print_figure
  File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1370 in savefig

  I wanted to draw 55620 dots in a scatter plot, each with a legend and its associated color. Actually only 100 color are used and multiple adjacent dots in the series have same color as necessary.


Is this a matplotlib or a python error?

----------
files: matplotlib_crash_1676__SRR091640_shortened.txt
messages: 196239
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: 2.7.5-r2: Fatal Python error: Segmentation fault
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file31478/matplotlib_crash_1676__SRR091640_shortened.txt

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

From report at bugs.python.org  Tue Aug 27 03:34:25 2013
From: report at bugs.python.org (SSmith)
Date: Tue, 27 Aug 2013 01:34:25 +0000
Subject: [New-bugs-announce] [issue18846] python.exe stdout stderr issues
	again
Message-ID: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za>


New submission from SSmith:

python.exe sends its output to stderr instead of stdout.
Writing the following to the command line highlight the issue:
[ in]>python.exe --version 1> null   #redirects stdout to null
[out]>Python 2.7.5

[ in]>python.exe --version 2> null   #redirects stderr to null
[out]>

Python 3.3 has exactly the same issue.

Python 3.4alpha now, although it gives the correct output with the --version switch...:
[ in]>python --version 1> null
[out]>

[ in]>python --version 2> null
[out]>Python 3.4.0a1

...still invoking a simple pyton.exe  (switchless), prints its default output to stderr:
[ in]>python 1> null
[out]>Python 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug  3 2013, 22:59:31) [MSC v.1600 32 bit (Intel)] on win32
[out]>Type "help", "copyright", "credits" or "license" for more information.
[out]>>>


[ in]>python 2> null
[out]>>>

Some notes/refs:
Incomplete fix in 3.4a http://bugs.python.org/issue18338

----------
components: Interpreter Core
messages: 196257
nosy: SSmith
priority: normal
severity: normal
status: open
title: python.exe stdout stderr issues again
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug 27 08:24:52 2013
From: report at bugs.python.org (Bernie Keimel)
Date: Tue, 27 Aug 2013 06:24:52 +0000
Subject: [New-bugs-announce] [issue18847] Einladung in mein Netzwerk bei
	LinkedIn
Message-ID: <1817855663.697017.1377584689965.JavaMail.app@ela4-app4300.prod>


New submission from Bernie Keimel:

LinkedIn
------------

Ich m?chte Sie zu meinem beruflichen Netzwerk auf LinkedIn hinzuf?gen.

- Bernard Keimel

Bernard Keimel
Business bei privat
Berlin und Umgebung, Deutschland

Best?tigen Sie, dass Sie Bernard Keimel kennen:
https://www.linkedin.com/e/-3qcne3-hkuqctnf-28/isd/16078050493/NNc4mKPz/?hs=false&tok=2zVN7V8rC0lBU1

--
Sie erhalten Einladungen zum Netwerkbeitritt per E-Mail. Klicken Sie hier, wenn Sie kein Interesse daran haben:
http://www.linkedin.com/e/-3qcne3-hkuqctnf-28/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5347669664_1/?hs=false&tok=3HVMvi7QC0lBU1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043, USA

----------
messages: 196264
nosy: Bernie.Keimel
priority: normal
severity: normal
status: open
title: Einladung in mein Netzwerk bei LinkedIn

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

From report at bugs.python.org  Tue Aug 27 08:48:50 2013
From: report at bugs.python.org (py.user)
Date: Tue, 27 Aug 2013 06:48:50 +0000
Subject: [New-bugs-announce] [issue18848] In unittest.TestResult
	.startTestRun() and	.stopTestRun() methods don't work
Message-ID: <1377586130.68.0.700857287739.issue18848@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestResult.startTestRun
http://docs.python.org/3/library/unittest.html#unittest.TestResult.stopTestRun



result.py:

#!/usr/bin/env python3

import unittest

class Test(unittest.TestCase):
    def test_1(self):
        print('test_1')

    def test_2(self):
        print('test_2')
        self.fail('msg')
    
class Result(unittest.TestResult):
    def startTestRun(self, test):
        print('starttestrun', test)

    def stopTestRun(self, test):
        print('stoptestrun', test)

    def startTest(self, test):
        print('starttest', test)

    def stopTest(self, test):
        print('stoptest', test)

result = Result()
suite = unittest.defaultTestLoader.loadTestsFromTestCase(Test)
suite.run(result)

print(result)



output:

[guest at localhost result]$ ./result.py 
starttest test_1 (__main__.Test)
test_1
stoptest test_1 (__main__.Test)
starttest test_2 (__main__.Test)
test_2
stoptest test_2 (__main__.Test)
<__main__.Result run=0 errors=0 failures=1>
[guest at localhost result]$



I tried also print messages to a file - same thing

----------
components: Library (Lib)
messages: 196266
nosy: py.user
priority: normal
severity: normal
status: open
title: In unittest.TestResult .startTestRun() and .stopTestRun() methods don't work
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug 27 10:58:41 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Tue, 27 Aug 2013 08:58:41 +0000
Subject: [New-bugs-announce] [issue18849] Failure to try another name for
	tempfile when directory	with chosen name exists on windows
Message-ID: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>


New submission from Vlad Shcherbina:

When directory exists with a name chosen for new temporary file, OSError with EACCESS errno is thrown on windows, while attempts to chose another name only happen on EEXIST errors.


To reproduce, run
--------------- 8< -----------------
import sys
import tempfile
import os

print sys.platform
print sys.version

# Mock random names to ensure collision.
tempfile._RandomNameSequence = lambda: iter(['a', 'a', 'b'])

d = tempfile.mkdtemp()
print d

try:
    print tempfile.NamedTemporaryFile().name
finally:
    os.rmdir(d)
--------------- >8 -----------------


Expected result:
win32
2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
...\tmpa
...\tmpb


Actual result:
win32
2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
c:\users\shcher~1\appdata\local\temp\tmpa
Traceback (most recent call last):
  File "hz.py", line 13, in <module>
    print tempfile.NamedTemporaryFile().name
  File "C:\python_27_amd64\files\lib\tempfile.py", line 454, in NamedTemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "C:\python_27_amd64\files\lib\tempfile.py", line 235, in _mkstemp_inner
    fd = _os.open(file, flags, 0600)
OSError: [Errno 13] Permission denied: 'c:\\users\\shcher~1\\appdata\\local\\temp\\tmpa'

----------
components: Library (Lib), Windows
messages: 196269
nosy: Vlad.Shcherbina
priority: normal
severity: normal
status: open
title: Failure to try another name for tempfile when directory with chosen name exists on windows
type: behavior

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

From report at bugs.python.org  Tue Aug 27 11:50:51 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Tue, 27 Aug 2013 09:50:51 +0000
Subject: [New-bugs-announce] [issue18850] xml.etree.ElementTree accepts
	control chars.
Message-ID: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>


New submission from Michele Orr?:

Got from irc; 
<JerryKwan> python bug in xml.etree.ElementTree, from version 2.7 to 3.2 http://www.reddit.com/r/Python/comments/1l6cta/python_bug_in_xmletreeelementtree/

I think we should keep consistency with lxml and forbid control chars in advance. 
<https://en.wikipedia.org/wiki/Valid_characters_in_XML#XML_1.1>

Attaching the test file proving the issue, slightly modified to work on 2.7 and 3.x

----------
files: test.py
messages: 196271
nosy: maker
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree accepts control chars.
Added file: http://bugs.python.org/file31482/test.py

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

From report at bugs.python.org  Tue Aug 27 14:06:55 2013
From: report at bugs.python.org (Jan-Wijbrand Kolman)
Date: Tue, 27 Aug 2013 12:06:55 +0000
Subject: [New-bugs-announce] [issue18851] subprocess's Popen closes
	stdout/stderr filedescriptors	used in another thread when
	Popen errors
Message-ID: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>


New submission from Jan-Wijbrand Kolman:

An internal library that heavily uses subprocess.Popen() started failing its automated tests when we upgraded from Python 2.7.3 to Python 2.7.5. This library is used in a threaded environment. After debugging the issue, I was able to create a short Python script that demonstrates the error seen as in the failing tests.

This is the script (called "threadedsubprocess.py"):

===
import time
import threading
import subprocess

def subprocesscall():
    p = subprocess.Popen(
        ['ls', '-l'],
        stdin=subprocess.PIPE,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        )
    time.sleep(2) # simulate the Popen call takes some time to complete.
    out, err = p.communicate()
    print 'succeeding command in thread:', threading.current_thread().ident

def failingsubprocesscall():
    try:
        p = subprocess.Popen(
            ['thiscommandsurelydoesnotexist'],
            stdin=subprocess.PIPE,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            )
    except Exception as e:
        print 'failing command:', e, 'in thread:', threading.current_thread().ident

print 'main thread is:', threading.current_thread().ident

subprocesscall_thread = threading.Thread(target=subprocesscall)
subprocesscall_thread.start()
failingsubprocesscall()
subprocesscall_thread.join()
===

Note: this script does not exit with an IOError when ran from Python 2.7.3. It does fail at least 50% of the times when ran from Python 2.7.5 (both on the same Ubuntu 12.04 64-bit VM).

The error that is raised on Python 2.7.5 is this:

==
/opt/python/2.7.5/bin/python ./threadedsubprocess.py 
main thread is: 139899583563520
failing command: [Errno 2] No such file or directory 139899583563520
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/opt/python/2.7.5/lib/python2.7/threading.py", line 808, in __bootstrap_inner
    self.run()
  File "/opt/python/2.7.5/lib/python2.7/threading.py", line 761, in run
    self.__target(*self.__args, **self.__kwargs)
  File "./threadedsubprocess.py", line 13, in subprocesscall
    out, err = p.communicate()
  File "/opt/python/2.7.5/lib/python2.7/subprocess.py", line 806, in communicate
    return self._communicate(input)
  File "/opt/python/2.7.5/lib/python2.7/subprocess.py", line 1379, in _communicate
    self.stdin.close()
IOError: [Errno 9] Bad file descriptor

close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor
==

When comparing the subprocess module from Python 2.7.3 to Python 2.7.5 I see the Popen()'s __init__() call indeed now explicitly closes the stdin, stdout and stderr file descriptors in case executing the command somehow fails. This seems to be an intended fix applied in Python 2.7.4 to prevent leaking file descriptors (http://hg.python.org/cpython/file/ab05e7dd2788/Misc/NEWS#l629).

The diff between Python 2.7.3 and Python 2.7.5 that seems to be relevant to this issue is in the Popen __init__():

==
@@ -671,12 +702,33 @@
          c2pread, c2pwrite,
          errread, errwrite) = self._get_handles(stdin, stdout, stderr)

-        self._execute_child(args, executable, preexec_fn, close_fds,
-                            cwd, env, universal_newlines,
-                            startupinfo, creationflags, shell,
-                            p2cread, p2cwrite,
-                            c2pread, c2pwrite,
-                            errread, errwrite)
+        try:
+            self._execute_child(args, executable, preexec_fn, close_fds,
+                                cwd, env, universal_newlines,
+                                startupinfo, creationflags, shell,
+                                p2cread, p2cwrite,
+                                c2pread, c2pwrite,
+                                errread, errwrite)
+        except Exception:
+            # Preserve original exception in case os.close raises.
+            exc_type, exc_value, exc_trace = sys.exc_info()
+
+            to_close = []
+            # Only close the pipes we created.
+            if stdin == PIPE:
+                to_close.extend((p2cread, p2cwrite))
+            if stdout == PIPE:
+                to_close.extend((c2pread, c2pwrite))
+            if stderr == PIPE:
+                to_close.extend((errread, errwrite))
+
+            for fd in to_close:
+                try:
+                    os.close(fd)
+                except EnvironmentError:
==

Note: I think to see a similar change in the subprocess.Popen() __init__() from Python-3.3.0 to Python-3.3.1.

----------
components: Library (Lib)
messages: 196276
nosy: janwijbrand
priority: normal
severity: normal
status: open
title: subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Aug 27 15:15:08 2013
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 27 Aug 2013 13:15:08 +0000
Subject: [New-bugs-announce] [issue18852] Problem with pyreadline
Message-ID: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>


New submission from Thomas Heller:

In site.py, line 477, I find this code:

        # Reading the initialization (config) file may not be enough to set a
        # completion key, so we set one first and then read the file
        if 'libedit' in getattr(readline, '__doc__', ''):
            readline.parse_and_bind('bind ^I rl_complete')

I am using pyreadline on Windows, where readline.__doc__ is None.

So the above code crashes with this exception:

Python 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug  3 2013, 22:57:30) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "C:\Python34-64\lib\site.py", line 477, in register_readline
    if 'libedit' in getattr(readline, '__doc__', ''):
TypeError: argument of type 'NoneType' is not iterable

----------
components: Library (Lib)
keywords: 3.3regression
messages: 196285
nosy: theller
priority: normal
severity: normal
status: open
title: Problem with pyreadline
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 27 16:04:27 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 27 Aug 2013 14:04:27 +0000
Subject: [New-bugs-announce] [issue18853] Got ResourceWarning unclosed file
	when running	Lib/shlex.py demo
Message-ID: <1377612267.45.0.680080135941.issue18853@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

The python is compiled with --with-pydebug flag.

[sky at localhost cpython]$ cat /tmp/quote.txt 
manly "man" likes 'cute "cat"'
[sky at localhost cpython]$ ./python Lib/shlex.py /tmp/quote.txt 
Token: 'manly'
Token: '"man"'
Token: 'likes'
Token: '\'cute "cat"\''
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/quote.txt' mode='r' encoding='UTF-8'>

Attached the patch to close the file when running the demo.

----------
components: Library (Lib)
files: fix_resource_warning_shlex_test.patch
keywords: patch
messages: 196291
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got ResourceWarning unclosed file when running Lib/shlex.py demo
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file31485/fix_resource_warning_shlex_test.patch

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

From report at bugs.python.org  Tue Aug 27 16:05:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Aug 2013 14:05:12 +0000
Subject: [New-bugs-announce] [issue18854] is_multipart and walk should
	document their treatment of	'message' parts.
Message-ID: <1377612312.75.0.466824716408.issue18854@psf.upfronthosting.co.za>


New submission from R. David Murray:

A 'message' part is not, in fact, a multipart in RFC terms.  (Only 'multipart' messages are multiparts.)  The email package models 'message' parts by making them single-element "multipart" messages, with the single element being a Message object representing the 'message' part's payload.

This is very useful; however, the fact that this is done should be documented in at least the is_multipart and walk methods.  As motivation for documenting this, consider a program that is looking for "the first part of type X" in a Message.  If an attached 'message' object has such a part, it would be discovered by a naive algorithm that uses 'walk', even though it is *inside* an attachment instead of part of the main message.  As for is_multipart, a naive reader of the documentation might expect that is_multipart would be true if and only if get_content_maintype == 'multipart', when this is in fact not true.

(I made these mistakes myself while implementing get_body and iter_parts in the new API additions.)

----------
components: email
messages: 196292
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: is_multipart and walk should document their treatment of 'message' parts.
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug 27 17:16:10 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 15:16:10 +0000
Subject: [New-bugs-announce] [issue18855] Inconsistent README filenames
Message-ID: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>


New submission from Madison May:

Is there any reason (other than backwards compatibility) that the names of README files are inconsistent?

README: 3 instances - root, /Mac, /Misc, /Tools
readme.txt: 2 instances - /PC, /PCbuild
README.txt: 1 instance - /Doc

----------
assignee: docs at python
components: Documentation
messages: 196299
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Inconsistent README filenames

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

From report at bugs.python.org  Tue Aug 27 21:19:21 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 27 Aug 2013 19:19:21 +0000
Subject: [New-bugs-announce] [issue18856] Added test coverage for calendar
	print functions
Message-ID: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>


New submission from Madison May:

Just redirected stdout to a string io object unittest.mock.patch() to add basic test coverage for calendar.py print functions (TextCalendary.prweek(), TextCalendar.prmonth(), TextCalendar.pryear(), and format()).

----------
components: Tests
files: calendar_print.diff
keywords: patch
messages: 196311
nosy: madison.may
priority: normal
severity: normal
status: open
title: Added test coverage for calendar print functions
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31487/calendar_print.diff

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

From report at bugs.python.org  Tue Aug 27 21:54:15 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Tue, 27 Aug 2013 19:54:15 +0000
Subject: [New-bugs-announce] [issue18857] urlencode of a None value uses the
	string 'None'
Message-ID: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>


New submission from Joshua Johnston:

This is strange behavior. When you encode nulls in other languages you don't get the string 'null' you usually get an empy string. Shouldn't str(None) == ''?

If not str(None) == 'None' and the string representation of a None value should not match a known string

>>> from urllib import urlencode
>>> urlencode({'josh': None})
'josh=None'

----------
components: Extension Modules
messages: 196314
nosy: Joshua.Johnston
priority: normal
severity: normal
status: open
title: urlencode of a None value uses the string 'None'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug 27 23:27:23 2013
From: report at bugs.python.org (Jan Kaliszewski)
Date: Tue, 27 Aug 2013 21:27:23 +0000
Subject: [New-bugs-announce] [issue18858] dummy_threading lacks
	threading.get_ident() equivalent
Message-ID: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski:

In Python 3.3 threading.get_ident() has been added as a public and documented function, but there is no dummy_threading.get_ident():

    >>> import threading, dummy_threading
    >>> threading.get_ident()
    139974728402752
    >>> dummy_threading.get_ident()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: 'module' object has no attribute 'get_ident'

By the way: it may be worth to check for other possible inconsistencies between avaliable interfaces of threading and dummy_threading.

----------
components: Library (Lib)
messages: 196321
nosy: zuo
priority: normal
severity: normal
status: open
title: dummy_threading lacks threading.get_ident() equivalent
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug 28 02:19:49 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 28 Aug 2013 00:19:49 +0000
Subject: [New-bugs-announce] [issue18859] README.valgrind should mention
	--with-valgrind
Message-ID: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za>


New submission from Tim Peters:

In issue 18843 a user noted that Misc/README.valgrind doesn't mention the --with-valgrind configure option.  It probably should.  But since I've never used valgrind, I'm not the guy to do it ;-)

----------
components: Build
messages: 196338
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: README.valgrind should mention --with-valgrind
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug 28 03:28:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Aug 2013 01:28:30 +0000
Subject: [New-bugs-announce] [issue18860] Add content manager API to email
	package
Message-ID: <1377653310.93.0.882700028291.issue18860@psf.upfronthosting.co.za>


New submission from R. David Murray:

Here is a patch, layered on top of the patch in issue 18785, to add the content manager support.  This patch contains only the base ContentManager class, not the proposed functional registries.

----------
components: email
files: contentmanager.patch
keywords: patch
messages: 196342
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add content manager API to email package
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31491/contentmanager.patch

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

From report at bugs.python.org  Wed Aug 28 04:42:07 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 28 Aug 2013 02:42:07 +0000
Subject: [New-bugs-announce] [issue18861] Problems with recursive automatic
	exception chaining
Message-ID: <1377657727.9.0.627993776621.issue18861@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

Consider this:

$ python3 test_exc.py 
Traceback (most recent call last):
  File "test_exc.py", line 14, in <module>
    fail1()
  File "test_exc.py", line 11, in fail1
    fail2()
  File "test_exc.py", line 5, in fail2
    raise RuntimeError('Third') from None
RuntimeError: Third

$ cat test_exc.py 
def fail2():
    try:
        raise RuntimeError('Second')
    except RuntimeError:
        raise RuntimeError('Third') from None

def fail1():
    try:
        raise RuntimeError('First')
    except:
        fail2()
        raise

fail1()


Any exception raised in fail2() is the immediate consequence of the 'First' exception should thus be chained to the 'First' exception.

However, if somewhere in the call stack under fail2() an exception is caught and re-raised from None (to convert between exception types), this also results in a loss of the chain to the initial exception.


The correct stacktrace (in my opinion) would be:
Traceback (most recent call last):
  File "test_exc.py", line 9, in fail1
    raise RuntimeError('First')
RuntimeError: First

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_exc.py", line 14, in <module>
    fail1()
  File "test_exc.py", line 11, in fail1
    fail2()
  File "test_exc.py", line 5, in fail2
    raise RuntimeError('Third')
RuntimeError: Third

----------
components: Interpreter Core
messages: 196344
nosy: Nikratio
priority: normal
severity: normal
status: open
title: Problems with recursive automatic exception chaining
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug 28 05:10:36 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Aug 2013 03:10:36 +0000
Subject: [New-bugs-announce] [issue18862] Implement __subclasshook__() for
	Finders and Loaders in	importlib.abc
Message-ID: <1377659436.77.0.0929523139133.issue18862@psf.upfronthosting.co.za>


New submission from Eric Snow:

It would be helpful to have __subclasshook__() implemented on the finders and loaders in importlib.abc, following the approach taken by ABCs in collections.abc.  This came up relative to PEP 431, but would be generally useful (if only to a limited audience <wink>).

----------
components: Library (Lib)
keywords: easy
messages: 196346
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Implement __subclasshook__() for Finders and Loaders in importlib.abc
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 28 08:28:31 2013
From: report at bugs.python.org (G. Scott Johnston)
Date: Wed, 28 Aug 2013 06:28:31 +0000
Subject: [New-bugs-announce] [issue18863] Encoding a unicode with unicode()
	and ignoring errors
Message-ID: <1377671311.74.0.613410259035.issue18863@psf.upfronthosting.co.za>


New submission from G. Scott Johnston:

I've come up with the following series of minimal examples to demonstrate my bug. 


>>> unicode("")
u''
>>> unicode("", errors="ignore")
u''


>>> unicode("abc?")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)
>>> unicode("abc?", errors="ignore")
u'abc'


>>> unicode(3)
u'3'
>>> unicode(3, errors="ignore")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercing to Unicode: need string or buffer, int found


>>> unicode(unicode(""))
u''
>>> unicode(unicode(""), errors="ignore")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: decoding Unicode is not supported


The first two pairs of mini-programs are reasonable behaviour.  If the errors parameter is set to "ignore", no additional errors are thrown, but characters that produce encoding errors are skipped in the output, as expected.  

The third pair of mini-programs can be solved by instead writing unicode(str(3), errors="ignore").  This should likely be done automatically, given the fact that unicode(3) behaves as expected, and properly converts between types.  The fact that the conversion is done automatically without the errors parameter leads me to believe that there is a logic problem with the code, where the setting errors="ignore" changes the path of execution by more than just skipping characters that cause encoding errors.

The fourth pair of mini-programs is simply baffling.  The first mini-program clearly demonstrates that decoding a Unicode object is in fact supported.  The fact that the second mini-program claims it's not supported further demonstrates that the logic depends on the errors="ignore" parameter more than it should.

----------
messages: 196350
nosy: G..Scott.Johnston
priority: normal
severity: normal
status: open
title: Encoding a unicode with unicode() and ignoring errors
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 28 08:56:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 28 Aug 2013 06:56:18 +0000
Subject: [New-bugs-announce] [issue18864] Implementation for PEP
	451	(importlib.machinery.ModuleSpec)
Message-ID: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>


New submission from Eric Snow:

This ticket will track the implementation for PEP 451 (ModuleSpec).  I'll have a patch up in the next couple days.

----------
assignee: eric.snow
components: Interpreter Core, Library (Lib)
messages: 196352
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Implementation for PEP 451 (importlib.machinery.ModuleSpec)
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 28 09:36:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 07:36:45 +0000
Subject: [New-bugs-announce] [issue18865] multiprocessing: remove
	util.pipe()?
Message-ID: <1377675405.74.0.563721263875.issue18865@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In the implementation of the PEP 446, issue #18571, I replaced multiprocessing.util.pipe() with os.pipe() in the multiprocessing module.

Can we remove the multiprocessing.util.pipe() function? It is not public nor documented.

Charles-Fran?ois Natali added the comment (in issue #18571):

   14.1 --- a/Lib/multiprocessing/util.py
   14.2 +++ b/Lib/multiprocessing/util.py

   14.13  #
   14.14  # Return pipe with CLOEXEC set on fds
   14.15  #
   14.16 +# Deprecated: os.pipe() creates non-inheritable file descriptors
   14.17 +# since Python 3.4
   14.18 +#
   14.19
   14.20  def pipe():
   14.21 -    import _posixsubprocess
   14.22 -    return _posixsubprocess.cloexec_pipe()
   14.23 +    return os.pipe()

I guess you could remove util.pipe() altogether: it wasn't part of the public API.

----------
messages: 196354
nosy: haypo, neologix, sbt
priority: normal
severity: normal
status: open
title: multiprocessing: remove util.pipe()?
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 28 10:33:30 2013
From: report at bugs.python.org (Mathieu Dutour Sikiric)
Date: Wed, 28 Aug 2013 08:33:30 +0000
Subject: [New-bugs-announce] [issue18866] Invitation to connect on LinkedIn
Message-ID: <123334601.8021512.1377678808806.JavaMail.app@ela4-app0134.prod>


New submission from Mathieu Dutour Sikiric:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Mathieu

Mathieu Dutour Sikiric
visitor at Technische Universit?t Darmstadt
Croatia

Confirm that you know Mathieu Dutour Sikiric:
https://www.linkedin.com/e/-3qcne3-hkwae47b-w/isd/16114407170/_uBqO9cI/?hs=false&tok=1LB6yqjv-xn5U1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hkwae47b-w/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5360506395_1/?hs=false&tok=2-0L5OcgWxn5U1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 196357
nosy: mathieu37
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Wed Aug 28 10:40:00 2013
From: report at bugs.python.org (Mathieu Dutour Sikiric)
Date: Wed, 28 Aug 2013 08:40:00 +0000
Subject: [New-bugs-announce] [issue18867] Invitation to connect on LinkedIn
Message-ID: <1370453702.8006392.1377679198049.JavaMail.app@ela4-app1201.prod>


New submission from Mathieu Dutour Sikiric:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Mathieu

Mathieu Dutour Sikiric
visitor at Technische Universit?t Darmstadt
Croatia

Confirm that you know Mathieu Dutour Sikiric:
https://www.linkedin.com/e/-3qcne3-hkwamgk2-6i/isd/16114407170/_uBqO9cI/?hs=false&tok=2qk9t5ByeDn5U1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hkwamgk2-6i/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I5360539519_1/?hs=false&tok=0MVwAfDXCDn5U1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 196358
nosy: mathieu37
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Wed Aug 28 11:19:24 2013
From: report at bugs.python.org (Joe Borg)
Date: Wed, 28 Aug 2013 09:19:24 +0000
Subject: [New-bugs-announce] [issue18868] Python3 unbuffered stdin
Message-ID: <1377681564.92.0.926371389199.issue18868@psf.upfronthosting.co.za>


New submission from Joe Borg:

I'm in need of an unbuffered stdin for Python3.  Using the '-u' flag worked fine in Python2.  But, it seems, Python3's stdin is always buffered; as seen in http://bugs.python.org/issue4705.

This is not always desirable.  For example:

#!/bin/python3
import os, subprocess, time

with open("%s/unbuffered_test.log" % (os.getenv("HOME")), "w") as f:
    with subprocess.Popen(["%s/unbuffered_test.sh" % (os.getenv("HOME"))], stdin=subprocess.PIPE, stdout=f, stderr=f) as p:
        p.stdin.write(bytes("test\n", encoding="utf-8"))
        time.sleep(10)

Where unbuffered_test.sh is:
#!/bin/sh
read INPUT
echo $INPUT
exit 0

Running with -u in Python2 sees the log file populated before the 10 seconds are up.  This isn't the case in Python3.  This making controlling applications, using subprocess, basically impossible; without putting p.stdin.flush() after each command (which does work in the example above).

I ran this example in Python3.3.2.

----------
messages: 196359
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Python3 unbuffered stdin
versions: 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/issue18868>
_______________________________________

From report at bugs.python.org  Wed Aug 28 18:24:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 28 Aug 2013 16:24:53 +0000
Subject: [New-bugs-announce] [issue18869] test suite: faulthandler signal
	handler is lost
Message-ID: <1377707093.4.0.0816466324955.issue18869@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

At the beginning of the test suit execution, faulthandler registers its signal handler for fatal signals, as well as SIGUSR1 and SIGALRM.

The problem is that some tests temporary change those handlers, e.g. for EINTR-handling tests.
While they do restore the original handlers after the test, this doesn't work as expected because of an artifact of the signal implementation: when a signal handler isn't registered through the signal module (e.g. directly from C for faulthandler), getsignal() and setsignal() return None/SIG_DFL (depending on whether it was registered before or after the module initialization). Which means that when the test is done, it will restore the default signal handler, and not the faulthandler's one. Thus, any subsequent crash due to this signal won't benefit from faulthandler debug output, see e.g. (issue #18786):
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/616/steps/test/logs/stdio
"""
[310/379] test_multiprocessing_spawn
make: *** [buildbottest] User defined signal 1
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 4 leaked semaphores to clean up at shutdown
  len(cache))
program finished with exit code 2
elapsedTime=2459.665997
"""

One way to fix this would be to add a WithSignalHandler(signal, handler) context manager to test.support that would replace the signal handler upon entry, and re-register faulthandler's handler upon exit.

----------
components: Tests
messages: 196387
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: test suite: faulthandler signal handler is lost
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 28 20:18:22 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Wed, 28 Aug 2013 18:18:22 +0000
Subject: [New-bugs-announce] [issue18870] eval() uses latin-1 to decode str
Message-ID: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>


New submission from Merlijn van Deen:

Steps to reproduce:
-------------------
>>> eval("u'?'")
# in an utf-8 console, so this is equivalent to
>>> eval("u'\xc3\xa4'")

Actual result:
----------------
u'\xc3\xa4'
# i.e.: u'??'

Expected result:
-----------------
SyntaxError: Non-ASCII character '\xc3' in file <string> on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
(which is what would happen if it was in a source file)

Or, alternatively:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2: ordinal not in range(128)
(which is what results from decoding the str with sys.getdefaultencoding())

Instead, the string is interpreted as latin-1. The same happens for ast.literal_eval - even calling compile() directly.

In python 3.2, this is the result, as utf-8 is used as default source encoding:
>>> eval(b"'\xc3\xa4'")
'?'

Workarounds
----------
>>> eval("# encoding: utf-8\nu'\xc3\xa4'")
u'\xe4'
>>> eval("u'\xc3\xa4'".decode('utf-8'))
u'\xe4'


I understand this might be considered a WONTFIX, as it would change behavior some people might depend on. Nonetheless, documenting this explicitly seems a sensible thing to do.

----------
messages: 196398
nosy: valhallasw
priority: normal
severity: normal
status: open
title: eval() uses latin-1 to decode str
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 28 21:32:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 28 Aug 2013 19:32:58 +0000
Subject: [New-bugs-announce] [issue18871] Be more stringent about the test
	suite
Message-ID: <1377718378.43.0.460982109409.issue18871@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a proposal to make the devguide more precise and explicit about needing to run the entire test suite before committing a change.

----------
assignee: docs at python
components: Devguide, Documentation
files: test_suite.patch
keywords: patch
messages: 196405
nosy: asvetlov, docs at python, eric.araujo, ezio.melotti, ncoghlan, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: Be more stringent about the test suite
type: enhancement
versions: 3rd party
Added file: http://bugs.python.org/file31500/test_suite.patch

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

From report at bugs.python.org  Wed Aug 28 22:59:44 2013
From: report at bugs.python.org (Lorin Hochstein)
Date: Wed, 28 Aug 2013 20:59:44 +0000
Subject: [New-bugs-announce] [issue18872] platform.linux_distribution()
	doesn't recognize Amazon	Linux
Message-ID: <1377723584.12.0.843452970556.issue18872@psf.upfronthosting.co.za>


New submission from Lorin Hochstein:

Amazon EC2 has their own Fedora-like Linux distribution (http://aws.amazon.com/amazon-linux-ami/). This distribution isn't recognized by platform.linux_distribution():

>>> import platform
>>> platform.linux_distribution()
('', '', '')

$ cat /etc/issue
Amazon Linux AMI release 2013.03
Kernel \r on an \m

Tested on Python 2.6.8.

----------
components: Library (Lib)
messages: 196420
nosy: Lorin.Hochstein
priority: normal
severity: normal
status: open
title: platform.linux_distribution() doesn't recognize Amazon Linux
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Aug 29 01:50:28 2013
From: report at bugs.python.org (Paul Bonser)
Date: Wed, 28 Aug 2013 23:50:28 +0000
Subject: [New-bugs-announce] [issue18873] "Encoding" detected in non-comment
	lines
Message-ID: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>


New submission from Paul Bonser:

lib2to3.pgen2.tokenize:detect_encoding looks for the regex "coding[:=]\s*([-\w.]+)" in the first two lines of the file without first checking if they are comment lines.

You can get 2to3 to fail with "SyntaxError: unknown encoding: 0" with a single line file:

    coding=0

A simple fix would be to check that the line is a comment before trying to look up the encoding from that line.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 196435
nosy: Paul.Bonser
priority: normal
severity: normal
status: open
title: "Encoding" detected in non-comment lines
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Aug 29 01:53:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Aug 2013 23:53:11 +0000
Subject: [New-bugs-announce] [issue18874] Add a new tracemalloc module to
	trace memory allocations
Message-ID: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Thanks to the PEP 445, it becomes possible to trace easily memory allocations. I propose to add a new tracemalloc module computing the memory usage per file and per line number.

I implemented the module as a third party module for Python 2.5-3.4, but it requires to patch and recompile Python:
https://pypi.python.org/pypi/pytracemalloc


My proposed implementation is different:

* use a simple C implementation of an hash table called "cfuhash" (coming from the libcfu project) instead of depending on the glib library ; I simplified and adapted the implementation for my usage

* no enable() / disable() function: tracemalloc can only be enabled before startup by setting PYTHONTRACEMALLOC=1 environment variable

* traces (size of the memory block, Python filename, Python line number) are stored directly in the memory block, not in a separated hash table

I chose PYTHONTRACEMALLOC env var instead of enable()/disable() functions to be able to really trace *all* memory allocated by Python, especially memory allocated at startup, during Python initialization.


TODO:

* The (high-level) API should be reviewed and discussed

* The documention should be improved

* PyMem_Raw API is not hooked yet because the code is not thread-safe (it relies on the Python GIL)

* Filenames should not be encoded: the hash table should directly use Unicode strings (PyObject*), encoding a filename allocates memory and may call the garbage collector

* Memory is not released at exit


For the documentation, see the following page:
https://pypi.python.org/pypi/pytracemalloc


See also the https://bitbucket.org/haypo/pyfailmalloc project and the issue #18408.

----------
hgrepos: 206
messages: 196436
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a new tracemalloc module to trace memory allocations
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 29 13:58:18 2013
From: report at bugs.python.org (irdb)
Date: Thu, 29 Aug 2013 11:58:18 +0000
Subject: [New-bugs-announce] [issue18875] Automatic insertion of the closing
	parentheses, brackets, and braces
Message-ID: <1377777498.6.0.468253349222.issue18875@psf.upfronthosting.co.za>


New submission from irdb:

Many other IDE's have this feature that allows automatic insertion of closing parentheses as user is typing something. I think it saves time and increases programming speed. Is it possible to have this on IDLE, too?

----------
components: IDLE
messages: 196456
nosy: irdb
priority: normal
severity: normal
status: open
title: Automatic insertion of the closing parentheses, brackets, and braces
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 29 19:07:33 2013
From: report at bugs.python.org (Erik Bray)
Date: Thu, 29 Aug 2013 17:07:33 +0000
Subject: [New-bugs-announce] [issue18876] Problems with files opened in
	append mode with io module
Message-ID: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>


New submission from Erik Bray:

I've come across a few difficulties of late with the io module's handling of files opened in append mode (any variation on 'a', 'ab', 'a+', 'ab+', etc.

The biggest problem is that the io module does not in any way keep track of whether a file was opened in append mode, and it's essentially impossible to determine the original mode string that was provided by the user.  For example:

>>> f = open('test', mode='ab+', buffering=0)
>>> f
<_io.FileIO name='test' mode='rb+'>

The 'a' is gone.  That doesn't mean the file *isn't* in append mode.  If supported, in fileio_init this still causes the O_APPEND flag to be added to the open() call.  But the *only* way to find out after the fact that the file  was actually opened in append mode is with fcntl:

>>> fcntl.fcntl(f.fileno(), fnctl.F_GETFL) & os.O_APPEND
1024

but this is hardly easily accessible or portable.  So it's possible to have two files open in 'rb+' mode but that have wildly differing behaviors.

The only other thing fileio_init does differently with append mode is that it seeks to the end of the file by default.  But that does not make the append behavior "portable".  If, on a system where O_APPEND was not supported, I seek to a different part of the file and the call write() it will *not* append to the end of the file.  Whereas the behavior of O_APPEND causes an automatic seek to the end before any write().

The fact that no record of the request for 'append' mode is kept leads to further bugs, particularly in BufferedWriter.  It doesn't know the raw file was opened with O_APPEND so the writes it shows in the buffer differ from what will actually end up in the file.  For example:

>>> f = open('test', 'wb')
>>> f.write(b'testest')
7
>>> f.close()
>>> f = open('test', 'ab+')
>>> f.tell()
7
>>> f.write(b'A')
1
>>> f.seek(0)
0
>>> f.read()
b'testestA'
>>> f.seek(0)
0
>>> f.read(1)
b't'
>>> f.write(b'B')
1
>>> f.seek(0)
0
>>> f.read()
b'tBstestA'
>>> f.flush()
>>> f.seek(0)
0
>>> f.read()
b'testestAB'

In this example, I read 1 byte from the beginning of the file, then write one byte.  Because of O_APPEND, the effect of the write() call on the raw file is to append, regardless of where BufferedWriter seeks it to first.  But before the f.flush() call f.read() just shows what's in the buffer which is not what will actually be written to the file.  (Naturally, unbuffered io does not have this particular problem.)

So, I'm thinking maybe the fileio struct needs to grow an 'append' member.  This could be used to provide a more accurate mode string, and could for example in fileio_write to provide append-like support where it isn't natively supported (though perhaps without any guarantees as to atomicity).

----------
components: IO
messages: 196464
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Problems with files opened in append mode with io module
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Aug 29 20:52:47 2013
From: report at bugs.python.org (tegavu)
Date: Thu, 29 Aug 2013 18:52:47 +0000
Subject: [New-bugs-announce] [issue18877] tkinter askopenfilenames does not
	work in Windows	library folder
Message-ID: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>


New submission from tegavu:

Using Python 3.3 on W7x64 I wanted to create a file dialog that allows me to select multiple files.
The code below is an example of how to re-create the bug.

# -*- coding: iso-8859-15 -*-
# Python 3

import tkinter 
import tkinter.filedialog  

def callback():
    name = tkinter.filedialog.askopenfilenames() 
    print(name)
     
tkinter.Button(text='File Open', command=callback).pack()
tkinter.mainloop()


---------
THE PROBLEM:
When selecting any file in the windows library\* folders (those: http://beingpc.com/wp-content/uploads/2011/05/How-to-Change-the-Windows-7-Library-Icon.jpg ) the return value that will be printed is always {}.
tkinter.filedialog.askopenfilename() (without the 's') works fine also in those directories.

Can anyone reproduce this behavior?

----------
components: Tkinter, Windows
messages: 196479
nosy: tegavu
priority: normal
severity: normal
status: open
title: tkinter askopenfilenames does not work in Windows library folder
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 29 21:48:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Aug 2013 19:48:58 +0000
Subject: [New-bugs-announce] [issue18878] Add support of the 'with'
	statement to sunau.open.
Message-ID: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds support of the 'with' statement to sunau.open (as it already was added for aifc.open and wave.open). It based on patches from issue17616.

----------
components: Library (Lib)
messages: 196482
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add support of the 'with' statement to sunau.open.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 29 22:25:43 2013
From: report at bugs.python.org (jort bloem)
Date: Thu, 29 Aug 2013 20:25:43 +0000
Subject: [New-bugs-announce] [issue18879] tempfile.NamedTemporaryFile can
	close the file too early, if not assigning to a variable
Message-ID: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>


New submission from jort bloem:

Issue occurs in the following code: tempfile.NamedTemporaryFile(dir=".",delete=False).write("hello")

The NamedTemporaryFile is deleted before the write is complete; deleting the object closes the file, so the write fails.

----------
messages: 196485
nosy: jort.bloem
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile can close the file too early, if not assigning to a variable
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Aug 29 23:36:58 2013
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBaaWVsacWEc2tp?=)
Date: Thu, 29 Aug 2013 21:36:58 +0000
Subject: [New-bugs-announce] [issue18880] ssl.SSLSocket shutdown doesn't
	behave like	socket.shutdown
Message-ID: <1377812218.52.0.68669263864.issue18880@psf.upfronthosting.co.za>


New submission from Micha? Zieli?ski:

SSLSocket documentation mentions shutdown as analogue to socket.shutdown. However, instead of forbidding communication, it removes SSL wrapper from socket. For example, the following script doesn't work and returns garbage:

    import socket
    import ssl

    s = socket.socket()
    s.connect(('google.com', 443))
    client = ssl.wrap_socket(s)
    client.sendall(b'GET / HTTP/1.0\nConnection: close\n\n')
    client.shutdown(socket.SHUT_WR)

    print(repr(client.recv(40)))

Attached patch makes shutdown raise exception if how != SHUT_RDWR, as closing one side of socket over SSL doesn't make sense (unless I'm missing something).

----------
components: Library (Lib)
files: ssl-shutdown-fail.patch
keywords: patch
messages: 196494
nosy: zielmicha
priority: normal
severity: normal
status: open
title: ssl.SSLSocket shutdown doesn't behave like socket.shutdown
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31514/ssl-shutdown-fail.patch

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

From report at bugs.python.org  Fri Aug 30 01:43:29 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 29 Aug 2013 23:43:29 +0000
Subject: [New-bugs-announce] [issue18881] Can someone try to duplicate
	corruption on Gentoo?
Message-ID: <CAExdVN=6SMyxLMPi+KiFTH5ophjM1kz9St8jYqNm38hANujUZg@mail.gmail.com>


New submission from Tim Peters:

In

    http://bugs.python.org/issue18843

a user reported a debug PyMalloc "bad leading pad byte" memory
corruption death while running their code.  After some thrashing, they
decided to rebuild Python, and got the same kind of error while
rebuilding Python.  See

    http://bugs.python.org/msg196481

in that bug report:

"""
# emerge dev-lang/python:2.7

 * IMPORTANT: 11 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.

Calculating dependencies... done!
Debug memory block at address p=0xa7f5900: API 'o'
    80 bytes originally requested
    The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb):
        at p-7: 0xfb
        at p-6: 0xfb
        at p-5: 0xfa *** OUCH
        at p-4: 0xfb
        at p-3: 0xfb
        at p-2: 0xfb
        at p-1: 0xfb
    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=0xa7f5950 are FORBIDDENBYTE, as expected.
    The block was made by call #21242094 to debug malloc/realloc.
    Data at p: 73 00 00 00 79 00 00 00 ... 67 00 00 00 00 00 00 00
Fatal Python error: bad leading pad byte
Aborted (core dumped)
#
"""

I don't have access to Gentoo, and don't know squat about its
`emerge`, but if someone else can do this it might help ;-)  The
Python used to run `emerge` here was a --with-pydebug Python the bug
reporter built earlier.

----------
messages: 196502
nosy: tim.peters
priority: normal
severity: normal
status: open
title: Can someone try to duplicate corruption on Gentoo?

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

From report at bugs.python.org  Fri Aug 30 12:26:46 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 30 Aug 2013 10:26:46 +0000
Subject: [New-bugs-announce] [issue18882] Add threading.main_thread()
	function
Message-ID: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

We need public API for getting main thread object.
See also http://comments.gmane.org/gmane.comp.python.devel/141370

----------
messages: 196521
nosy: asvetlov, haypo, pitrou
priority: normal
severity: normal
status: open
title: Add threading.main_thread() function
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 30 15:27:32 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 13:27:32 +0000
Subject: [New-bugs-announce] [issue18883] python-3.3.2-r2:
	Modules/xxlimited.c:17:error: #error	Py_LIMITED_API is
	incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
Message-ID: <1377869252.37.0.462052472279.issue18883@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Looks I cannot compile when python-3.3 was configured with --with-pydebug. I use Gentoo Linux, the -r2 shows they added some patches but should not matter I think.

building 'xxlimited' extension
x86_64-pc-linux-gnu-gcc -pthread -fPIC -Wno-unused-result -DDYNAMIC_ANNOTATIONS_ENABLED=1 -O2 -pipe -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -maes -mpclmul -mpopcnt -march=corei7-avx -fstack-protector-all -fwrapv -DPy_LIMITED_API=1 -IInclude -I. -I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include -I/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/x86_64-pc-linux-gnu -c /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c -o build/temp.linux-x86_64-3.3-pydebug/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.o
In file included from /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/Python.h:68:0,
                 from /mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Modules/xxlimited.c:17:
/mnt/1TB/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Include/object.h:65:2: error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG


I think make should ignore this error unless you fix xxlimited.c sources.

----------
files: build.log
messages: 196534
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-3.3.2-r2: Modules/xxlimited.c:17:error: #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file31520/build.log

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

From report at bugs.python.org  Fri Aug 30 15:45:47 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Fri, 30 Aug 2013 13:45:47 +0000
Subject: [New-bugs-announce] [issue18884] python-2.7.5-r3: 40 bytes in 1
	blocks are definitely lost
Message-ID: <1377870347.55.0.997907560608.issue18884@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

It is not important why I had in this moment matplotlib not in sync with python itself whcih was configure using --with-pydebug ... but here I just want to show that maybe you do not test for memleaks using valgrind on import errors (maybe include such testcase into you tests).
Anyway, here is what I got:


==14007== Memcheck, a memory error detector
==14007== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14007== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14007== Command: /usr/bin/python2.7 blah.py
==14007== 
Traceback (most recent call last):
  File "blah.py", line 288, in <module>
    import pylab
  File "/usr/lib64/python2.7/site-packages/pylab.py", line 1, in <module>
    from matplotlib.pylab import *
  File "/usr/lib64/python2.7/site-packages/matplotlib/pylab.py", line 222, in <module>
    from matplotlib import mpl  # pulls in most modules
  File "/usr/lib64/python2.7/site-packages/matplotlib/mpl.py", line 1, in <module>
    from matplotlib import artist
  File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 7, in <module>
    from transforms import Bbox, IdentityTransform, TransformedBbox, \
  File "/usr/lib64/python2.7/site-packages/matplotlib/transforms.py", line 35, in <module>
    from matplotlib._path import (affine_transform, count_bboxes_overlapping_bbox,
ImportError: /usr/lib64/python2.7/site-packages/matplotlib/_path.so: undefined symbol: _PyMem_DebugFree
[100070 refs]
==14007== 
==14007== HEAP SUMMARY:
==14007==     in use at exit: 6,303,492 bytes in 31,921 blocks
==14007==   total heap usage: 1,266,299 allocs, 1,234,378 frees, 179,304,947 bytes allocated
==14007== 
==14007== 40 bytes in 1 blocks are definitely lost in loss record 167 of 3,515
==14007==    at 0x4C2C63B: malloc (vg_replace_malloc.c:270)
==14007==    by 0x4EF1E8C: PyMem_Malloc (object.c:2343)
==14007==    by 0x10064848: initialize_builtin_datetime_metadata (arraytypes.c.src:3953)
==14007==    by 0x100719E2: set_typeinfo (arraytypes.c.src:4047)
==14007==    by 0x1016354E: initmultiarray (multiarraymodule.c:4057)
==14007==    by 0x4FB2661: _PyImport_LoadDynamicModule (importdl.c:53)
==14007==    by 0x4FAE3A7: load_module (import.c:1915)
==14007==    by 0x4FB07C1: import_submodule (import.c:2700)
==14007==    by 0x4FAFCC6: load_next (import.c:2515)
==14007==    by 0x4FAED8B: import_module_level (import.c:2224)
==14007==    by 0x4FAF320: PyImport_ImportModuleLevel (import.c:2288)
==14007==    by 0x4F78862: builtin___import__ (bltinmodule.c:49)

----------
components: Interpreter Core
messages: 196538
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-2.7.5-r3: 40 bytes in 1 blocks are definitely lost
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 30 17:02:35 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 15:02:35 +0000
Subject: [New-bugs-announce] [issue18885] handle EINTR in the stdlib
Message-ID: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

As discussed in http://mail.python.org/pipermail/python-dev/2013-August/128204.html, I think that we shouldn't let EINTR leak to Python code: it should be handled properly by the C code, so that users (and the Python part of the stdlib) don't have to worry about this low-level historical nuisance.

For code that doesn't release the GIL, we could simply use this glibc macro:
# define TEMP_FAILURE_RETRY(expression) \
  (__extension__                                                              \
    ({ long int __result;                                                     \
       do __result = (long int) (expression);                                 \
       while (__result == -1L && errno == EINTR);                             \
       __result; }))
#endif

Now, I'm not sure about how to best handle this for code that releases the GIL.

Basically:

    Py_BEGIN_ALLOW_THREADS
    pid = waitpid(pid, &status, options);
    Py_END_ALLOW_THREADS

should become

begin_handle_eintr:
        Py_BEGIN_ALLOW_THREADS
        pid = waitpid(pid, &status, options);
        Py_END_ALLOW_THREADS

        if (pid < 0 && errno == EINTR) {
            if (PyErr_CheckSignals())
                return NULL;
            goto begin_handle_eintr;
        }

Should we do this with a macro?

If yes, should it be a new one that should be placed around Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS (like BEGIN_SELECT_LOOP in selectmodule.c) or could we have a single macro that would do both (i.e. release the GIL / reacquire the GIL, and try again in case of EINTR, unless a signal handler raised an exception)?

>From a cursory look, the main files affected would be:
Modules/fcntlmodule.c
Modules/ossaudiodev.c
Modules/posixmodule.c
Modules/selectmodule.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/socketmodule.c
Modules/syslogmodule.c

----------
messages: 196555
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: handle EINTR in the stdlib
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug 30 22:37:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Aug 2013 20:37:30 +0000
Subject: [New-bugs-announce] [issue18886] BytesGenerator does not handle
	'binary' CTE correctly
Message-ID: <1377895050.78.0.441930672492.issue18886@psf.upfronthosting.co.za>


New submission from R. David Murray:

ByteGenerator will assume that it can change any linesep characters to the linesep being used for the general message serialization, even if the content transfer encoding is 'binary'.  This is incorrect, as existing \r and \n characters in binary parts must be retained exactly as is.

----------
components: email
messages: 196572
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: BytesGenerator does not handle 'binary' CTE correctly
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 31 00:27:24 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Aug 2013 22:27:24 +0000
Subject: [New-bugs-announce] [issue18887]
	test_multiprocessing.test_connection failure
Message-ID: <1377901644.63.0.505553589029.issue18887@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

http://buildbot.python.org/all/builders/x86%20Windows7%202.7/builds/2211/steps/test/logs/stdio

"""
test_ignore_listener (test.test_multiprocessing.TestIgnoreEINTR) ... test test_multiprocessing failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\test\test_multiprocessing.py", line 1524, in test_connection
    conn.send_bytes(really_big_msg)
ValueError: Cannnot send 16777216 bytes over connection
"""

----------
components: Tests
messages: 196591
nosy: neologix, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing.test_connection failure
type: behavior

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

From report at bugs.python.org  Sat Aug 31 02:23:49 2013
From: report at bugs.python.org (Madison May)
Date: Sat, 31 Aug 2013 00:23:49 +0000
Subject: [New-bugs-announce] [issue18888] Add stdlib support for random
	sampling with replacement
Message-ID: <1377908629.62.0.534510987475.issue18888@psf.upfronthosting.co.za>


New submission from Madison May:

Although the random module supports random sampling without replacement, there is no support for random sampling with replacement.  Efficient random sampling with replacement is trivial using random.choice() (see below), but supporting it as an optional 'replace' arg to random.sample() might be nice for symmetry. 

array = range(100)
random_sample = [random.choice(array) for i in range(10)]

----------
components: Library (Lib)
messages: 196603
nosy: madison.may
priority: normal
severity: normal
status: open
title: Add stdlib support for random sampling with replacement
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug 31 03:33:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Aug 2013 01:33:31 +0000
Subject: [New-bugs-announce] [issue18889] test_sax: multiple failures on
	Windows desktop
Message-ID: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

These are due to \r in line endings, as with #12037.
  File "F:\Python\dev\py34\lib\test\test_sax.py", line 634, in test_expat_file
    self.assertEqual(result.getvalue(), xml_test_out)

Assert fails because off many \rs in xml_text_out. Same in

line 649, in test_expat_file_nonascii
line 778, in test_expat_inpsource_filename
line 788, in test_expat_inpsource_sysid
line 803, in test_expat_inpsource_sysid_nonascii
line 816, in test_expat_inpsource_stream

A fix that works is essentially the same as for #12037:
  xml_test_out = xml_test_out.replace(b'r', b'')
just after xml_test_out is read from the file.
(.translate(None, b'\r') also works, seems slightly slower)

Another would be to not put \r in the file in the first place;-).

Any objection to this?

----------
files: 188xx_text_sax.diff
keywords: patch
messages: 196606
nosy: christian.heimes, terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: test_sax: multiple failures on Windows desktop
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31526/188xx_text_sax.diff

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

From report at bugs.python.org  Sat Aug 31 04:35:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 02:35:52 +0000
Subject: [New-bugs-announce] [issue18890] Add a raw_data_manager content
	manager to the email	package.
Message-ID: <1377916552.26.0.723801852284.issue18890@psf.upfronthosting.co.za>


New submission from R. David Murray:

This is the third of three layered patches that introduce a new content management API to the email package.  This patch is layered on top of the patch in issue 18860.  Unfortunately the fact that these patches are layered (which I did in hopes of making them into more reviewable chunks) means that only the first one gets a rietveld link.

This patch provides the raw_data_manager, and makes it the default content_manager.  The raw_data_manager doesn't provide any facilities beyond that provided by the base API of email package, but it does provide those facilities in a much more convenient and consistent API.

----------
components: email
files: raw_data_manager.patch
keywords: patch
messages: 196610
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add a raw_data_manager content manager to the email package.
versions: Python 3.4
Added file: http://bugs.python.org/file31528/raw_data_manager.patch

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

From report at bugs.python.org  Sat Aug 31 05:10:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 31 Aug 2013 03:10:03 +0000
Subject: [New-bugs-announce] [issue18891] Master patch for content manager
	addtion to email	package.
Message-ID: <1377918603.72.0.362957249668.issue18891@psf.upfronthosting.co.za>


New submission from R. David Murray:

Since the only way to get a rietveld review link for all the changes is to post a single complete patch, I'm doing so in this issue.  Feel free to review based on either this or the separate patches posted in issue 18785, issue 18860, and issue 18890.

There are a couple of bug fixes in this code, but for the most part it is the addition of a new sub-modulej, and a new subclass to the message.py code, plus the accompanying documentation.

Note that this pretty much completes the proposed API additions to the email module.  There may be some additional small tweaks, and there will certainly be some additional support code for specific message header and message types later, but checking this in will mark the completion of the email6 implementation from my point of view.  (The project won't be complete, of course, until the code becomes non-provisional, hopefully in 3.5.)

----------
components: email
files: master_content_manager.patch
keywords: patch
messages: 196613
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Master patch for content manager addtion to email package.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31529/master_content_manager.patch

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

From report at bugs.python.org  Sat Aug 31 09:10:38 2013
From: report at bugs.python.org (Heijink)
Date: Sat, 31 Aug 2013 07:10:38 +0000
Subject: [New-bugs-announce] [issue18892] sqlite3,
	valued records not persisted, default ones are
Message-ID: <1377933038.86.0.811831713393.issue18892@psf.upfronthosting.co.za>


New submission from Heijink:

In the end I tracked down the behaviour with the attached program
behaviour with an initially empty table:

7 : insert two records with values in the columns
two records show up, # 1,2
as expected
9 : show al records
none
whereas two are to be expected
8 : add records with default values
two records show up # 1,2
as expected in an empty table
7
two records # 3,4
record numbers as expected, but where are records 1,2?  (ABC)
9
the default records are present #1,2
the previous valued records 3,4 not
  unexpected, but identical to first behaviour issuing 7
8
4 records show up # 1-4
record numbers as expected when valued records are not present
0  :  I quit

to summarize:
It is not possible to store records in the database with valued columns.
Records with default values can be stored and retrieved, they are the ones that are persistent
Additional strange behaviour is that after adding valued records (3,4) also the already present records with default values (1,2) should have shown show up, remark (ABC).

----------
components: Demos and Tools
files: dump.py
messages: 196617
nosy: debewerker
priority: normal
severity: normal
status: open
title: sqlite3, valued records not persisted, default ones are
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file31531/dump.py

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

From report at bugs.python.org  Sat Aug 31 12:56:26 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 31 Aug 2013 10:56:26 +0000
Subject: [New-bugs-announce] [issue18893] typo in Lib/ctypes/macholib/dyld.py
Message-ID: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The exception handling clauses in framework_find() are weird.


def framework_find(fn, executable_path=None, env=None):
    """
    Find a framework using dyld semantics in a very loose manner.

    Will take input such as:
        Python
        Python.framework
        Python.framework/Versions/Current
    """
    try:
        return dyld_find(fn, executable_path=executable_path, env=env)
    except ValueError as e:
        pass
    fmwk_index = fn.rfind('.framework')
    if fmwk_index == -1:
        fmwk_index = len(fn)
        fn += '.framework'
    fn = os.path.join(fn, os.path.basename(fn[:fmwk_index]))
    try:
        return dyld_find(fn, executable_path=executable_path, env=env)
    except ValueError:
        raise e


My guess is that this is left-over code from Py2.x. Since it doesn't make sense to catch an exception in the second clause just to re-raise it, I think the intention was really to re-raise the original exception caught in the first clause, which no longer works that way in Py3.

The fix would then be to assign the exception to a new variable in the first except clause and re-raise that in the second.

I found this problem because Cython rejected the module with a compile error about "e" being undefined in the last line.

----------
components: Library (Lib), ctypes
messages: 196629
nosy: scoder
priority: normal
severity: normal
status: open
title: typo in Lib/ctypes/macholib/dyld.py
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 31 18:22:54 2013
From: report at bugs.python.org (py.user)
Date: Sat, 31 Aug 2013 16:22:54 +0000
Subject: [New-bugs-announce] [issue18894] In unittest.TestResult.failures
	remove deprecated fail*	methods
Message-ID: <1377966174.08.0.355322542495.issue18894@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestResult.failures

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 196644
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestResult.failures remove deprecated fail* methods
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31534/issue.diff

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

From report at bugs.python.org  Sat Aug 31 18:26:06 2013
From: report at bugs.python.org (py.user)
Date: Sat, 31 Aug 2013 16:26:06 +0000
Subject: [New-bugs-announce] [issue18895] In unittest.TestResult.addError
	split the sentence
Message-ID: <1377966366.86.0.69110585984.issue18895@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/unittest.html#unittest.TestResult.addError

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 196645
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestResult.addError split the sentence
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31535/issue.diff

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

From report at bugs.python.org  Sat Aug 31 20:05:10 2013
From: report at bugs.python.org (Alori)
Date: Sat, 31 Aug 2013 18:05:10 +0000
Subject: [New-bugs-announce] [issue18896] Remove namedtuple 255 arguments
	restriction
Message-ID: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>


New submission from Alori:

Named tuples offer a useful mix of features from both dict and tuple data structures. However, unlike dictionaries and tuples, Named tuples are only allowed to hold up to 255 items.

This behavior seems inconsistent and un-Pythonic.
Is there a way to remove this restriction? Why not set a much higher limit?

Also see:
http://grokbase.com/t/python/python-ideas/109hbv63sv/new-3-x-restriction-on-number-of-keyword-arguments#responses_tab_top

http://stackoverflow.com/questions/18550270/any-way-to-bypass-namedtuple-255-arguments-limitation

----------
messages: 196660
nosy: valorien
priority: normal
severity: normal
status: open
title: Remove namedtuple 255 arguments restriction
type: enhancement
versions: Python 3.3

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