From report at bugs.python.org  Mon Apr  1 00:03:10 2013
From: report at bugs.python.org (Sebastian Ortiz Vasquez)
Date: Sun, 31 Mar 2013 22:03:10 +0000
Subject: [New-bugs-announce] [issue17606] BUG: XMLGenerator cannot output
	with the correct encoding
Message-ID: <1364767390.87.0.956919246275.issue17606@psf.upfronthosting.co.za>


New submission from Sebastian Ortiz Vasquez:

The XMLGenerator character method is unable to detect and encode using the encoding defined in the constructor.

This yields to an UnicodeEncode exception, because always tries to encode using 'ascii' as default in python 2

----------
components: XML
files: XMLGenerator.patch
keywords: patch
messages: 185684
nosy: Arfrever, BreamoreBoy, benjamin.peterson, doerwalter, georg.brandl, larry, loewis, neoecos, neoecos, ngrig, pitrou, python-dev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: BUG: XMLGenerator cannot output with the correct encoding
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file29640/XMLGenerator.patch

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

From report at bugs.python.org  Mon Apr  1 06:45:51 2013
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 01 Apr 2013 04:45:51 +0000
Subject: [New-bugs-announce] [issue17607] missed peephole optimization
	(unnecessary jump at end of	function after yield)
Message-ID: <1364791551.27.0.510465438261.issue17607@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

>>> def foo():
...   if x:
...     yield None
... 
>>> dis.dis(foo)
  2           0 LOAD_GLOBAL              0 (x)
              3 POP_JUMP_IF_FALSE       14

  3           6 LOAD_CONST               0 (None)
              9 YIELD_VALUE         
             10 POP_TOP             
             11 JUMP_FORWARD             0 (to 14)
        >>   14 LOAD_CONST               0 (None)
             17 RETURN_VALUE        


The JUMP_FORWARD at 11 is not necessary and is not in place with a return in the code:

>>> def foo():
...  if x:
...   return None
... 
>>> dis.dis(foo)
  2           0 LOAD_GLOBAL              0 (x)
              3 POP_JUMP_IF_FALSE       10

  3           6 LOAD_CONST               0 (None)
              9 RETURN_VALUE        
        >>   10 LOAD_CONST               0 (None)
             13 RETURN_VALUE

----------
components: Interpreter Core
messages: 185708
nosy: Neal.Norwitz
priority: normal
severity: normal
status: open
title: missed peephole optimization (unnecessary jump at end of function after yield)
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  1 07:40:10 2013
From: report at bugs.python.org (Rodney Persky)
Date: Mon, 01 Apr 2013 05:40:10 +0000
Subject: [New-bugs-announce] [issue17608] configparser not honouring section
	but not variable case
Message-ID: <1364794810.72.0.199775169756.issue17608@psf.upfronthosting.co.za>


New submission from Rodney Persky:

Hey,

Just a fairly small one in the configparser library. I've got a bunch of variables with varying capitalisation to indicate words in the variable name.

The config file contains lines such as:
[GlobalSection]
ParameterDelimiterCharacter = ,


Watching the program, at some point (this is straight from a for loop) the capitalisation gets lost:
Looking for ['GlobalSection', 'parameterdelimitercharacter']

----------
components: Library (Lib), Windows
messages: 185718
nosy: Rodney.Persky
priority: normal
severity: normal
status: open
title: configparser not honouring section but not variable case
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  1 13:51:27 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 01 Apr 2013 11:51:27 +0000
Subject: [New-bugs-announce] [issue17609] IDLE: Remove config option 'editor
	on startup' and	utilize command line options only
Message-ID: <1364817087.43.0.386717084157.issue17609@psf.upfronthosting.co.za>


New submission from Todd Rovito:

Based on enhancements from this issue:
http://bugs.python.org/issue6698

Comments from Tal Einat

The "editor-on-startup" config option should be removed. Running IDLE without arguments should open a shell. If IDLE is asked to open any files for editing, it should open just editor windows. IDLE should open both a shell window and one or more editor windows only when explicitly asked to do so on the command line.

If this is done, the -e option ("open an editor") would tell IDLE to open an empty editor window if no files are asked to be opened for editing. If no other arguments are given, IDLE will open just an editor window (no shell window). The -i option ("open a shell") would tell IDLE to open a shell window even if asked to open files for editing.

I think this is more obvious and easier to work with. It will also make the command line argument processing code simpler. And as a bonus we remove a config option :)

I will also post on idle-dev for discussion as Terry Reedy requested.

----------
components: IDLE
messages: 185731
nosy: Todd.Rovito, roger.serwy, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Remove config option 'editor on startup' and utilize command line options only
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr  1 14:49:02 2013
From: report at bugs.python.org (Zbigniew Halas)
Date: Mon, 01 Apr 2013 12:49:02 +0000
Subject: [New-bugs-announce] [issue17610] Qsort function misuse in
	typeobject.c
Message-ID: <1364820542.51.0.192116883803.issue17610@psf.upfronthosting.co.za>


New submission from Zbigniew Halas:

Comparison function slotdef_cmp in  Objects/typeobject.c is based on the assumption that qsort may be stabilised by taking memory addresses of compared objects into consideration. This assumption is not guaranteed by the C standard and may not always be true, like for example in the case of qsort implemented as a typical quicksort.
Sometimes it may be even more harmful, as some implementations may be unhappy about comparison function changing its value just because an element was moved to another memory location (I discovered this problem while porting Python to HelenOS, where this comparison function caused qsort to enter infinite recursion).

The actual function:

/* Comparison function for qsort() to compare slotdefs by their offset, and
   for equal offset by their address (to force a stable sort). */
static int
slotdef_cmp(const void *aa, const void *bb)
{
    const slotdef *a = (const slotdef *)aa, *b = (const slotdef *)bb;
    int c = a->offset - b->offset;
    if (c != 0)
        return c;
    else
        /* Cannot use a-b, as this gives off_t,
           which may lose precision when converted to int. */
        return (a > b) ? 1 : (a < b) ? -1 : 0;
}

----------
components: Interpreter Core
messages: 185738
nosy: zhalas
priority: normal
severity: normal
status: open
title: Qsort function misuse in typeobject.c
type: behavior
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/issue17610>
_______________________________________

From report at bugs.python.org  Mon Apr  1 18:31:20 2013
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 01 Apr 2013 16:31:20 +0000
Subject: [New-bugs-announce] [issue17611] Move unwinding of stack for
	"pseudo exceptions" from	interpreter to compiler.
Message-ID: <1364833880.2.0.617388686213.issue17611@psf.upfronthosting.co.za>


New submission from Mark Shannon:

The handling of "pseudo exceptions" (return, break and continue) are currently handled in the interpreter. This make the interpreter loop more complex and slower than it needs to be. This change moves the handling of pseudo exceptions into the compiler. 

The net effects of this patch are:

Simpler interpreter loop: no 'psuedo-exceptions', fewer bytecodes and some simplifed bytecodes.

Eliminate the 'why_code' state variable in the  interpreter. Execution is always in the 'normal' state except during explicit exception handling.

Small increase in size and complexity of compiler.

Speedup of 1.5% (Intel i7); this should be considered a happy side-effect rather than a motivation for the change.

----------
hgrepos: 181
messages: 185741
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

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

From report at bugs.python.org  Tue Apr  2 00:00:55 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 01 Apr 2013 22:00:55 +0000
Subject: [New-bugs-announce] [issue17612] hooks/mail.py requires [smtp] host
	to be set, despite a comment to the contrary
Message-ID: <1364853655.88.0.718145768613.issue17612@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

In the mail hook, there's a comment that says:

'''
To set the SMTP server to something other than localhost, add a [smtp]
section to your hgrc:

[smtp]
host = mail.python.org
port = 25
'''

This is not true. The default host is '', which tells smtplib.SMTP to not make an initial connection. If we want the comment to be correct, then we need to set 'localhost' as the default:

-    host = ui.config('smtp', 'host', '')
+    host = ui.config('smtp', 'host', 'localhost')

I guess there's some chance that we want to force the smtp host to be set. If that's the case then then comment should be changed and the code modified to require the host be specified in the config file (or at least a better error message than 'please run connect() first').

Adding Antoine because annotate points to him for these lines.

----------
assignee: eric.smith
keywords: easy
messages: 185777
nosy: eric.smith, pitrou
priority: normal
severity: normal
status: open
title: hooks/mail.py requires [smtp] host to be set, despite a comment to the contrary

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

From report at bugs.python.org  Tue Apr  2 02:55:15 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Apr 2013 00:55:15 +0000
Subject: [New-bugs-announce] [issue17613] IDLE error
Message-ID: <1364864115.36.0.547026592703.issue17613@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Running ILDE with 2.7.4 RC 1 on Mac OS X 10.8 and with ActiveTCL 8.5.13 using "python -m idlelib.idle", I object the following traceback messages.  I'm unsure what events are triggering it:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 531, in callit
    func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/ColorDelegator.py", line 153, in recolorize
    self.recolorize_main()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/ColorDelegator.py", line 186, in recolorize_main
    next = self.index(mark + "+%d lines linestart" %
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/Delegator.py", line 10, in __getattr__
    attr = getattr(self.delegate, name) # May raise AttributeError
AttributeError: 'NoneType' object has no attribute 'index'

----------
components: IDLE
messages: 185784
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE error
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  2 05:42:40 2013
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 02 Apr 2013 03:42:40 +0000
Subject: [New-bugs-announce] [issue17614] IDLE - quickly closing a large
	file triggers a traceback
Message-ID: <1364874160.69.0.887183749933.issue17614@psf.upfronthosting.co.za>


New submission from Roger Serwy:

Using the bigfile.py generation program from #17613 triggers the following traceback:

Traceback (most recent call last):
  File "/usr/bin/idle", line 5, in <module>
    main()
  File "/usr/lib/python3.3/idlelib/PyShell.py", line 1431, in main
    if flist.open(filename) is None:
  File "/usr/lib/python3.3/idlelib/FileList.py", line 36, in open
    edit = self.EditorWindow(self, filename, key)
  File "/usr/lib/python3.3/idlelib/PyShell.py", line 113, in __init__
    if self.io.filename: self.restore_file_breaks()
  File "/usr/lib/python3.3/idlelib/PyShell.py", line 229, in restore_file_breaks
    filename = self.io.filename
AttributeError: 'NoneType' object has no attribute 'filename'

----------
components: IDLE
messages: 185802
nosy: roger.serwy
priority: critical
severity: normal
status: open
title: IDLE - quickly closing a large file triggers a traceback
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr  2 11:14:23 2013
From: report at bugs.python.org (Neil Hodgson)
Date: Tue, 02 Apr 2013 09:14:23 +0000
Subject: [New-bugs-announce] [issue17615] String comparison performance
	regression
Message-ID: <1364894063.07.0.761589052415.issue17615@psf.upfronthosting.co.za>


New submission from Neil Hodgson:

On Windows, non-equal comparisons (<, <=, >, >=) between strings with common prefixes are slower in Python 3.3 than 3.2. This is for both 32-bit and 64-bit builds. Performance on Linux has not decreased for the same code. The attached program tests comparisons for strings that have common prefixes.

On a 64-bit build, a 25 character string comparison is around 30% slower and a 100 character string averages 85% slower. A user of 32-bit Python builds reported the 25 character case to average 70% slower. 

Here are two runs of the program using 3.2/3.3 on Windows 7 on an i7 870:

>c:\python32\python -u "charwidth.py"
3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)]
a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/z']176
[0.7116295577956576, 0.7055591343157613, 0.7203483026429418]

a=['C:/Users/Neil/Documents/?','C:/Users/Neil/Documents/?']176
[0.7664397841378787, 0.7199902325464409, 0.713719289812504]

a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/?']176
[0.7341851791817691, 0.6994205901833599, 0.7106807593741005]

a=['C:/Users/Neil/Documents/?','C:/Users/Neil/Documents/?']180
[0.7346812372666784, 0.6995411113377914, 0.7064768417728411]

>c:\python33\python -u "charwidth.py"
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)]
a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/z']108
[0.9913326076446045, 0.9455845241056282, 0.9459076605341776]

a=['C:/Users/Neil/Documents/?','C:/Users/Neil/Documents/?']192
[1.0472289217234318, 1.0362342484091207, 1.0197109728048384]

a=['C:/Users/Neil/Documents/b','C:/Users/Neil/Documents/?']192
[1.0439643704533834, 0.9878581050301687, 0.9949265834034335]

a=['C:/Users/Neil/Documents/?','C:/Users/Neil/Documents/?']312
[1.0987483965446412, 1.0130257167690004, 1.024832248526499]

----------
components: Unicode
files: charwidth.py
messages: 185824
nosy: Neil.Hodgson, ezio.melotti
priority: normal
severity: normal
status: open
title: String comparison performance regression
versions: Python 3.3
Added file: http://bugs.python.org/file29652/charwidth.py

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

From report at bugs.python.org  Tue Apr  2 11:16:06 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 02 Apr 2013 09:16:06 +0000
Subject: [New-bugs-announce] [issue17616] wave.Wave_read and wave.Wave_write
	can be context	managers
Message-ID: <1364894166.78.0.454807000252.issue17616@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

I think that wave.open should work with the `with` statement, given the fact that Lib/aifc.py does this. I attached a simple patch for this. Thanks in advance.

----------
components: Library (Lib)
files: wave_context_manager.patch
keywords: patch
messages: 185825
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: wave.Wave_read and wave.Wave_write can be context managers
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29653/wave_context_manager.patch

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

From report at bugs.python.org  Tue Apr  2 14:40:51 2013
From: report at bugs.python.org (bonnet)
Date: Tue, 02 Apr 2013 12:40:51 +0000
Subject: [New-bugs-announce] [issue17617] struct.calcsize() incorrect
Message-ID: <1364906451.57.0.179854550538.issue17617@psf.upfronthosting.co.za>


New submission from bonnet:

struct.calcsize('iiiii?') : 21

appears to be incorrect ; in C sizeof : 24

C code:
typedef struct {
  int	param1;
  int	param2;
  int	param3;
  int	param4;
  int	param5;
  unsigned char param6;
} struct_titi6;

main:
struct_titi6 toto3;
printf("taille toto3 : %d\n",sizeof(toto3));
printf("taille toto3.param1 : %d\n",sizeof(toto3.param1));
printf("taille toto3.param6 : %d\n",sizeof(toto3.param6));

results:
taille toto3 : 24
taille toto3.param1 : 4
taille toto3.param6 : 1

----------
components: Library (Lib)
messages: 185834
nosy: boa124
priority: normal
severity: normal
status: open
title: struct.calcsize() incorrect
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr  2 15:23:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Apr 2013 13:23:35 +0000
Subject: [New-bugs-announce] [issue17618] base85 encoding
Message-ID: <1364909015.82.0.0760723886219.issue17618@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Base85 encoding (see e.g. http://en.wikipedia.org/wiki/Ascii85 ) allows a tighter encoding than Base64: it has a 5/4 expansion ratio, rather than 4/3.
It is used in Mercurial, git, and there's another variant that's used by Adobe in the PDF format.

It would be nice to have a Base85 implementation in either the binascii or base64 modules.

(unfortunately the Mercurial implementation is GPL'ed, although if we want to copy it we might simply ask them for a relicensing)

----------
components: Library (Lib)
messages: 185835
nosy: christian.heimes, pitrou
priority: normal
severity: normal
status: open
title: base85 encoding
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr  2 18:35:51 2013
From: report at bugs.python.org (Drekin)
Date: Tue, 02 Apr 2013 16:35:51 +0000
Subject: [New-bugs-announce] [issue17619] input() swallows KeyboardInterrupt
	in Python 3.3
Message-ID: <1364920551.51.0.354757016043.issue17619@psf.upfronthosting.co.za>


New submission from Drekin:

At least on Windows, input() doesn't raise KeyboardInterrupt when Ctrl-C is hit in Python 3.3 (it does in Python 3.2).

3.3:
>>> x = input() # Ctrl-C hit - no exception raised
>>> x
NameError

3.2:
>>> x = input() # Ctrl-C hit
KeyboardInterrupt

----------
messages: 185845
nosy: Drekin
priority: normal
severity: normal
status: open
title: input() swallows KeyboardInterrupt in Python 3.3
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  2 18:59:14 2013
From: report at bugs.python.org (Drekin)
Date: Tue, 02 Apr 2013 16:59:14 +0000
Subject: [New-bugs-announce] [issue17620] Python interactive console doesn't
	use sys.stdin for	input
Message-ID: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za>


New submission from Drekin:

The Python interactive console actually doesn't use sys.stdin but standard C stdin for input. Is there any reason for this? Why it then uses its encoding attribute? (Assigning sys.stdin something, that doesn't have encoding attribute freezes the interpreter.) If anything, wouldn't it make more sense if it used sys.__stdin__.encoding instead of sys.stdin? sys.stdin is intended to be set by user (it affects input() and code.inpterrupt() which tries to minic standard interactive console).

----------
messages: 185848
nosy: Drekin
priority: normal
severity: normal
status: open
title: Python interactive console doesn't use sys.stdin for input
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr  2 20:00:47 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Apr 2013 18:00:47 +0000
Subject: [New-bugs-announce] [issue17621] Create a lazy import loader mixin
Message-ID: <1364925647.64.0.233663837419.issue17621@psf.upfronthosting.co.za>


New submission from Brett Cannon:

People keep asking and I keep promising to get a lazy loader into Python 3.4. This issue is for me to track what I have done towards meeting that promise.

To start, I have something working at https://code.google.com/p/importers/, but I need to make sure that the code copies any newly assigned objects post-import but before completing an attribute read::

  import lazy_mod
  lazy_mod.attr = True  # Does not have to trigger import, although there is nothing wrong if it did.
  lazy_mod.func()  # Since it might depend on 'attr', don't return attr until after import and 'attr' with a value of True has been set.

Also need to see if anything can be done about isinstance/issubclass checks as super() is used for assigning to __loader__ and thus might break checks for ABCs. Maybe create a class from scratch w/o the mixin somehow (which I don't see from looking at http://docs.python.org/3.4/library/types.html#module-types w/o re-initializing everything)? Somehow get __subclasscheck__() on the super() class? Some other crazy solution that avoids having to call __init__() a second time?

----------
assignee: brett.cannon
components: Library (Lib)
messages: 185852
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Create a lazy import loader mixin
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr  3 09:23:29 2013
From: report at bugs.python.org (Yuri)
Date: Wed, 03 Apr 2013 07:23:29 +0000
Subject: [New-bugs-announce] [issue17622] Python sets wrong pid in window
	properties
Message-ID: <1364973809.38.0.992357465661.issue17622@psf.upfronthosting.co.za>


New submission from Yuri:

When I click on "Close Window" button for the unresponsive python-based app 'meld', message from window manager shows up offering to kill the non-existent pid. It looks like python libs set wrong pid for windows when python multithreading is in use by this app.

Here are my original PRs with detailed description for kde4 and meld:
https://bugs.kde.org/show_bug.cgi?id=317750
https://bugzilla.gnome.org/show_bug.cgi?id=697143

----------
components: Library (Lib)
messages: 185896
nosy: yurivict
priority: normal
severity: normal
status: open
title: Python sets wrong pid in window properties
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  3 11:22:47 2013
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 03 Apr 2013 09:22:47 +0000
Subject: [New-bugs-announce] [issue17623] Typo in Doc/whatsnew/3.3.rst
Message-ID: <1364980967.1.0.766058009466.issue17623@psf.upfronthosting.co.za>


New submission from Thomas Heller:

Typo:  trucate instead of truncate

----------
assignee: docs at python
components: Documentation
files: work.patch
keywords: patch
messages: 185901
nosy: docs at python, theller
priority: normal
severity: normal
status: open
title: Typo in Doc/whatsnew/3.3.rst
Added file: http://bugs.python.org/file29664/work.patch

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

From report at bugs.python.org  Wed Apr  3 12:45:05 2013
From: report at bugs.python.org (Stefan Bucur)
Date: Wed, 03 Apr 2013 10:45:05 +0000
Subject: [New-bugs-announce] [issue17624] Confusing TypeError in
	urllib.urlopen
Message-ID: <1364985905.97.0.615690774313.issue17624@psf.upfronthosting.co.za>


New submission from Stefan Bucur:

When calling urllib.urlopen with a string containing the NULL ('\x00') character, a TypeError exception is thrown, as in the following example:

urllib.urlopen('\x00\x00\x00')

[...]
  File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 86, in urlopen
    return opener.open(url)
  File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 207, in open
    return getattr(self, name)(url)
  File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 462, in open_file
    return self.open_local_file(url)
  File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 474, in open_local_file
    stats = os.stat(localname)
TypeError: must be encoded string without NULL bytes, not str


This exception is confusing, since apparently the right type (a string) is passed to the function.  Since this behavior cannot change, it would be good to mention this exception in the function documentation.

I can imagine code that composes a URL based on user-supplied input and passes it to urlopen crashing if it doesn't properly sanitize the URL and/or doesn't catch TypeError.

----------
components: Library (Lib)
messages: 185913
nosy: Stefan.Bucur
priority: normal
severity: normal
status: open
title: Confusing TypeError in urllib.urlopen
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  3 13:27:24 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Apr 2013 11:27:24 +0000
Subject: [New-bugs-announce] [issue17625] IDLE regression -- Search and
	Replace Window doesn't	automatically clear
Message-ID: <1364988444.15.0.220238239818.issue17625@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

In an editor window, select Edit-Replace and click ReplaceAll.  The dialog window stays open.   Formerly, it cleared immediately which was useful.  The new behavior is confusing and less useful.

----------
assignee: roger.serwy
components: IDLE
messages: 185917
nosy: rhettinger, roger.serwy
priority: normal
severity: normal
status: open
title: IDLE regression -- Search and Replace Window doesn't automatically clear
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  3 19:34:58 2013
From: report at bugs.python.org (Roy Wellington)
Date: Wed, 03 Apr 2013 17:34:58 +0000
Subject: [New-bugs-announce] [issue17626] set's __isub__ doesn't support
	non-sets.
Message-ID: <1365010498.59.0.57626371366.issue17626@psf.upfronthosting.co.za>


New submission from Roy Wellington:

The following:

s = set(range(10))

s -= (1, 2, 3)

raises a TypeError. Yet the following, which is more verbose and equivalent, succeeds:

s.difference_update((1, 2, 3))

Under the hood, __isub__ calls difference_update to do its work. Unfortunately, __isub__ explicitly checks that the parameter is a set, even though difference_update can handle more than just sets. Could set.__isub__ just pass along the tuple to difference update, allowing __isub__ to operate on any iterable?

For the purposes of "remove these elements from this set", any iterable works just as well as any other. It should O(number of elements to remove) in time (for sets, tuples, lists, etc.) and constant in memory, aside from the memory required for the parameters themselves.

----------
messages: 185941
nosy: Roy.Wellington
priority: normal
severity: normal
status: open
title: set's __isub__ doesn't support non-sets.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Apr  3 20:39:11 2013
From: report at bugs.python.org (CM)
Date: Wed, 03 Apr 2013 18:39:11 +0000
Subject: [New-bugs-announce] [issue17627] Datetime and time doesn't update
	timezone in a running	Win app
Message-ID: <1365014351.49.0.143463684024.issue17627@psf.upfronthosting.co.za>


New submission from CM:

On Windows (tested on XP), the datetime module (and, as reported online in [1], time module) apparently gets the timezone only when a Python instance first starts, but then never updates the timezone during the life of that Python instance.  So, if the user changes the system time zone while an application is running, datetime still uses the time zone that the Python instance started with, and so it is incorrect.

Example, Python 2.7.3:

First, the system time zone is set to Eastern U.S. and the system time shows 14:27.

>>> import datetime
>>> print datetime.datetime.now()
2013-04-03 14:27:43.124000

This is correct, and matches the system clock.

Now user changes time zone on Windows to GMT (and doesn't change the time).  Clock now shows the time as 18:29.

>>> print datetime.datetime.now()
2013-04-03 14:29:02.875000
            ^
This is incorrect and doesn't match the time shown on the system clock.

Note:  if the user changes the system clock time and NOT the time zone, then datetime updates the time fine.  

This has been discussed in a Stack Overflow question, with a proposed workaround[1], but it doesn't fix the fact that this makes datetime incorrect for those that have processes that ought to continue across time zone changes as the user moves.

[1]See accepted answer in particular here:  http://stackoverflow.com/questions/4360981/make-python-respond-to-windows-timezone-changes

----------
components: Library (Lib)
messages: 185943
nosy: cm
priority: normal
severity: normal
status: open
title: Datetime and time doesn't update timezone in a running Win app
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr  3 23:29:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 03 Apr 2013 21:29:12 +0000
Subject: [New-bugs-announce] [issue17628] str==str: compare the first and
	last character before	calling memcmp()
Message-ID: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3.4, str==str is implemented by calling memcmp().

unicode_eq() function, used by dict and set types, checks the first byte before calling memcmp(). bytes==bytes uses the same check.

Py_UNICODE_MATCH macro checks the first *and* last character before calling memcmp() since this commit:
---
changeset:   38242:0de9a789de39
branch:      legacy-trunk
user:        Fredrik Lundh <fredrik at pythonware.com>
date:        Tue May 23 10:10:57 2006 +0000
files:       Include/unicodeobject.h
description:
needforspeed: check first *and* last character before doing a full memcmp
---

Attached patch changes str==str to check the first and last character before calling memcmp(). It might reduce the overhead of a C function call, but it is much faster when comparing two different strings of the same length with a common prefix (but a different suffix).

The patch merges also unicode_compare_eq() and unicode_eq() to use the same code for str, dict and set.

We may use the same optimization on byte strings.

See also #16321.

----------
files: unicode_eq.patch
keywords: patch
messages: 185956
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: str==str: compare the first and last character before calling memcmp()
versions: Python 3.4
Added file: http://bugs.python.org/file29668/unicode_eq.patch

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

From report at bugs.python.org  Wed Apr  3 23:54:31 2013
From: report at bugs.python.org (Chris Angelico)
Date: Wed, 03 Apr 2013 21:54:31 +0000
Subject: [New-bugs-announce] [issue17629] Expose string width to Python
Message-ID: <1365026071.28.0.865581650366.issue17629@psf.upfronthosting.co.za>


New submission from Chris Angelico:

As of PEP 393, a string's width is recorded in its header - effectively, a marker that says whether the highest codepoint in the string is >0xFFFF, >0xFF, or <=0xFF. This is, on some occasions, useful to know; for instance, when testing string performance, it's handy to be able to very quickly throw something down that, without scanning the contents of all the strings used, can identify the width spread.

A similar facility is provided by Pike, which has a similar flexible string representation: http://pike.lysator.liu.se/generated/manual/modref/ex/7.2_3A_3A/String/width.html accessible to a script as String.width().

Since this is not something frequently needed, it would make sense to hide it away in the sys or inspect modules, or possibly in strings or as a method on the string itself.

Currently, the best way to do this is something like:

def str_width(s):
  width=1
  for ch in map(ord,s):
    if n > 0xFFFF: return 4
    if n > 0xFF: width=2
  return width

which necessitates a scan of the entire string, unless it has an astral character.

----------
components: Library (Lib)
messages: 185963
nosy: Rosuav
priority: normal
severity: normal
status: open
title: Expose string width to Python
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Apr  4 00:05:56 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Apr 2013 22:05:56 +0000
Subject: [New-bugs-announce] [issue17630] Create a pure Python zipfile
	importer
Message-ID: <1365026756.4.0.0705755124355.issue17630@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I'm going to write an importer using zipfile and importlib in pure Python. I'm doing this so that (a) there is an importer that relies on zipfile and thus what features it adds over time, (b) to have good example code to point people to when they need to implement their own importers, and (c) for me to see where there are API holes in importlib and the ABCs in order to continue to try and make things easier for people.

Do realize that the last point means I will most likely be writing this myself no matter what people contribute (sorry). If people still want to tackle it to provide feedback on what importlib is lacking that's totally fine and welcome feedback, but since this is partially an exercise for myself I feel like I do need to type it all out from scratch to discover sticking points, even from an experienced perspective. But I'm happy to discuss design choices, etc. here with folks as this progresses.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 185967
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Create a pure Python zipfile importer
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr  4 01:13:59 2013
From: report at bugs.python.org (Alexey Spiridonov)
Date: Wed, 03 Apr 2013 23:13:59 +0000
Subject: [New-bugs-announce] [issue17631] inspect getsource does not display
	full text of lambda
Message-ID: <1365030839.21.0.0882950227622.issue17631@psf.upfronthosting.co.za>


New submission from Alexey Spiridonov:

This happens because the block search algorithm seems not to be handling lambda arguments correctly.

$ cat x.py
import inspect

def a(y):
    print inspect.getsource(y)
    print inspect.getsourcelines(y)
    
a(
    lambda x:
        x * 
        3
)

$ python x.py
    lambda x:

(['    lambda x:\n'], 8)

----------
components: Library (Lib)
messages: 185975
nosy: Alexey.Spiridonov
priority: normal
severity: normal
status: open
title: inspect getsource does not display full text of lambda
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Apr  4 07:59:59 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Apr 2013 05:59:59 +0000
Subject: [New-bugs-announce] [issue17632] IDLE: Add clear-window option to
	the Shell menu.
Message-ID: <1365055199.08.0.309826591604.issue17632@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Without a restart-and-clear option, the shell window tends to grow without bound, becoming increasingly lethargic along the way.

I've have recurring student requests for this minor feature.

----------
components: IDLE
keywords: easy
messages: 186004
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE:  Add clear-window option to the Shell menu.
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr  4 12:10:23 2013
From: report at bugs.python.org (Phil Connell)
Date: Thu, 04 Apr 2013 10:10:23 +0000
Subject: [New-bugs-announce] [issue17633] zipimport's handling of namespace
	packages is incorrect
Message-ID: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za>


New submission from Phil Connell:

Only one level of namespace package nesting is handled correctly:

$ unzip -l foo.zip
Archive:  foo.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2013-04-03 17:28   a/b/c/foo.py
        0  2013-04-03 17:34   a/
        0  2013-04-03 17:34   a/b/
        0  2013-04-03 17:34   a/b/c/
---------                     -------
        0                     4 files
$ ls
foo.zip
$ PYTHONPATH=foo.zip ~/dev/cpython/python
Python 3.4.0a0 (default:3b1dbe7a2aa0+, Apr  3 2013, 17:31:54) 
[GCC 4.8.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import a
>>> import a.b
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'a.b'
>>>


The problem appears to be that check_is_directory constructs the wrong directory path (it should be 'a/b'):

check_is_directory (self=0x7ffff6d3dc88, prefix='a/', path='a.b')
    at ./Modules/zipimport.c:280
280     dirpath = PyUnicode_FromFormat("%U%U%c", prefix, path, SEP);
(gdb) n
281     if (dirpath == NULL)
(gdb) p dirpath
$11 = 'a/a.b/'


I've attached a tentative initial patch that appears to fix the issue, although it probably needs some more thought (and definitely some more testing - the existing tests still pass though).

----------
components: Extension Modules
files: zipimport_ns.diff
keywords: patch
messages: 186025
nosy: brett.cannon, eric.snow, ncoghlan, pconnell
priority: normal
severity: normal
status: open
title: zipimport's handling of namespace packages is incorrect
versions: Python 3.4
Added file: http://bugs.python.org/file29679/zipimport_ns.diff

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

From report at bugs.python.org  Thu Apr  4 18:23:18 2013
From: report at bugs.python.org (Andrej Krpic)
Date: Thu, 04 Apr 2013 16:23:18 +0000
Subject: [New-bugs-announce] [issue17634] Win32: shutil.copy leaks file
	handles to child processes
Message-ID: <1365092598.25.0.167628873092.issue17634@psf.upfronthosting.co.za>


New submission from Andrej Krpic:

Function shutil.copy opens source file with open('rb') and destination file with open('wb') and then proceeds to copy the content.

If you create child process from the same python process during that time, that process will inherit open file handles.

This could lead to situation when parent process tries to delete the file, but child process prevents that by holding an open handle to the file (Windows XP, Windows 7).
 
This is not expected side effect for copy file operation.
Win32's native CopyFile API call doesn't leak file handles to child processes.

Python's open function behavior is defined by platform's implementation, which translates C function fopen with 'rb' and 'wb' modes to CRT open call without O_NOINHERIT flag, which creates inheritable Win32 HANDLEs.

Possible fix would be to add 'N' to mode string in calls to open function in shutil.copy.

----------
components: Library (Lib), Windows
messages: 186041
nosy: akrpic77
priority: normal
severity: normal
status: open
title: Win32: shutil.copy leaks file handles to child processes
type: security
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/issue17634>
_______________________________________

From report at bugs.python.org  Thu Apr  4 18:43:53 2013
From: report at bugs.python.org (Antony Lee)
Date: Thu, 04 Apr 2013 16:43:53 +0000
Subject: [New-bugs-announce] [issue17635] Doc of multiprocessing.connection
	mentions	answerChallenge instead of answer_challenge
Message-ID: <1365093833.89.0.404146948486.issue17635@psf.upfronthosting.co.za>


New submission from Antony Lee:

The documentation for multiprocessing.connection mentions the answerChallenge function, but it is actually called answer_challenge in 2.6, 2.7 and 3.3 -- I guess it's also the case in 3.1 and 3.2 but I didn't check.

----------
assignee: docs at python
components: Documentation
messages: 186043
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Doc of multiprocessing.connection mentions answerChallenge instead of answer_challenge
versions: Python 2.6, Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Apr  5 03:15:02 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Apr 2013 01:15:02 +0000
Subject: [New-bugs-announce] [issue17636] Modify IMPORT_FROM to fallback on
	sys.modules
Message-ID: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za>


New submission from Brett Cannon:

To help with circular imports, IMPORT_FROM should be modified to check sys.modules if a getattr() check fails.

http://mail.python.org/pipermail/python-dev/2013-April/125123.html

----------
components: Interpreter Core
messages: 186059
nosy: brett.cannon, pje
priority: normal
severity: normal
stage: test needed
status: open
title: Modify IMPORT_FROM to fallback on sys.modules
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr  5 03:17:16 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 05 Apr 2013 01:17:16 +0000
Subject: [New-bugs-announce] [issue17637] Mention "What's New" in devguide's
	patch guidelines
Message-ID: <1365124636.23.0.37694009358.issue17637@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://docs.python.org/devguide/patch.html should mention that What's New should also be considered for updating if a change is either significant or requires potential modification of existing code.

----------
components: Devguide
messages: 186060
nosy: brett.cannon, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Mention "What's New" in devguide's patch guidelines

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

From report at bugs.python.org  Fri Apr  5 09:44:40 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 05 Apr 2013 07:44:40 +0000
Subject: [New-bugs-announce] [issue17638] test_ssl failure
Message-ID: <1365147880.88.0.698550208243.issue17638@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

test_ssl is failing on one the NetBSD buildbots:
http://buildbot.python.org/all/builders/x86%20NetBSD%205.1.2%20%5BSB%5D%203.x/builds/1129/steps/test/logs/stdio

"""
======================================================================
ERROR: test_options (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_ssl.py", line 87, in f
    return func(*args, **kwargs)
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_ssl.py", line 420, in test_options
    ctx.options = (ctx.options & ~ssl.OP_NO_SSLv2) | ssl.OP_NO_TLSv1
ValueError: can't clear options before OpenSSL 0.9.8m
"""

Antoine, I think I saw commits from you some time ago to deal with this SSL version thing...

----------
components: Tests
keywords: buildbot
messages: 186066
nosy: neologix, pitrou
priority: normal
severity: normal
status: open
title: test_ssl failure
type: behavior

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

From report at bugs.python.org  Fri Apr  5 11:29:06 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 05 Apr 2013 09:29:06 +0000
Subject: [New-bugs-announce] [issue17639] symlinking .py files creates
	unexpected sys.path[0]
Message-ID: <1365154146.05.0.401345898234.issue17639@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

When .py files are assembled into a directory structure using direct symbolic links to the files, something odd happens to sys.path[0].

Consider this file structure:
/pystuff/
  foo.py -> /scripts/foo.py
  bar.py -> /libs/bar.py

foo.py contains the line: "import bar"
"python /pystuff/foo.py" will now fail, because when foo.py is run, sys.path[0] will contain "/scripts", rather than the expected "/pystuff".

It would appear that the algorithm for finding sys.path[0] is:
sys.path[0] = os.dirname(os.realpath(filename)).
IMO, it should be:
sys.path[0] = os.realpath(os.dirname(filename)).

I say that this behaviour is unexpected, because symlinking to individual files normally has the semantics of "pulling that file in" rather than "hopping to that file's real dir".

As an example, the following works C, and other languages too, I should imagine:
/code/
  myfile.c -> /sources/myfile.c
  mylib.h  -> /libs/mylib.h
  libmylib.so -> /libs/libmylib.so

an "#include "mylib.h" in myfile.c would look for the file in /code and find it.
a "cc myfile.c -lmylib" would find the libmylib.so in /code

This problem was observed on linux, when running hadoop script jobs.  The hadoop code (cloudera CDH4) creates a symlink copy of your file structure, where each file is individually symlinked to an place in a file cache, where each file may sit in a different physical dir, like this:

tmp1/
 a.py -> /secret/filecache/0001/a.py
 b.py -> /secret/filecache/0002/b.py
 c.py -> /secret/filecache/0003/c.py

Suddenly, importing b and c from a.py won't work.
if a, b, and c were .h files, then "#include "b.h"" from a.h would work.

----------
components: Interpreter Core, Library (Lib)
messages: 186069
nosy: kristjan.jonsson, ncoghlan, neologix
priority: normal
severity: normal
status: open
title: symlinking .py files creates unexpected sys.path[0]
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Apr  5 16:31:26 2013
From: report at bugs.python.org (Dmitry Sivachenko)
Date: Fri, 05 Apr 2013 14:31:26 +0000
Subject: [New-bugs-announce] [issue17640] from distutils.util import
	byte_compile hangs
Message-ID: <1365172286.35.0.207252264643.issue17640@psf.upfronthosting.co.za>


New submission from Dmitry Sivachenko:

The following problem exists in python3.3.0 and python3.3.1rc1.

>From the command line it works:

root at dhcp175-40-red:~ # python3
Python 3.3.1rc1 (default, Apr  5 2013, 18:03:56) 
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd10
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.util import byte_compile
>>> 


>From script it hangs:
root at dhcp175-40-red:~ # cat /tmp/comp.py 
from distutils.util import byte_compile
files = [
'/usr/local/lib/python3.3/site-packages/yaml/__init__.py',]

byte_compile(files, optimize=1, force=None,
             prefix=None, base_dir=None,
             verbose=1, dry_run=0,
             direct=1)

# python3 /tmp/comp.py
--> Now it hangs forever, if I press Ctrl+D, I get:
Traceback (most recent call last):
  File "/tmp/comp.py", line 1, in <module>
    from distutils.util import byte_compile
  File "/usr/local/lib/python3.3/distutils/util.py", line 9, in <module>
    import imp
  File "/usr/local/lib/python3.3/imp.py", line 28, in <module>
    import tokenize
  File "/usr/local/lib/python3.3/tokenize.py", line 37, in <module>
    __all__ = token.__all__ + ["COMMENT", "tokenize", "detect_encoding",
AttributeError: 'module' object has no attribute '__all__'

----------
assignee: eric.araujo
components: Distutils
messages: 186084
nosy: Dmitry.Sivachenko, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: from distutils.util import byte_compile hangs
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr  5 19:54:41 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 05 Apr 2013 17:54:41 +0000
Subject: [New-bugs-announce] [issue17641] ssl module doc unification
Message-ID: <1365184481.29.0.784588958426.issue17641@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

I noticed 2.X version of ssl module doc does not mention different socket methods (sendall(), accept(), etc) whereas the 3.X version does.
Patch in attachment unifies the 2 docs.

----------
assignee: docs at python
components: Documentation
keywords: easy, needs review
messages: 186097
nosy: docs at python, ezio.melotti, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: ssl module doc unification
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr  6 08:06:25 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Apr 2013 06:06:25 +0000
Subject: [New-bugs-announce] [issue17642] IDLE add font resizing hot keys
Message-ID: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Add the standard hot keys for resizing fonts (i.e. on a Mac, CMD-plus and CMD-minus).

----------
components: IDLE
keywords: easy
messages: 186118
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE add font resizing hot keys
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr  6 14:54:57 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Apr 2013 12:54:57 +0000
Subject: [New-bugs-announce] [issue17643] Expose weakref callback for
	introspection purposes.
Message-ID: <1365252897.75.0.384188042072.issue17643@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

It would be nice to be able to access the callback of a weakref as an attribute on the weakref itself.  For example:

Python 3.4.0a0 (default:2bf154ca43c6+, Apr  6 2013, 13:31:29) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import weakref
>>> x = {1, 2, 3}
>>> ref = weakref.ref(x, lambda ref: print("done"))
>>> ref.__callback__
<function <lambda> at 0x1004f56d0>
>>> del x
done
>>> ref.__callback__  # Returns None

I encountered this while writing a tool to show graphs of Python objects and their references to each other:  I wanted to be able to annotate each edge of the graph.  For something like a function, it's easy to use introspection to compare the reference target with f.__code__, f.__annotations__, etc.  For a weakref, I couldn't find an easy way to retrieve the callback (or even determine whether there *was* a callback associated to the weakref).  One can do a "gc.get_referents" call and hope that if there's exactly one object returned it's the callback, but that won't work so well with weakref.ref subclasses.

Patch attached:  it has tests but no doc updates as yet.

----------
components: Interpreter Core
files: weakref___callback__.patch
keywords: patch
messages: 186122
nosy: mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Expose weakref callback for introspection purposes.
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29685/weakref___callback__.patch

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

From report at bugs.python.org  Sat Apr  6 16:46:26 2013
From: report at bugs.python.org (Anton Poldnev)
Date: Sat, 06 Apr 2013 14:46:26 +0000
Subject: [New-bugs-announce] [issue17644] str.format() crashes
Message-ID: <1365259586.34.0.498934812452.issue17644@psf.upfronthosting.co.za>


New submission from Anton Poldnev:

Windows interpreter immediately crashes on this command:
>>> "{[{}]}".format({"{}": 5})

----------
messages: 186130
nosy: poldnev
priority: normal
severity: normal
status: open
title: str.format() crashes
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr  6 17:37:03 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 06 Apr 2013 15:37:03 +0000
Subject: [New-bugs-announce] [issue17645] assert fails in _Py_Mangle
Message-ID: <1365262623.27.0.317962100513.issue17645@psf.upfronthosting.co.za>


New submission from Armin Rigo:

Run this example on a 32-bit machine with more than 2GB of addressable RAM (e.g. by default, more or less anything but Windows).

On Python 2.7 it raises "SystemError: Negative size passed to PyString_FromStringAndSize".  On a debug version, it causes an assert in _Py_Mangle() to trigger.

----------
files: mem2.py
messages: 186135
nosy: arigo
priority: normal
severity: normal
status: open
title: assert fails in _Py_Mangle
versions: Python 2.7
Added file: http://bugs.python.org/file29688/mem2.py

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

From report at bugs.python.org  Sat Apr  6 19:23:44 2013
From: report at bugs.python.org (Martin Morrison)
Date: Sat, 06 Apr 2013 17:23:44 +0000
Subject: [New-bugs-announce] [issue17646] traceback.py has a lot of code
	duplication
Message-ID: <1365269024.35.0.461360708932.issue17646@psf.upfronthosting.co.za>


New submission from Martin Morrison:

traceback.py contains a lot of code duplication, which makes it fragile in the face of changes (i.e. special cases) to the stack/traceback output (I am separately working on just such a change).

The attached patch refactors the code to reduce to a single function for each bit of logic, wrapped by the various existing APIs. The new helper functions are refactored as generators so as not to create unnecessary transient lists (not that stacks usually get very big anyway).

I've fully tested the replacement module, and it passes all the traceback tests in the standard suite.

----------
components: Library (Lib)
files: traceback.diff
keywords: patch
messages: 186142
nosy: isoschiz
priority: normal
severity: normal
status: open
title: traceback.py has a lot of code duplication
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29692/traceback.diff

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

From report at bugs.python.org  Sat Apr  6 23:19:39 2013
From: report at bugs.python.org (Caitlin Potter)
Date: Sat, 06 Apr 2013 21:19:39 +0000
Subject: [New-bugs-announce] [issue17647] subprocess.communicate() should
	preserve colored output	on Windows
Message-ID: <1365283179.61.0.145925901601.issue17647@psf.upfronthosting.co.za>


New submission from Caitlin Potter:

In migrating from GNU autoconf/automake build systems to a python-based build system (Waf), I've been slightly annoyed that coloured text output from unit test programs is lost on the windows platform (the gtest framework uses ::SetConsoleTextAttribute on windows)

Ideally, the coloured output from the test sets would be preserved so that problems could be easily identified and stand out (See attached image for demonstration of problem)

This might be scoffed at as a minor problem because nobody uses SetConsoleTextAttribute anyways, and even if they do it would only affect the windows platform. But just the same, preserving coloured output on windows should be doable.

I'd be happy to work on a patch for this myself, but I'm new to the python tree and am not completely sure where to find what I'm looking for. I think an if mswindows: clause wherever stdout.read() is would probably work, but I'm not sure where that would be.

----------
components: IO, Windows
files: unit-tests.png
messages: 186168
nosy: Caitlin.Potter
priority: normal
severity: normal
status: open
title: subprocess.communicate() should preserve colored output on Windows
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29699/unit-tests.png

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

From report at bugs.python.org  Sun Apr  7 01:45:14 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Apr 2013 23:45:14 +0000
Subject: [New-bugs-announce] [issue17648] test_urllib2 convert doctests to
	unittest
Message-ID: <1365291914.89.0.625576108544.issue17648@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

Sometime back during an IRC conversation we realized that converting test_urllib2 doctests to proper unittest may help in various ways. 
a) Improve coverage report (?) Know what is covered and not.
b) Helps expand it further when new features are added.

Here is patch which removes the old doctests and converts them to unittest.

Reviews will be helpful.

----------
assignee: orsenthil
files: remove_doctests.patch
keywords: patch
messages: 186171
nosy: eric.araujo, ezio.melotti, orsenthil, r.david.murray
priority: normal
severity: normal
status: open
title: test_urllib2 convert doctests to unittest
versions: Python 3.4
Added file: http://bugs.python.org/file29700/remove_doctests.patch

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

From report at bugs.python.org  Sun Apr  7 03:46:48 2013
From: report at bugs.python.org (pfg)
Date: Sun, 07 Apr 2013 01:46:48 +0000
Subject: [New-bugs-announce] [issue17649] Python/Python-ast.c: No such file
	or directory
Message-ID: <1365299208.3.0.0356664357916.issue17649@psf.upfronthosting.co.za>


New submission from pfg:

This happens when I run configure for python 2.7.2 on FreeBSD
...
cc -c -fno-strict-aliasing -O2 -fno-strict-aliasing -pipe -march=nocona  -DNDEBUG -O2 -fno-strict-aliasing -pipe -march=nocona  -I. -IInclude -I./../Include -fPIC -DPy_BUILD_CORE -o Python/Python-ast.o Python/Python-ast.c
cc: Python/Python-ast.c: No such file or directory
cc: No input files specified
*** [Python/Python-ast.o] Error code 1

Stop in /usr/ports/lang/python27/work/Python-2.7.4/portbld.shared.

----------
messages: 186176
nosy: pfg
priority: normal
severity: normal
status: open
title: Python/Python-ast.c: No such file or directory
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr  7 12:08:13 2013
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDRltC5INCi0LjRhdC+0L3QvtCy?=)
Date: Sun, 07 Apr 2013 10:08:13 +0000
Subject: [New-bugs-announce] [issue17650] There is no exception correspond
	to errno EROFS
Message-ID: <1365329293.45.0.99632836105.issue17650@psf.upfronthosting.co.za>


New submission from ?????? ???????:

I found errno.EROFS in Lib/mailbox.py but didn't find exception  correspond to this errno. Is it need to be created?

----------
messages: 186185
nosy: pitrou, ??????.???????
priority: normal
severity: normal
status: open
title: There is no exception correspond to errno EROFS

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

From report at bugs.python.org  Sun Apr  7 15:42:24 2013
From: report at bugs.python.org (Andrey Tykhonov)
Date: Sun, 07 Apr 2013 13:42:24 +0000
Subject: [New-bugs-announce] [issue17651] Errno checking replaced by
	concrete classes inherited	from OSError
Message-ID: <1365342144.92.0.760776925333.issue17651@psf.upfronthosting.co.za>


Changes by Andrey Tykhonov <atykhonov at gmail.com>:


----------
components: Library (Lib)
nosy: asvetlov, atykhonov
priority: normal
severity: normal
status: open
title: Errno checking replaced by concrete classes inherited from OSError
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr  7 18:47:16 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 07 Apr 2013 16:47:16 +0000
Subject: [New-bugs-announce] [issue17652] Add skip_on_windows decorator to
	test.support
Message-ID: <1365353236.0.0.311562843433.issue17652@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I saw a conversation about adding a @skip_on_windows decorator on #python-dev a couple of months ago.

Attached a patch with a documentation update.

(Added the participants of the conversation to nosy list.)

----------
components: Tests
files: skip_on_windows.diff
keywords: patch
messages: 186226
nosy: berker.peksag, ezio.melotti, r.david.murray
priority: normal
severity: normal
status: open
title: Add skip_on_windows decorator to test.support
versions: Python 3.4
Added file: http://bugs.python.org/file29718/skip_on_windows.diff

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

From report at bugs.python.org  Sun Apr  7 22:43:57 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 07 Apr 2013 20:43:57 +0000
Subject: [New-bugs-announce] [issue17653] fix typo in socketserver.rst
Message-ID: <1365367437.59.0.735275083965.issue17653@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: fix.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: fix typo in socketserver.rst
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29719/fix.diff

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

From report at bugs.python.org  Mon Apr  8 02:14:56 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 08 Apr 2013 00:14:56 +0000
Subject: [New-bugs-announce] [issue17654] IDLE: Right click menu not working
	on OS X
Message-ID: <1365380096.1.0.0254781694905.issue17654@psf.upfronthosting.co.za>


New submission from Todd Rovito:

IDLE's new right click menu doesn't seem to be working on Mac OS X.  I am running OS X 10.8.3 with TK version 8.5.9 (which I think is what OS X 10.8.3 ships with). The right click activation I am trying is control-click.

----------
components: IDLE
messages: 186257
nosy: Todd.Rovito, ned.deily, roger.serwy
priority: normal
severity: normal
status: open
title: IDLE: Right click menu not working on OS X
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Apr  8 03:00:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Apr 2013 01:00:15 +0000
Subject: [New-bugs-announce] [issue17655] Use writev() function in the io
	module
Message-ID: <1365382815.42.0.538101348018.issue17655@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since issue #12268 has been fixed, it looks like it became easier to modify the io to use the writev() function when available.

For example, if FileIO.writelines() uses writev(), it can be used by TextIOWrapper.write() through BufferedWriter. The _io.TextIOWrapper.write() method stores encoded chunks of text into a list. It can calls buffer.writlines(pending) instead of buffer.write(b''.join(pending)).

I expect less Python function calls and less system calls, and so better performances because both are expensive (especially I/O syscalls).

See also issue #15723.

I don't know if/how readv() can be used to optimize I/O performances.

----------
components: IO
messages: 186259
nosy: gregory.p.smith, haypo, pitrou
priority: normal
severity: normal
status: open
title: Use writev() function in the io module
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr  8 05:20:59 2013
From: report at bugs.python.org (Vhati)
Date: Mon, 08 Apr 2013 03:20:59 +0000
Subject: [New-bugs-announce] [issue17656] Python 2.7.4 Breaks ZipFile
	Extraction
Message-ID: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za>


New submission from Vhati:

Python 2.7.4 fails while extracting zip files when 'member' is a unicode path.

---
Traceback (most recent call last):
  ...
    my_zip.extract(item, tmp_folder_path)
  File "D:\Apps\Python274\lib\zipfile.py", line 1024, in extract
    return self._extract_member(member, path, pwd)
  File "D:\Apps\Python274\lib\zipfile.py", line 1057, in _extract_member
    arcname = arcname.translate(table)
TypeError: character mapping must return integer, None or unicode
---
2.7.3 had no problems because the call to translate() is new.


The following, copied from ZipFile.py, will recreate the error.
--
import string
illegal = ':<>|"?*'
table = string.maketrans(illegal, '_' * len(illegal))

arcname = "hi"
arcname = arcname.translate(table)
# ascii strings are fine

arcname = u"hi"
arcname = arcname.translate(table)
# unicode fails
# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
# TypeError: character mapping must return integer, None or unicode
---

I tried using unicode literals for the illegal string and maketrans underscore arg, but that didn't work. Suggestions?


Here's a link to the doc for translate().
http://docs.python.org/2/library/stdtypes.html#str.translate

----------
components: Unicode
messages: 186264
nosy: Vhati, ezio.melotti
priority: normal
severity: normal
status: open
title: Python 2.7.4 Breaks ZipFile Extraction
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  8 05:37:34 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 08 Apr 2013 03:37:34 +0000
Subject: [New-bugs-announce] [issue17657] IDLE: about dialog should report
	the full version of TK
Message-ID: <1365392254.45.0.513038915285.issue17657@psf.upfronthosting.co.za>


New submission from Todd Rovito:

The IDLE about dialog does not report the full version of TK.  For instance it will report "8.5" and not report the last minor version number such as "8.5.9".  On the Mac OS X this is problematic (but it could be a problem on other platforms) because Apple ships their own version of TK which is known to be buggy.  For bug reporting purposes IDLE should report the full version of TK which could help diagnose bugs.

----------
components: IDLE
messages: 186266
nosy: Todd.Rovito
priority: normal
severity: normal
status: open
title: IDLE: about dialog should report the full version of TK
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Apr  8 05:51:55 2013
From: report at bugs.python.org (Patrick Poitras)
Date: Mon, 08 Apr 2013 03:51:55 +0000
Subject: [New-bugs-announce] [issue17658] pythonw.exe crashes on opening IDLE
Message-ID: <1365393115.5.0.931092283515.issue17658@psf.upfronthosting.co.za>


New submission from Patrick Poitras:

I just installed Python 3.3.1, and tried to open IDLE, which failed to come up, giving only the classic pythonw.exe has stopped responding.

Will post dumps.

----------
components: IDLE, Windows
files: WER1B0A.tmp.WERInternalMetadata.xml
messages: 186268
nosy: Acebulf
priority: normal
severity: normal
status: open
title: pythonw.exe crashes on opening IDLE
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file29725/WER1B0A.tmp.WERInternalMetadata.xml

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

From report at bugs.python.org  Mon Apr  8 10:48:03 2013
From: report at bugs.python.org (=?utf-8?q?Izidor_Matu=C5=A1ov?=)
Date: Mon, 08 Apr 2013 08:48:03 +0000
Subject: [New-bugs-announce] [issue17659] First weekday
Message-ID: <1365410883.64.0.172005963141.issue17659@psf.upfronthosting.co.za>


New submission from Izidor Matu?ov:

There is no way how to figure out the first weekday: Does a week start with Monday or Saturday? (Or any other day?)

According to documentation, module locale doesn't provide this information. Module calendar uses European convention (Monday is the first weekday).

Purpose of this issue is to have a way how to return first weekday (Monday, Sunday, etc)

Known workarounds:
  * http://blogs.gnome.org/patrys/2008/09/29/how-to-determine-the-first-day-of-week/
  * https://github.com/projecthamster/hamster/blob/master/src/hamster/lib/stuff.py#L153
  * http://stackoverflow.com/questions/4265697/how-to-determine-the-first-day-of-week-in-python

----------
components: Library (Lib)
messages: 186280
nosy: IzidorMatusov
priority: normal
severity: normal
status: open
title: First weekday
type: enhancement

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

From report at bugs.python.org  Mon Apr  8 12:48:10 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Apr 2013 10:48:10 +0000
Subject: [New-bugs-announce] [issue17660] mock.patch could whitelist
	builtins to not need	create=True
Message-ID: <1365418089.99.0.0976801798706.issue17660@psf.upfronthosting.co.za>


New submission from Michael Foord:

When patching builtin names (e.g. open) in a specific namespace you need to specify "create=True" or patch will refuse to create a name that doesn't exist.

patch could whitelist the builtin names, when the patch target is a module object, to not require the "create=True".

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 186290
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: mock.patch could whitelist builtins to not need create=True
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr  8 14:32:38 2013
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 08 Apr 2013 12:32:38 +0000
Subject: [New-bugs-announce] [issue17661] documentation of '%r' links to the
	wrong repr
Message-ID: <1365424358.04.0.0999956639688.issue17661@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

The documentation of '%r' in http://docs.python.org/2/library/stdtypes.html#string-formatting-operations links to the wrong repr, the module (http://docs.python.org/2/library/repr.html#module-repr) instead of the builtin function (http://docs.python.org/2/library/functions.html#func-repr).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 186292
nosy: docs at python, twouters
priority: normal
severity: normal
status: open
title: documentation of '%r' links to the wrong repr
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  8 14:57:17 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Mon, 08 Apr 2013 12:57:17 +0000
Subject: [New-bugs-announce] [issue17662] socketmodule raises on import when
	compiled using	Setup.dist on 2.7.4
Message-ID: <1365425837.0.0.73403835622.issue17662@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

When building extension modules of Python 2.7.4 through Modules/Setup.dist, the socketmodule gets built badly, as it also needs to be compiled with timemodule.c (see the attached patch).
This was caused by commit 8ec39bfd1f01, which introduced usage of _PyTime_floattime() without fixing Setup.dist (note, that this is ok when compiling through setup.py, as it has:

exts.append( Extension('_socket', ['socketmodule.c', 'timemodule.c'],

----------
components: Build
files: python-2.7.4-properly-compile-socketmodule-by-Setupdist.patch
keywords: patch
messages: 186298
nosy: bkabrda
priority: normal
severity: normal
status: open
title: socketmodule raises on import when compiled using Setup.dist on 2.7.4
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file29730/python-2.7.4-properly-compile-socketmodule-by-Setupdist.patch

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

From report at bugs.python.org  Mon Apr  8 15:25:17 2013
From: report at bugs.python.org (z06steve)
Date: Mon, 08 Apr 2013 13:25:17 +0000
Subject: [New-bugs-announce] [issue17663] re.sub not replacing all
Message-ID: <1365427517.11.0.8190689371.issue17663@psf.upfronthosting.co.za>


New submission from z06steve:

fails to replace last occurrence of string v_wofstgvw, reproduced in 3.2.3, 3.2.4 and 3.3.1

a='''
--------------------------------------------------------------------------------
-- V_INT_CTRC_ENTRY_DATE
--------------------------------------------------------------------------------
REPLACE VIEW V_WOFSTGVW.V_INT_CTRC_ENTRY_DATE AS LOCKING ROW FOR ACCESS
SELECT                                                                        
 D.DY DY,                   
 D.DW_CRRT_FL CURRENT_FLAG,                                                   
         D.MTH CURRENT_MTH,                                                     
(CAST(D.DY AS DATE) - EXTRACT(DAY FROM (CAST( D.DY AS DATE)))+1)  CURRENT_MTH_BEG_DT,                              
       ADD_MONTHS ((CAST(D.DY AS DATE) - EXTRACT(DAY FROM (CAST( D.DY AS DATE)))+1) , 1) - 1 CURRENT_MTH_END_DT,            
        D.WOFC_MTH_END_FLG CURRENT_MTH_END_FLG,                                
         D.WOFC_QTR_END_FLG CURRENT_QTR_END_FL,                                 
         D.YR CURRENT_YEAR,                                                     
             ((D.YR||'01/01')(DATE)) CURRENT_YEAR_BEG_DT ,     
              ((D.YR||'12/31')(DATE)) CURRENT_YEAR_END_DT ,       
         D.WOFC_YR_END_FLG CURRENT_YEAR_END_FL,                                 
 D.HDAY_FLG HOLIDAY_FLG,                                                    
       CAST(ADD_MONTHS (CASE WOFC_MTH_END_FLG
                               WHEN 'Y'
                                  THEN WOFCO_FRST_DY_MTH
                               ELSE WOFCO_BEGIN_MTH_DT
                            END,
                            -1)AS CHAR(7)) PREV_REP_MTH,
         ADD_MONTHS (CASE WOFC_MTH_END_FLG                                      
                        WHEN 'Y'                                                
                           THEN WOFCO_FRST_DY_MTH                               
                        ELSE WOFCO_BEGIN_MTH_DT                                 
                     END,                                                       
-1
                    ) PREV_REP_MTH_BEG_DT,                                      
        ADD_MONTHS (CASE WOFC_MTH_END_FLG                                      
                        WHEN 'Y'                                                
                           THEN D.DY                                            
                        ELSE D.WOFCO_MTH_END_DT                                 
                     END,                                                       
-1
                    ) PREV_REP_MTH_END_DT                                      
         ,
         D.PREV_MTH PRIOR_MTH,                                                  
         PSETM.PRIOR_SET_CURRENT_MTH,                                           
 PSETM.PRIOR_SET_CURRENT_MTH_BGN_DT,                                          
         PSETM.PRIOR_SET_CURRENT_MTH_END_DT,                                    
 PREPSETM.PRIOR_SET_REP_MTH,                                                  
         PREPSETM.PRIOR_SET_REP_MTH_BGN_DT,                                     
 PREPSETM.PRIOR_SET_REP_MTH_END_DT,                                           
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN MTH                                                         
            ELSE PREV_MTH                                                       
         END REP_MTH,                                                           
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN WOFCO_FRST_DY_MTH                                           
            ELSE WOFCO_BEGIN_MTH_DT                                             
         END REP_MTH_BEG_DT,                                                    
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN D.DY                                                        
            ELSE D.WOFCO_MTH_END_DT                                             
         END REP_MTH_END_DT,
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN ADD_MONTHS (D.WOFCO_FRST_DY_MTH,                            
12
                               )                                                
            ELSE ADD_MONTHS (D.WOFCO_BEGIN_MTH_DT, 12)                          
         END REP_MTH_NEXT_YEAR_BEG_DT,                                          
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN ADD_MONTHS (D.DY, 12)                                       
            ELSE D.WOFCO_MTH_NXT_YR_DT                                          
         END REP_MTH_NEXT_YEAR_END_DT,                                          
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN D.YR                                                        
            ELSE SUBSTR (PREV_MTH, 1, 4)                                        
         END REP_YEAR,                                                    
         CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
            THEN  (CAST((CAST(D.YR AS DATE FORMAT 'YYYY')||'/01/01') AS DATE FORMAT 'YYYY/MM/DD'))
  ELSE  (CAST((SUBSTR (PREV_MTH, 1, 4) || '/01/01')AS DATE FORMAT 'YYYY/MM/DD' ))
         END REP_YEAR_BEG_DT,                                                   
    CASE WOFC_MTH_END_FLG                                                  
            WHEN 'Y'                                                            
               THEN (CAST((CAST(D.YR AS DATE FORMAT 'YYYY' )||'/12/31') AS DATE FORMAT 'YYYY/MM/DD'))              
            ELSE (CAST((SUBSTR (PREV_MTH, 1, 4) || '/12/31') AS DATE FORMAT 'YYYY/MM/DD' ))   
         END REP_YEAR_END_DT,
 D.SET_MTH SET_CURRENT_MTH,                                                   
         D.SET_BEGIN_MTH_DT SET_CURRENT_MTH_BGN_DT,                             
         D.SET_MTH_END_DT SET_CURRENT_MTH_END_DT,                               
 D.SET_YR SET_CURRENT_YEAR,                                                   
         D1.SET_CURRENT_BEG_DT SET_CURRENT_YEAR_BEG_DT,                         
         D2.SET_CURRENT_END_DT SET_CURRENT_YEAR_END_DT,                         
         D.SET_MTH_END_FLG SET_MTH_END_FLAG,                                    
         D.SET_QTR_END_FLG SET_QTR_END_FLAG,                                    
         CASE D.SET_MTH_END_FLG                                                 
            WHEN 'Y'                                                            
               THEN (CAST (D.SET_BEGIN_MTH_DT AS CHAR(7)))                  
            ELSE (CAST (SET_MTH_BEG_PREV_DT AS CHAR (7)))                 
         END SET_REP_MTH,                                                       
         CASE D.SET_MTH_END_FLG                                                 
            WHEN 'Y'                                                            
               THEN D.SET_BEGIN_MTH_DT                                          
            ELSE SET_MTH_BEG_PREV_DT                                            
         END SET_REP_MTH_BEG_DT,                                                
         CASE D.SET_MTH_END_FLG                                                 
            WHEN 'Y'                                                            
               THEN D.SET_MTH_END_DT                                            
            ELSE SET_MTH_END_PREV_DT                                            
         END SET_REP_MTH_END_DT,                                                
         SUBSTR (CASE D.SET_MTH_END_FLG                                         
                    WHEN 'Y'                                                    
                       THEN (CAST (D.SET_BEGIN_MTH_DT AS CHAR(7)))              
                    ELSE (CAST (SET_MTH_BEG_PREV_DT AS CHAR(7)))               
                 END,                                                           
                 1, 4)SET_REP_YEAR ,                                                      
         RD1.SET_RPT_YEAR_BEG_DT SET_RPT_YEAR_BEG_DT,                           
 SYB.SET_RPT_YEAR_END_DT,                                                     
D.SET_YR_END_FLG SET_YEAR_END_FLAG                                                                      
 FROM  V_WOFSTGVW.D_DT D
LEFT OUTER JOIN 
          (SELECT   D.SET_YR,                                      
                   MIN (D.SET_BEGIN_YR_DT) SET_CURRENT_BEG_DT      
              FROM V_WOFSTGVW.D_DT D                                          
             WHERE (CAST (D.SET_BEGIN_YR_DT AS CHAR(4)))  =           
                                                         D.SET_YR  
           GROUP BY D.SET_YR) D1                            
ON
  D1.SET_YR = D.SET_YR                                               
LEFT OUTER JOIN 
         (SELECT D_SET_CURR_END.SET_YR, D_SET_CURR_END.DY SET_CURRENT_END_DT    
            FROM V_WOFSTGVW.D_DT D_SET_CURR_END                                            
           WHERE D_SET_CURR_END.SET_YR_END_FLG = 'Y') D2                 
           ON D2.SET_YR = D.SET_YR 
LEFT OUTER JOIN 
         (SELECT   CASE WOFC_MTH_END_FLG                                        
                      WHEN 'Y'                                                  
                         THEN D.YR                                 
                      ELSE SUBSTR (D.PREV_MTH, 1, 4)               
                   END SET_RPT_YR,                                              
                   MIN (D.SET_BEGIN_YR_DT) SET_RPT_YEAR_BEG_DT     
              FROM V_WOFSTGVW.D_DT D                                          
             WHERE D.PREV_MTH IS NOT NULL                          
               AND SET_BEGIN_YR_DT IS NOT NULL                                  
          GROUP BY CASE WOFC_MTH_END_FLG                                        
                      WHEN 'Y'                                                  
                         THEN D.YR                                 
                      ELSE SUBSTR (D.PREV_MTH, 1, 4)               
                   END) RD1                                         
    ON RD1.SET_RPT_YR =                                                   
            (CASE D.SET_MTH_END_FLG                                             
                WHEN 'Y'                                                        
                   THEN (CAST(D.SET_BEGIN_MTH_DT AS CHAR(4)))                   
                ELSE (CAST (D.SET_MTH_BEG_PREV_DT AS CHAR(4)))                    
             END                                                                
            )                                                                   
LEFT OUTER JOIN 
         (SELECT   D.SET_MTH, MIN (D.SET_MTH_END_DT) SET_RPT_YEAR_END_DT        
              FROM V_WOFSTGVW.D_DT D                                                       
             WHERE D.SET_MTH =                                                  
                      CASE D.SET_MTH_END_FLG                                    
                         WHEN 'Y'                                               
                            THEN (CAST(D.SET_BEGIN_MTH_DT AS CHAR(4)))       
                         ELSE (CAST (SET_MTH_BEG_PREV_DT AS CHAR(4)))          
                      END                                                       
          GROUP BY D.SET_MTH) SYB                                            
ON
 (   SYB.SET_MTH  =                                                      
               CASE WOFC_MTH_END_FLG                                            
                  WHEN 'Y'                                                      
                     THEN D.YR                                                  
                  ELSE SUBSTR (D.PREV_MTH, 1, 4)                                
               END                                                              
            || '/12' )                                                   
LEFT OUTER JOIN 
         (SELECT DISTINCT D.SET_MTH_END_FLG SET_MTH_END_FLAG,                   
                          D.SET_MTH PRIOR_SET_CURRENT_MTH,                      
                          D.SET_BEGIN_MTH_DT PRIOR_SET_CURRENT_MTH_BGN_DT,      
                          D.SET_MTH_END_DT PRIOR_SET_CURRENT_MTH_END_DT         
                     FROM V_WOFSTGVW.D_DT D) PSETM                                  
ON 
       PSETM.PRIOR_SET_CURRENT_MTH =                                 
                       (CAST (ADD_MONTHS (D.SET_BEGIN_MTH_DT, -1) AS CHAR(7)))            
AND  PSETM.SET_MTH_END_FLAG = D.SET_MTH_END_FLG 
LEFT OUTER JOIN 
         (SELECT DISTINCT D.SET_MTH_END_FLG SET_MTH_END_FLAG,                   
                          D.SET_MTH PRIOR_SET_REP_MTH,                          
                          D.SET_BEGIN_MTH_DT PRIOR_SET_REP_MTH_BGN_DT,          
                          D.SET_MTH_END_DT PRIOR_SET_REP_MTH_END_DT             
                     FROM V_WOFSTGVW.D_DT D) PREPSETM                                      
ON
       PREPSETM.PRIOR_SET_REP_MTH  =                                  
                 (CAST (ADD_MONTHS (CASE D.SET_MTH_END_FLG                    
                                         WHEN 'Y'                               
                                            THEN D.SET_BEGIN_MTH_DT             
                                         ELSE SET_MTH_BEG_PREV_DT               
                                      END, -1 ) AS CHAR(7)) )                               
AND  PREPSETM.SET_MTH_END_FLAG = D.SET_MTH_END_FLG
WHERE V_WOFSTGVW.D.DY <> DATE '9999-12-31';'''

re.sub('v_wofstgvw','d_dscteve', a, re.MULTILINE, re.IGNORECASE)

----------
components: Regular Expressions
messages: 186300
nosy: ezio.melotti, mrabarnett, z06steve
priority: normal
severity: normal
status: open
title: re.sub not replacing all
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Apr  8 17:36:00 2013
From: report at bugs.python.org (Paul Wiseman)
Date: Mon, 08 Apr 2013 15:36:00 +0000
Subject: [New-bugs-announce] [issue17664] ssl.SSLError has errno value of
	None
Message-ID: <1365435360.08.0.632289322267.issue17664@psf.upfronthosting.co.za>


New submission from Paul Wiseman:

I was using py2.7.3 and was getting None back for the errno attribute for an ssl.SSLError('The read operation timed out').

I noticed in the 2.7.4 release notes that it sounds like there was a fix for this:

Issue #12065: connect_ex() on an SSL socket now returns the original errno
when the socket's timeout expires (it used to return None).

I've just tested in py2.7.4 and I'm still getting None back for the errno attribute.

I'm using this code to produce the error:

import requests

def __init__(self, exception):
    # First extract the real underlying exception
    exception = exception.args[0]  # This should be ssl.SSLError
    super(requests.exceptions.ConnectionError, self).__init__(exception)
    self.strerror = exception.strerror
    self.errno = exception.errno

requests.exceptions.ConnectionError.__init__ = __init__

timeout_val = 0.2
while True:
    try:
        print requests.get("https://google.com", timeout=timeout_val)
    except requests.exceptions.SSLError as err:
        print err.strerror
        print err.errno
        break
    except Exception as err:
        print "Got %s: %s" % (err.__class__.__name__, err)
    timeout_val /= 2

----------
messages: 186310
nosy: Paul.Wiseman
priority: normal
severity: normal
status: open
title: ssl.SSLError has errno value of None
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr  8 19:46:27 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 08 Apr 2013 17:46:27 +0000
Subject: [New-bugs-announce] [issue17665] convert to idiomatic unittest code
Message-ID: <1365443187.46.0.933041957834.issue17665@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
components: Tests
files: diff
nosy: tshepang
priority: normal
severity: normal
status: open
title: convert to idiomatic unittest code
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29738/diff

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

From report at bugs.python.org  Mon Apr  8 19:55:12 2013
From: report at bugs.python.org (Peter)
Date: Mon, 08 Apr 2013 17:55:12 +0000
Subject: [New-bugs-announce] [issue17666] Extra gzip headers breaks
	_read_gzip_header
Message-ID: <1365443712.06.0.547975068624.issue17666@psf.upfronthosting.co.za>


New submission from Peter:

Regression in Python 3.3.0 to 3.3.1, tested under Mac OS X 10.8 and CentOS Linux 64bit.

The same regression also present in going from Python 2.7.3 from 2.7.4, does that need a separate issue filed?

Consider this VALID GZIP file, human link:
https://github.com/biopython/biopython/blob/master/Tests/GenBank/cor6_6.gb.bgz

Binary link, only a small file:
https://raw.github.com/biopython/biopython/master/Tests/GenBank/cor6_6.gb.bgz

This is compressed using a GZIP variant called BGZF which uses multiple blocks and records additional tags in the header, for background see:
http://blastedbio.blogspot.com/2011/11/bgzf-blocked-bigger-better-gzip.html

$ curl -O https://raw.github.com/biopython/biopython/master/Tests/GenBank/cor6_6.gb.bgz
$ cat cor6_6.gb.bgz | gunzip | wc
     320    1183   14967

Now for the bug, expected behaviour:

$ python3.2
Python 3.2 (r32:88445, Feb 28 2011, 17:04:33) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> handle = gzip.open("cor6_6.gb.bgz", "rb")
>>> data = handle.read()
>>> handle.close()
>>> len(data)
14967
>>> quit()

Broken behaviour:

$ python3.3
Python 3.3.1 (default, Apr  8 2013, 17:54:08) 
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gzip
>>> handle = gzip.open("cor6_6.gb.bgz", "rb")
>>> data = handle.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pjcock/lib/python3.3/gzip.py", line 359, in read
    while self._read(readsize):
  File "/Users/pjcock/lib/python3.3/gzip.py", line 432, in _read
    if not self._read_gzip_header():
  File "/Users/pjcock/lib/python3.3/gzip.py", line 305, in _read_gzip_header
    self._read_exact(struct.unpack("<H", self._read_exact(2)))
  File "/Users/pjcock/lib/python3.3/gzip.py", line 282, in _read_exact
    data = self.fileobj.read(n)
  File "/Users/pjcock/lib/python3.3/gzip.py", line 81, in read
    return self.file.read(size)
TypeError: integer argument expected, got 'tuple'


The bug is very simple, an error in line 205 of gzip.py:

203     if flag & FEXTRA:
204         # Read & discard the extra field, if present
205         self._read_exact(struct.unpack("<H", self._read_exact(2)))

The struct.unpack method returns a single element tuple, thus a fix is:

203     if flag & FEXTRA:
204         # Read & discard the extra field, if present
205         extra_len, = struct.unpack("<H", self._read_exact(2))
206         self._read_exact(extra_len)

This bug was identified via failing Biopython unit tests under Python 2.7.4 and 3.3.1, which all pass with this minor fix applied.

----------
components: Library (Lib)
messages: 186320
nosy: maubp
priority: normal
severity: normal
status: open
title: Extra gzip headers breaks _read_gzip_header
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr  8 20:10:34 2013
From: report at bugs.python.org (Anselm Kruis)
Date: Mon, 08 Apr 2013 18:10:34 +0000
Subject: [New-bugs-announce] [issue17667] Windows: build with "build_pgo.bat
	-2" fails to optimize	python.dll
Message-ID: <1365444634.63.0.621793850181.issue17667@psf.upfronthosting.co.za>


New submission from Anselm Kruis:

Version: 2.7.4 (and any prior 2.7-version. not tested with 3.x)
Compiler: VS 2008 Professional

If I compile Python using the batch 

> PCbuild\build_pgo.bat -2

Visual Studio fails to correctly collect profile information for the project "python27.dll". As a result, no real optimisation takes place.

The command "build_pgo.bat -2" runs the full test suite (..\lib\test\regrtest.py) to collect profile data. Experiments show, that several test cases (i.e. test_os and test_subprocess) break the collection of profile data. Probably the failure is related to the creation of sub-processes. I consider it a Visual Studio bug.

To work around this issue I created a list of good test cases and patched build_pgo.bat to run only the tests from this list.

----------
components: Build, Windows
files: build_pgo-2.patch
keywords: patch
messages: 186322
nosy: akruis
priority: normal
severity: normal
status: open
title: Windows: build with "build_pgo.bat -2" fails to optimize python.dll
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file29739/build_pgo-2.patch

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

From report at bugs.python.org  Mon Apr  8 20:18:58 2013
From: report at bugs.python.org (Tomasz J. Kotarba)
Date: Mon, 08 Apr 2013 18:18:58 +0000
Subject: [New-bugs-announce] [issue17668] re.split loses characters matching
	ungrouped parts of a	pattern
Message-ID: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>


New submission from Tomasz J. Kotarba:

Tested in 2.7 but possibly affects the other versions as well.

A real life example (note the first character '>' being lost):

>>> import re
>>> re.split(r'^>(.*)$', '>Homo sapiens catenin (cadherin-associated)')

produces:

['', 'Homo sapiens catenin (cadherin-associated)', '']


Expected (and IMHO most useful) behaviour would be for it to return:

['', '>Homo sapiens catenin (cadherin-associated)', '']

or (IMHO much less useful as one can already get this one just by adding external grouping parentheses and it is ):

['', '>Homo sapiens catenin (cadherin-associated)', 'Homo sapiens catenin (cadherin-associated)', '']

Not sure whether it can be changed in such a mature and widely used module without breaking compatibility but just adding a new optional parameter for deciding how re.split() deals with patterns containing grouping parentheses and making it default to the current behaviour would be very helpful.
Best Regards

----------
components: Regular Expressions
messages: 186324
nosy: ezio.melotti, mrabarnett, triquetra011
priority: normal
severity: normal
status: open
title: re.split loses characters matching ungrouped parts of a pattern
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  9 00:49:14 2013
From: report at bugs.python.org (Frank Hamand)
Date: Mon, 08 Apr 2013 22:49:14 +0000
Subject: [New-bugs-announce] [issue17669] Segfault caused by
Message-ID: <1365461354.47.0.82208645723.issue17669@psf.upfronthosting.co.za>


Changes by Frank Hamand <frankhamand at hotmail.com>:


----------
components: Interpreter Core, Windows
nosy: fhamand
priority: normal
severity: normal
status: open
title: Segfault caused by
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  9 01:26:31 2013
From: report at bugs.python.org (=?utf-8?q?Alfredo_Solano_Mart=C3=ADnez?=)
Date: Mon, 08 Apr 2013 23:26:31 +0000
Subject: [New-bugs-announce] [issue17670] expandabs() weirdness
Message-ID: <1365463591.17.0.891545615286.issue17670@psf.upfronthosting.co.za>


New submission from Alfredo Solano Mart?nez:

I stumbled upon this by chance. Is the following behaviour by design?

>>> s = 'a\tb'
>>> s.expandtabs(1) == s.expandtabs(2)
True

In fact:
>>> s.expandtabs(1)
'a b' # 1 space
>>> s.expandtabs(2)
'a b' # 1 space
>>> s.expandtabs(3)
'a  b' # 2 spaces
>>> s.expandtabs(4)
'a   b' # 3 spaces

It seems to be an off-by-one difference from 2 onwards. 

Tested with python versions 2.7.4, 3.2.4 and 3.3.1 on a Linux x86_64 machine.

----------
components: Library (Lib)
messages: 186358
nosy: asolano
priority: normal
severity: normal
status: open
title: expandabs() weirdness
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Apr  9 01:55:32 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Apr 2013 23:55:32 +0000
Subject: [New-bugs-announce] [issue17671] io.BufferedRWPair can use
	uninitialized members
Message-ID: <1365465332.23.0.700317324795.issue17671@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This segfaults on all Python versions:
  io.BufferedRWPair.__new__(io.BufferedRWPair).read()

The various "_forward_call" methods should check that the reader and writer objects are correctly initialized. Not NULL, at the very least.

----------
components: IO
messages: 186360
nosy: amaury.forgeotdarc, pitrou
priority: normal
severity: normal
status: open
title: io.BufferedRWPair can use uninitialized members
type: crash
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr  9 06:45:38 2013
From: report at bugs.python.org (Hiroaki Kawai)
Date: Tue, 09 Apr 2013 04:45:38 +0000
Subject: [New-bugs-announce] [issue17672] ssl clean shutdown
Message-ID: <1365482738.48.0.840321565435.issue17672@psf.upfronthosting.co.za>


New submission from Hiroaki Kawai:

When using ssl module, I sometimes get unexpected error. The observed error varies in different situations. After the investigation, I found the reason was that ssl shutdown was not performed and sometimes RST was sent over the network instead of FIN.

I created a patch against 2.7 branch.

----------
components: Library (Lib)
files: python27.patch
keywords: patch
messages: 186372
nosy: Hiroaki.Kawai
priority: normal
severity: normal
status: open
title: ssl clean 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/file29750/python27.patch

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

From report at bugs.python.org  Tue Apr  9 12:19:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Apr 2013 10:19:58 +0000
Subject: [New-bugs-announce] [issue17673] add `copy_from` argument to
	temporaryfile
Message-ID: <1365502798.91.0.357173988008.issue17673@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It is sometimes useful to create a temporary file as a copy of an existing file (especially e.g. in tests, when you want to mutate the temp file but not the original). I would suggest adding a `copy_from` argument to TemporaryFile and NamedTemporaryFile, which is either the path to an existing file or a file-like object. Then the contents of that source file are copied to the tempfile before it is yielded.

----------
components: Library (Lib)
messages: 186392
nosy: ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: add `copy_from` argument to temporaryfile
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr  9 15:04:51 2013
From: report at bugs.python.org (gjwebber)
Date: Tue, 09 Apr 2013 13:04:51 +0000
Subject: [New-bugs-announce] [issue17674] All examples for
	concurrent.futures fail with	"BrokenProcessPool"
Message-ID: <1365512691.79.0.330331294917.issue17674@psf.upfronthosting.co.za>


New submission from gjwebber:

Running on Windows XP 32-bit.
Uninstalled Python 2.7, installed Python 3.3.

I asked a question on stack overflow, detailing the problem and supplying example code and Traceback here:
http://stackoverflow.com/questions/15900366/all-example-concurrent-futures-code-is-failing-with-brokenprocesspool

More info on request if required.

----------
components: Library (Lib), Windows
messages: 186397
nosy: gjwebber
priority: normal
severity: normal
status: open
title: All examples for concurrent.futures fail with "BrokenProcessPool"
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr  9 15:16:10 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 09 Apr 2013 13:16:10 +0000
Subject: [New-bugs-announce] [issue17675] show addresses in socket.__repr__
Message-ID: <1365513370.53.0.242693872141.issue17675@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is useful, for example, when running tests as "python3 -Wa" and you bump into:

ResourceWarning: unclosed <socket object, fd=8, family=2, type=2, proto=0>

With this we'd get:

<socket.socket fd=8, family=2, type=2, proto=0, laddr=('192.168.1.2', 37537), raddr=('173.194.35.6', 80)>

If desirable, I will add some tests.

----------
components: Library (Lib)
files: socket-repr.patch
keywords: patch
messages: 186400
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: show addresses in socket.__repr__
versions: Python 3.4
Added file: http://bugs.python.org/file29751/socket-repr.patch

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

From report at bugs.python.org  Tue Apr  9 15:28:48 2013
From: report at bugs.python.org (Alex Waite)
Date: Tue, 09 Apr 2013 13:28:48 +0000
Subject: [New-bugs-announce] [issue17676] spwd uses -1 for empty attributes
Message-ID: <1365514128.27.0.523273104192.issue17676@psf.upfronthosting.co.za>


New submission from Alex Waite:

spwd uses -1 rather than '' for empty attributes. This is different from the behaviour in the pwd module, and makes it more difficult to generate a new, valid shadow entry.

In my opinion, simply doing a ':'.join(str(val) for val in rec) should result in a valid entry. With pwd this is currently possible. Not so with spwd.

pwd:
import pwd
rec = pwd.getpwnam('alex')
print ':'.join(str(val) for val in rec)

spwd:
import spwd
rec = spwd.getspnam('alex')
shdw = ''
for idx, val in enumerate(recs_shdw):
    if idx != 0:
        shdw += ':'

    if val != -1:
        shdw += str(val)

print shdw

----------
messages: 186402
nosy: Alexqw
priority: normal
severity: normal
status: open
title: spwd uses -1 for empty attributes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr  9 15:36:58 2013
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 09 Apr 2013 13:36:58 +0000
Subject: [New-bugs-announce] [issue17677] Invitation to connect on LinkedIn
Message-ID: <476079342.24940169.1365514616076.JavaMail.app@ela4-app0134.prod>


New submission from Bruce Frederiksen:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Bruce

Bruce Frederiksen
Information Technology and Services Professional
Tampa/St. Petersburg, Florida Area

Confirm that you know Bruce Frederiksen:
https://www.linkedin.com/e/-3qcne3-hfb45911-6b/isd/12316860876/7QjJbS4a/?hs=false&tok=0GlQRpsV-Mh5I1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hfb45911-6b/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4080988955_1/?hs=false&tok=3s-0HjjjGMh5I1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 186404
nosy: dangyogi
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Tue Apr  9 15:40:04 2013
From: report at bugs.python.org (Wei-Cheng Pan)
Date: Tue, 09 Apr 2013 13:40:04 +0000
Subject: [New-bugs-announce] [issue17678] DeprecationWarning fix on
	cookiejar module since Python	3.3
Message-ID: <1365514804.83.0.671647327236.issue17678@psf.upfronthosting.co.za>


Changes by Wei-Cheng Pan <legnaleurc at gmail.com>:


----------
components: Library (Lib)
files: cookiejar_fix_deprecated_method_calls.patch
keywords: patch
nosy: Wei-Cheng.Pan
priority: normal
severity: normal
status: open
title: DeprecationWarning fix on cookiejar module since Python 3.3
versions: Python 3.3
Added file: http://bugs.python.org/file29752/cookiejar_fix_deprecated_method_calls.patch

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

From report at bugs.python.org  Tue Apr  9 15:51:48 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 09 Apr 2013 13:51:48 +0000
Subject: [New-bugs-announce] [issue17679] sysconfig generation uses some env
	variables multiple	times
Message-ID: <1365515508.55.0.936246153534.issue17679@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

When compiling Python 3.3.1, I noticed that some variables like LDFLAGS or CFLAGS in sysconfig have some flags multiple times. (Which BTW breaks distutils.tests.{test_sysconfig_compiler_vars,test_sysconfig_module}) This is caused by interpretation of Makefile in sysconfig._parse_makefile(), which seems to evaluate the variables in Makefile - but some variables in Makefile are formed by expanding env variables multiple times, e.g.:
PY_LDFLAGS=        $(CONFIGURE_LDFLAGS) $(LDFLAGS)
CONFIGURE_LDFLAGS=        @LDFLAGS@
so when doing the build from scratch with configure & make, PY_LDFLAGS gets the content of LDFLAGS twice  (as far as I remember autotools...), CFLAGS gets expanded like 5 times at least.
I think that this is not the correct behaviour, but not sure, maybe I'm doing something wrong.

Thanks.

----------
components: Build
messages: 186408
nosy: bkabrda
priority: normal
severity: normal
status: open
title: sysconfig generation uses some env variables multiple times
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Tue Apr  9 15:59:08 2013
From: report at bugs.python.org (Roman Rader)
Date: Tue, 09 Apr 2013 13:59:08 +0000
Subject: [New-bugs-announce] [issue17680] self is lost if methods are
	callable objects
Message-ID: <1365515948.78.0.259986619224.issue17680@psf.upfronthosting.co.za>


New submission from Roman Rader:

Some strange behavior is observed while method in object substitutes with callable object.

For example:
-------------------------------------
class Meth(object):
    def __call__(*args, **kwargs):
        print (args, kwargs)

class X(object):
    def some_method(*args, **kwargs):
        print (args, kwargs)

x = X()
x.some_method(1)
X.some_method = Meth()
x.some_method(1)

-------------------------------------
Output
(<__main__.X object at 0xb72d408c>, 1) {}
(<__main__.Meth object at 0xb72d40cc>, 1) {}
-------------------------------------

So, second call lost caller object ("self").
I suppose second output should be
(<__main__.Meth object ...>, <__main__.X object ...>, 1) {}


Tested in Python 2.7 and Python 3.3.

----------
components: Interpreter Core
messages: 186410
nosy: Roman.Rader
priority: normal
severity: normal
status: open
title: self is lost if methods are callable objects
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Apr  9 17:03:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Apr 2013 15:03:01 +0000
Subject: [New-bugs-announce] [issue17681] Work with an extra field of gzip
	files
Message-ID: <1365519781.38.0.309194725625.issue17681@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Gzip files can contains an extra field and some applications use this for extending gzip format. The current GzipFile implementation ignores this field on input and doesn't allow to create a new file with an extra field.

I propose to save an extra field data on reading as a GzipFile attribute and add new parameter for GzipFile constructor for creating new file with an extra field.

----------
components: Library (Lib)
messages: 186423
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Work with an extra field of gzip files
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr  9 17:31:05 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 09 Apr 2013 15:31:05 +0000
Subject: [New-bugs-announce] [issue17682] _io is missing in Setup.dist in
	2.7.x
Message-ID: <1365521465.61.0.848599040327.issue17682@psf.upfronthosting.co.za>


New submission from Matthias Klose:

_io is missing in Setup.dist in 2.7.x. just adding it, copied the file list from the setup.py, leaving it commented out.

----------
components: Build
messages: 186430
nosy: doko
priority: normal
severity: normal
status: open
title: _io is missing in Setup.dist in 2.7.x
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 10 03:02:50 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 10 Apr 2013 01:02:50 +0000
Subject: [New-bugs-announce] [issue17683] socket.getsockname() inconsistent
	return type with	AF_UNIX
Message-ID: <1365555770.86.0.711874075927.issue17683@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

(bytes vs. string)

>>> import socket 
>>> s = socket.socket(socket.AF_UNIX)
>>> s.getsockname()
b''
>>> s.bind(('/tmp/temp'))
>>> s.getsockname()
'/tmp/temp'
>>>

----------
messages: 186472
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: socket.getsockname() inconsistent return type with AF_UNIX
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 10 05:10:29 2013
From: report at bugs.python.org (Jeff Ramnani)
Date: Wed, 10 Apr 2013 03:10:29 +0000
Subject: [New-bugs-announce] [issue17684] Skip tests in test_socket like
	testFDPassSeparate on OS X
Message-ID: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za>


New submission from Jeff Ramnani:

The changeset for subtests in #16997 cause some tests in test_socket to fail on OS X.
Specifically, they cause some tests that were marked as expected failures to be run and be marked as failures.

I'm experiencing the same test failures as the OS X Mountain Lion buildbot.  `Here's an example build failure (Build 1058). http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20%5BSB%5D%203.x/builds/1058`_

Per issue #12958 I believe these tests should be skipped on OS X.

I'm attaching a patch which skips the offending tests on OS X.

----------
components: Tests
files: skip-fd-socket-tests-osx.patch
keywords: patch
messages: 186474
nosy: jramnani
priority: normal
severity: normal
status: open
title: Skip tests in test_socket like testFDPassSeparate on OS X
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29762/skip-fd-socket-tests-osx.patch

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

From report at bugs.python.org  Wed Apr 10 14:19:09 2013
From: report at bugs.python.org (Edd)
Date: Wed, 10 Apr 2013 12:19:09 +0000
Subject: [New-bugs-announce] [issue17685] Frozenset literal?
Message-ID: <1365596349.2.0.253732187508.issue17685@psf.upfronthosting.co.za>


New submission from Edd:

Hi,

I am willing to bet that this has been discussed before, but I don't see any related bugs.

I have been using Python for a while now as a prototyping language for scientific applications. Most recently I have been using it for prototype program analyses.

In this kind of work you are usually transcribing pseudo-code, defined in terms of sets, vectors and mappings into Python syntax. Inevitably, you need to store sets of sets, or you need to do some other operation that requires a hashable data structure.

As a result, I never use sets. I usually resort to using frozensets, which are hashable, yet the syntax for creating these is very verbose:

frozenset([e1, e2, ...])

To counter this, I usually use the following hack:

fs = frozenset

then frozensets can be instantiated like this:

fs([e1, e2, ...])

But this is not ideal. I can't help wondering why there is not a frozenset literal. I see that the mutable set recently got a literal, but why not frozenset?

Cheers!

----------
components: Interpreter Core
messages: 186486
nosy: vext01
priority: normal
severity: normal
status: open
title: Frozenset literal?
type: enhancement

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

From report at bugs.python.org  Wed Apr 10 15:11:35 2013
From: report at bugs.python.org (Masato HASHIMOTO)
Date: Wed, 10 Apr 2013 13:11:35 +0000
Subject: [New-bugs-announce] [issue17686] Doc using/unix broken link
	(http://linuxmafia.com/)
Message-ID: <1365599495.88.0.846759502226.issue17686@psf.upfronthosting.co.za>


New submission from Masato HASHIMOTO:

In Doc/using/unix.rst, the following link is broken:

31:   http://linuxmafia.com/pub/linux/suse-linux-internals/chapter35.html

(See also for OpenSuse users)

----------
assignee: docs at python
components: Documentation
messages: 186491
nosy: docs at python, hashimo
priority: normal
severity: normal
status: open
title: Doc using/unix broken link (http://linuxmafia.com/)
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 10 16:54:23 2013
From: report at bugs.python.org (Andreas Kloeckner)
Date: Wed, 10 Apr 2013 14:54:23 +0000
Subject: [New-bugs-announce] [issue17687] Undeclared symbol in _struct.c
Message-ID: <1365605663.05.0.5813211378.issue17687@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner:

This line in the "_struct" module references a "PyStructType" that isn't declared anywhere. This is only apparent when the file is compiled without -DNDEBUG.

http://hg.python.org/cpython/file/1410b7790de6/Modules/_struct.c#l43

----------
components: Extension Modules
messages: 186501
nosy: inducer
priority: normal
severity: normal
status: open
title: Undeclared symbol in _struct.c
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 10 18:22:19 2013
From: report at bugs.python.org (=?utf-8?q?Daniel_M=C3=BCllner?=)
Date: Wed, 10 Apr 2013 16:22:19 +0000
Subject: [New-bugs-announce] [issue17688] Wrong signature for richcmpfunc in
	documentation
Message-ID: <1365610939.69.0.214227746512.issue17688@psf.upfronthosting.co.za>


New submission from Daniel M?llner:

The C API documentation has a code snippet with a sample implementation of a rich comparison function here:

http://docs.python.org/3.3/extending/newtypes.html#object-comparison

The function is declared as

static int
newdatatype_richcmp(PyObject *obj1, PyObject *obj2, int op)

but I believe that it should be

static PyObject *
newdatatype_richcmp(PyObject *obj1, PyObject *obj2, int op)

----------
assignee: docs at python
components: Documentation
messages: 186513
nosy: docs at python, muellner
priority: normal
severity: normal
status: open
title: Wrong signature for richcmpfunc in documentation
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 10 20:40:49 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 10 Apr 2013 18:40:49 +0000
Subject: [New-bugs-announce] [issue17689] Fix test discovery for
	test_tarfile.py
Message-ID: <1365619249.38.0.463638779993.issue17689@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a patch for test_tarfile.py discovery.

There are a couple of inheritance issues resolved; CommonReadTest (and its children, MiscReadTest and StreamReadTest) are changed simply to avoid running the tests in CommonReadTest on their own--they pass, but are unnecessary.  LongnameTest and WriteTestBase cause failures when run on their own, so they no longer inherit from unittest.TestCase.

test_main() has been replaced by setUpModule, some skip decorators, and tearDownModule.  HardlinkTest and LinkEmulationTest are given skipUnless and skipIf decorators, respectively, instead of simply being appended to 'tests' or not.  This does change the test count; on my machine it adds the 4 tests skipped in LinkEmulationTest, raising the total from 307 to 311.  gzip, bz2, and lzma setup has been moved into setUpModule, and each group of those tests now has a new dummy base class with a skip decorator.  This will also change test counts on machines that don't have gzip, bz2, or lzma available.  tearDownModule replaces the finally clause at the end of test_main().

A simpler patch would just convert test_main into load_tests and add a tearDownModule function to replace the finally clause of test_main(), but I believe this slightly more invasive approach is more correct and should simplify future maintenance of the module.

Thanks,

Zach

----------
components: Tests
files: test_tarfile_discovery.diff
keywords: patch
messages: 186525
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_tarfile.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29765/test_tarfile_discovery.diff

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

From report at bugs.python.org  Wed Apr 10 20:58:07 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 10 Apr 2013 18:58:07 +0000
Subject: [New-bugs-announce] [issue17690] Fix test discovery for test_time.py
Message-ID: <1365620287.02.0.897864401648.issue17690@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Just inheritance issues in this one.  The patch removes _BaseYearTest as its only use was as a unittest.TestCase subclass to inherit from, which caused the discovery issues.

----------
components: Tests
files: test_time_discovery.diff
keywords: patch
messages: 186526
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_time.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29766/test_time_discovery.diff

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

From report at bugs.python.org  Wed Apr 10 21:19:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 10 Apr 2013 19:19:05 +0000
Subject: [New-bugs-announce] [issue17691] Fix test discovery for
	test_univnewlines.py
Message-ID: <1365621545.24.0.445008426691.issue17691@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Inheritance issues again.  This one has some magic in test_main to create the C and Python tests programmatically which I felt was best left alone, so the patch simply converts test_main into a load_tests which ignores its arguments.

----------
components: Tests
files: test_univnewlines_discovery.diff
keywords: patch
messages: 186527
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_univnewlines.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29767/test_univnewlines_discovery.diff

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

From report at bugs.python.org  Wed Apr 10 21:29:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 10 Apr 2013 19:29:08 +0000
Subject: [New-bugs-announce] [issue17692] Fix test discovery for
	test_sqlite.py
Message-ID: <1365622148.84.0.335603443253.issue17692@psf.upfronthosting.co.za>


New submission from Zachary Ware:

test_sqlite.py simply imports and runs tests from sqlite3.test, the patch converts test_main to load_tests to do the same.

----------
components: Tests
files: test_sqlite_discovery.diff
keywords: patch
messages: 186528
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_sqlite.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29768/test_sqlite_discovery.diff

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

From report at bugs.python.org  Thu Apr 11 01:50:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Apr 2013 23:50:55 +0000
Subject: [New-bugs-announce] [issue17693] Use _PyUnicodeWriter API for CJK
	decoders
Message-ID: <1365637855.94.0.450867352057.issue17693@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modify CJK decoders to use the _PyUnicodeWriter API. It adds a new _PyUnicodeWriter_WriteChar() function.

Performances are not optimal: the overallocation is not well controlled. I will try to adjust it later (if this patch is accepted).

----------
components: Unicode
files: cjkcodecs_writer.patch
keywords: patch
messages: 186536
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use _PyUnicodeWriter API for CJK decoders
versions: Python 3.4
Added file: http://bugs.python.org/file29769/cjkcodecs_writer.patch

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

From report at bugs.python.org  Thu Apr 11 01:53:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Apr 2013 23:53:21 +0000
Subject: [New-bugs-announce] [issue17694] Enhance _PyUnicodeWriter API to
	control minimum buffer	length without overallocation
Message-ID: <1365638001.77.0.401787088666.issue17694@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The _PyUnicodeWriter API is used in many functions to create Unicode strings, especially decoders. Performances are not optimal: it is not possible to specify the minimum length of the buffer if the overallocation is disabled. It may help #17693 for example.

----------
messages: 186537
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Enhance _PyUnicodeWriter API to control minimum buffer length without overallocation
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 11 07:59:08 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Apr 2013 05:59:08 +0000
Subject: [New-bugs-announce] [issue17695] _sysconfigdata broken with
	universal builds on OSX
Message-ID: <1365659948.17.0.458530957334.issue17695@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

The _sysconfig module contains the definitions for sysconfig.get_config_var and is created during python's build.

The definitions in _sysconfig.py for #define macros redefined in pymacconfig.h are wrong when building a universal build of Python (fat binaries) on OSX.

In particular the definitions for the various SIZEOF_ definitions are wrong and are the values for the default architecture of the build machine instead of reflecting the architecture for the code that is actually executing.

----------
messages: 186547
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: _sysconfigdata broken with universal builds on OSX
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Apr 11 09:08:20 2013
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Thu, 11 Apr 2013 07:08:20 +0000
Subject: [New-bugs-announce] [issue17696] lookup fails for renamed functions
Message-ID: <1365664100.2.0.310972176949.issue17696@psf.upfronthosting.co.za>


New submission from Ulrich Eckhardt:

When you rename a test function, you can't explicitly specify it on the commandline any more. During normal test runs, it is automatically discovered though. The error is that the old name was not found, even though the new name was specified. The attached example changes the name attached to the function (its __name__ attribute) for demonstration. The same problem occurs if you auto-generate test functions and attach them to the class, using post-processing or a metaclass. The cases all have in common that the name in the class' dict is not the same as the function's __name__, so cls.foo.__name__ is not "foo".

See http://mail.python.org/pipermail/python-list/2013-April/644863.html for the initial discussion on the mailinglist. While I only tested Python 2.7 there, it also fails for 3.2 and 3.3.

----------
components: Tests
files: name_mod.py
messages: 186549
nosy: eckhardt
priority: normal
severity: normal
status: open
title: lookup fails for renamed functions
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file29775/name_mod.py

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

From report at bugs.python.org  Thu Apr 11 17:07:39 2013
From: report at bugs.python.org (Don Allen)
Date: Thu, 11 Apr 2013 15:07:39 +0000
Subject: [New-bugs-announce] [issue17697] Incorrect stacktrace from pdb
Message-ID: <1365692859.49.0.652230897549.issue17697@psf.upfronthosting.co.za>


New submission from Don Allen:

Give the attached file execute permission and run it. At the first breakpoint, the backtrace will be correct. Continue. At the second breakpoint, a backtrace will show the foo('first call') on the stack when, in fact, the call came from foo('second call'), as verified by the printed message.

I am running this on an up-to-date 64-bit Arch Linux system. Python 3.3.1.

----------
components: Library (Lib)
files: python_bug.py
messages: 186561
nosy: donaldcallen
priority: normal
severity: normal
status: open
title: Incorrect stacktrace from pdb
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29777/python_bug.py

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

From report at bugs.python.org  Thu Apr 11 20:16:14 2013
From: report at bugs.python.org (Michael Bevilacqua-Linn)
Date: Thu, 11 Apr 2013 18:16:14 +0000
Subject: [New-bugs-announce] [issue17698] Setting allow_reuse_address in
	BaseHTTPServer has no	effect.
Message-ID: <1365704174.76.0.0610300427152.issue17698@psf.upfronthosting.co.za>


New submission from Michael Bevilacqua-Linn:

Hello, 

In BaseHTTPServer line 104 is the following:

allow_reuse_address = 1    # Seems to make sense in testing environment

This appears to attempt to set SO_REUSEADDR, but it doesn't actually do anything since the attribute that needs to be set to true is actually on the superclass (TCPServer).

A tad misleading when reading the code trying to figure out how to set SO_REUSEADDR.

----------
components: Library (Lib)
messages: 186572
nosy: Michael.Bevilacqua-Linn
priority: normal
severity: normal
status: open
title: Setting allow_reuse_address in BaseHTTPServer has no effect.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Apr 11 22:29:24 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 11 Apr 2013 20:29:24 +0000
Subject: [New-bugs-announce] [issue17699] Fix test_getpass on Windows
Message-ID: <1365712164.55.0.847820152156.issue17699@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Copied the nosy list from issue17484)

The new test module fails on Windows due to the lack of termios and pwd modules.  Here's a patch that fixes things.  I suspect the skip condition on UnixGetpassTest could be changed to check 'termios' rather than os.name, but I can't test that currently.

Thanks,

Zach

----------
components: Tests
files: test_getpass_windows_fix.diff
keywords: patch
messages: 186588
nosy: Thomas Fenzl, pitrou, r.david.murray, zach.ware
priority: normal
severity: normal
status: open
title: Fix test_getpass on Windows
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29782/test_getpass_windows_fix.diff

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

From report at bugs.python.org  Fri Apr 12 00:34:47 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 11 Apr 2013 22:34:47 +0000
Subject: [New-bugs-announce] [issue17700] Update Curses HOWTO for 3.4
Message-ID: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

Here's a patch updating the Curses HOWTO for 3.4 that can be applied to the default branch.  Changes:

* curses.wrapper.wrapper is now just curses.wrapper
* Mention window.encoding and its effect on Unicode.
* Describe getkey() as well as getch()
* Improve some examples.
* Use 4-space indentation.
* Add links to urwid, an alternate UI library.
* Various edits & rewording.

----------
assignee: docs at python
components: Documentation
files: update-curses-howto.txt
messages: 186599
nosy: akuchling, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Update Curses HOWTO for 3.4
type: enhancement
Added file: http://bugs.python.org/file29783/update-curses-howto.txt

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

From report at bugs.python.org  Fri Apr 12 02:06:03 2013
From: report at bugs.python.org (David Wolever)
Date: Fri, 12 Apr 2013 00:06:03 +0000
Subject: [New-bugs-announce] [issue17701] Improving strftime documentation
Message-ID: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za>


New submission from David Wolever:

The current strftime documentation isn't very helpful. It doesn't have examples, and the ordering is unhelpful.

I've also moved some format-specific notes into the notes below the format-string-table, because the format string table is what 98%* of people care about.

TODO before this can be merged:
- Clean up note order
- Check that it works with the Python 3 docs

*: based on a sample size of 1

----------
assignee: docs at python
components: Documentation
files: strftime-docs.diff
keywords: needs review, patch
messages: 186601
nosy: docs at python, wolever
priority: normal
severity: normal
status: open
title: Improving strftime documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file29784/strftime-docs.diff

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

From report at bugs.python.org  Fri Apr 12 02:36:11 2013
From: report at bugs.python.org (Robert Tasarz)
Date: Fri, 12 Apr 2013 00:36:11 +0000
Subject: [New-bugs-announce] [issue17702] os.environ converts key type from
	string to bytes in	KeyError exception
Message-ID: <1365726971.44.0.005141093776.issue17702@psf.upfronthosting.co.za>


New submission from Robert Tasarz:

Minimal example:

>>> import os
>>> somekey = 'random'
>>> try:
...   os.environ[somekey]
... except KeyError as e:
...   print(repr(e))
...   somekey == e.args[0]
... 
KeyError(b'random',)
False

Tested in Python 3.3.1 on Debian

----------
components: Extension Modules
messages: 186604
nosy: Robert.Tasarz
priority: normal
severity: normal
status: open
title: os.environ converts key type from string to bytes in KeyError exception
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 12 15:43:12 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 12 Apr 2013 13:43:12 +0000
Subject: [New-bugs-announce] [issue17703] Trash can mechanism segfault
	during interpreter	finalization in Python 2.7.4
Message-ID: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

A user reported a segfault when using our mxURL extension with Python 2.7.4. Previous Python versions do not show this behavior, so it's new in Python 2.7.4.

The extension uses an Py_AtExit() function to clean up among other things a reference to a dictionary from another module. The dictionary deallocation then causes the segfault:

$ gdb /usr/local/bin/python2.7
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/python2.7...done.
(gdb) r
Starting program: /usr/local/bin/python2.7
[Thread debugging using libthread_db enabled]
Python 2.7.4 (default, Apr  8 2013, 15:51:19)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mx.URL
>>> import sys
>>> sys.exit()

Program received signal SIGSEGV, Segmentation fault.
0x08091201 in dict_dealloc (mp=0xb7b2813c) at Objects/dictobject.c:1005
1005        Py_TRASHCAN_SAFE_BEGIN(mp)
(gdb) bt
#0  0x08091201 in dict_dealloc (mp=0xb7b2813c) at Objects/dictobject.c:1005
#1  0xb7875928 in mxURLModule_Cleanup () at mx/URL/mxURL/mxURL.c:2789
#2  0x0810553f in call_ll_exitfuncs () at Python/pythonrun.c:1763
#3  Py_Finalize () at Python/pythonrun.c:554
#4  0x08104bac in Py_Exit () at Python/pythonrun.c:1772
#5  handle_system_exit () at Python/pythonrun.c:1146
#6  0x0810517d in PyErr_PrintEx (set_sys_last_vars=<value optimized out>)
at Python/pythonrun.c:1156
#7  0x081058dd in PyRun_InteractiveOneFlags (fp=0xb7f8b420,
filename=0x815f9c0 "<stdin>", flags=0xbffffc4c) at Python/pythonrun.c:855
#8  0x08105a68 in PyRun_InteractiveLoopFlags (fp=0xb7f8b420,
filename=0x815f9c0 "<stdin>", flags=0xbffffc4c) at Python/pythonrun.c:772
#9  0x081062f2 in PyRun_AnyFileExFlags (fp=0xb7f8b420, filename=0x815f9c0
"<stdin>", closeit=0, flags=0xbffffc4c) at Python/pythonrun.c:741
#10 0x0805bb59 in Py_Main (argc=1, argv=0xbffffd34) at Modules/main.c:640
#11 0x0805abeb in main (argc=1, argv=0xbffffd34) at ./Modules/python.c:23
(gdb)

----------
assignee: pitrou
components: Interpreter Core
messages: 186627
nosy: lemburg, pitrou
priority: normal
severity: normal
status: open
title: Trash can mechanism segfault during interpreter finalization in Python 2.7.4
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 12 17:20:09 2013
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 12 Apr 2013 15:20:09 +0000
Subject: [New-bugs-announce] [issue17704] ImportError: No module named
	'_curses'
Message-ID: <1365780009.75.0.902696843023.issue17704@psf.upfronthosting.co.za>


New submission from Marco Buttu:

Right now I downloaded and installed Python 3.3.1 on Linux Mint 14, with Cinnamon:

$ uname -a
Linux buttu-oac 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ python3.3
Python 3.3.1 (default, Apr 12 2013, 16:24:16) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/curses/__init__.py", line 13, in <module>
    from _curses import *
ImportError: No module named '_curses'

It works fine on Python 3.2, where I have:

$ ls -1 /usr/lib/python3.2/lib-dynload/*_curses*
/usr/lib/python3.2/lib-dynload/_curses.cpython-32mu.so
/usr/lib/python3.2/lib-dynload/_curses_panel.cpython-32mu.so

On Python 3.3:

$ ls -1 /usr/lib/python3.3/lib-dynload/*_curses*
/usr/lib/python3.3/lib-dynload/_curses.cpython-33dm-x86_64-linux-gnu.so
/usr/lib/python3.3/lib-dynload/_curses.cpython-33m-x86_64-linux-gnu.so
/usr/lib/python3.3/lib-dynload/_curses_panel.cpython-33dm-x86_64-linux-gnu.so
/usr/lib/python3.3/lib-dynload/_curses_panel.cpython-33m-x86_64-linux-gnu.so

Is this a Python bug?

----------
components: Extension Modules
messages: 186641
nosy: marco.buttu
priority: normal
severity: normal
status: open
title: ImportError: No module named '_curses'
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 12 18:54:55 2013
From: report at bugs.python.org (Julian Berman)
Date: Fri, 12 Apr 2013 16:54:55 +0000
Subject: [New-bugs-announce] [issue17705] Fill Character cannot be \0
Message-ID: <1365785695.21.0.22745237494.issue17705@psf.upfronthosting.co.za>


New submission from Julian Berman:

The docs say:

"The fill character can be any character other than ?{? or ?}?."

http://docs.python.org/dev/library/string.html#format-specification-mini-language

But:

>>> "{0:\x01>8.2f}".format(12)
'\x01\x01\x0112.00'

whereas:

>>> "{0:\x00>8.2f}".format(12)
'   12.00'

----------
components: Interpreter Core
messages: 186653
nosy: Julian
priority: normal
severity: normal
status: open
title: Fill Character cannot be \0
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr 13 00:37:06 2013
From: report at bugs.python.org (Orion Poplawski)
Date: Fri, 12 Apr 2013 22:37:06 +0000
Subject: [New-bugs-announce] [issue17706] Segfault in PyErr_SetObject
Message-ID: <1365806226.48.0.566850087286.issue17706@psf.upfronthosting.co.za>


New submission from Orion Poplawski:

I'm seeing a segfault running the scipy 0.12 tests against numpy 1.7.1 with python 3.3.1.  The crash is here:

test_ticket_1645 (test_lapack.TestRegression) ... 
Program received signal SIGSEGV, Segmentation fault.
PyErr_SetObject (exception=exception at entry=<type at remote 0x3032fface0>, 
    value=value at entry='On entry to SGERQF parameter number 7 had an illegal value')
    at /usr/src/debug/Python-3.3.1/Python/errors.c:67
67          exc_value = tstate->exc_value;
(gdb) print tstate
$1 = (PyThreadState *) 0x0

So it appears that PyThreadState_GET() is returning NULL and PyErr_SetOject() is not handling that condition.  Not sure if this is a sign of another issue.

(gdb) bt
#0  PyErr_SetObject (exception=exception at entry=<type at remote 0x7ffff7f75ce0>, 
    value=value at entry='On entry to SGERQF parameter number 7 had an illegal value')
    at /usr/src/debug/Python-3.3.1/Python/errors.c:67
#1  0x00007ffff7c93bbf in PyErr_SetString (exception=<type at remote 0x7ffff7f75ce0>, 
    string=string at entry=0x7fffffff8160 "On entry to SGERQF parameter number 7 had an illegal value") at /usr/src/debug/Python-3.3.1/Python/errors.c:125
#2  0x00007fffeea223f1 in xerbla_ (srname=<optimized out>, info=<optimized out>)
    at numpy/linalg/python_xerbla.c:35
#3  0x00007fffee4925d9 in sgerqf_ () from /usr/lib64/atlas/liblapack.so.3
#4  0x00007fffe6d5a56f in f2py_rout__flapack_sgerqf ()
   from /scratch/orion/redhat/BUILDROOT/scipy-0.12.0-1.fc20.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/_flapack.cpython-33m.so
#5  0x00007ffff7bda0cc in PyObject_Call (func=func at entry=<fortran at remote 0x7fffebddc198>, 
    arg=arg at entry=(<numpy.ndarray at remote 0x11a60e0>,), kw=kw at entry={'lwork': 2})
    at /usr/src/debug/Python-3.3.1/Objects/abstract.c:2082
#6  0x00007ffff7c859b2 in ext_do_call (nk=<optimized out>, na=<optimized out>, 
    flags=<optimized out>, pp_stack=0x7fffffff85f8, func=<fortran at remote 0x7fffebddc198>)
    at /usr/src/debug/Python-3.3.1/Python/ceval.c:4406
#7  PyEval_EvalFrameEx (
    f=f at entry=Frame 0x11ae310, for file /usr/lib64/python3.3/unittest/case.py, line 173, in handle (self=<_AssertRaisesContext(test_case=<Dummy(_testMethodName='nop', _cleanups=[], _testMethodDoc=None, _outcomeForDoCleanups=None, _type_equality_funcs={<type at remote 0x7ffff7f8b800>: 'assertMultiLineEqual', <type at remote 0x7ffff7f7d920>: 'assertListEqual', <type at remote 0x7ffff7f80440>: 'assertDictEqual', <type at remote 0x7ffff7f85560>: 'assertTupleEqual', <type at remote 0x7ffff7f843c0>: 'assertSetEqual', <type at remote 0x7ffff7f84220>: 'assertSetEqual'}) at remote 0x7fffecd1c390>, msg=None, obj_name='<fortran object>', expected=<type at remote 0x7ffff7f799c0>, expected_regex=None) at remote 0x7fffe0716cd0>, name='assertRaises', callable_obj=<fortran at remote 0x7fffebddc198>, args=(<numpy.ndarray at remote 0x11a60e0>,), kwargs={'lwork': 2}), 
    throwflag=throwflag at entry=0) at /usr/src/debug/Python-3.3.1/Python/ceval.c:2744
#8  0x00007ffff7c879cc in fast_function (nk=<optimized out>, na=5, n=5, 
    pp_stack=0x7fffffff8770, func=<optimized out>)
    at /usr/src/debug/Python-3.3.1/Python/ceval.c:4179
#9  call_function (oparg=<optimized out>, pp_stack=0x7fffffff8770)
    at /usr/src/debug/Python-3.3.1/Python/ceval.c:4112
..............

it goes on a long ways down.

----------
components: Interpreter Core
messages: 186684
nosy: opoplawski
priority: normal
severity: normal
status: open
title: Segfault in PyErr_SetObject
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 13 03:30:25 2013
From: report at bugs.python.org (Sultan Qasim)
Date: Sat, 13 Apr 2013 01:30:25 +0000
Subject: [New-bugs-announce] [issue17707] Multiprocessing queue get method
	does not block for	short timeouts
Message-ID: <1365816625.92.0.503962460634.issue17707@psf.upfronthosting.co.za>


New submission from Sultan Qasim:

This issue seems to be new in Python 3.3.1. This worked fine in Python 3.3.0 and earlier. I am using fully up-to-date installation of Arch Linux, running the official arch repo's 64 bit build of Python 3.3.1.
This issue is probably a result of the changes to multiprocessing's pipes brought about in solutions to issues #10527 or #16955.

The multiprocessing Queue's get() method on Python 3.3.1 does not block on Linux when a timeout of 1 second or less is specified. I have not tested this on Windows or Mac OS X.

Example Code:
from multiprocessing import Queue
q = Queue()

q.get(True, 0.5)
# Expected result: block for half a second before throwing exception
# Actual result: throws empty exception immediately without waiting

q.get(True, 1)
# Expected result: block for one second before throwing exception
# Actual result: throws empty exception immediately without waiting

q.get(True, 1.00001)
# Expected result: block for just over a second before throwing exception
# Actual result: throws empty exception immediately without waiting

q.get(True, 1.00002)
# Blocks for just over a second, as expected

q.get(True, 2)
# Blocks for two seconds, as expected

----------
components: Library (Lib)
messages: 186687
nosy: sultanqasim
priority: normal
severity: normal
status: open
title: Multiprocessing queue get method does not block for short timeouts
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 13 07:46:48 2013
From: report at bugs.python.org (Masami HIRATA)
Date: Sat, 13 Apr 2013 05:46:48 +0000
Subject: [New-bugs-announce] [issue17708] sys.flags.hash_randomization
	doesn't return correct value
Message-ID: <1365832008.74.0.106201952551.issue17708@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

OS: Windows 7 Starter Edition SP1 (32-bit)
Python: 3.3.1 (python-3.3.1.msi)

It seems that sys.flags.hash_randomization doesn't return correct value

Output:
C:\>set PYTHONHASHSEED=random

C:\>C:\Python33\python.exe
Python 3.3.1 (v3.3.1:d9893d13c628, Apr  6 2013, 20:25:12) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.flags.hash_randomization
1
>>> ^Z


C:\>set PYTHONHASHSEED=1

C:\>C:\Python33\python.exe
Python 3.3.1 (v3.3.1:d9893d13c628, Apr  6 2013, 20:25:12) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.flags.hash_randomization
1
>>> ^Z


C:\>set PYTHONHASHSEED=12345

C:\>C:\Python33\python.exe
...
>>> import sys
>>> sys.flags.hash_randomization
12345
>>> ^Z

Output I Expected:
C:\>set PYTHONHASHSEED=random

C:\>C:\Python33\python.exe
...
>>> import sys
>>> sys.flags.hash_randomization
True
>>> ^Z


C:\>set PYTHONHASHSEED=1

C:\>C:\Python33\python.exe
...
>>> import sys
>>> sys.flags.hash_randomization
False
>>> ^Z


C:\>set PYTHONHASHSEED=12345

C:\>C:\Python33\python.exe
...
>>> import sys
>>> sys.flags.hash_randomization
False
>>> ^Z

----------
components: Library (Lib)
messages: 186693
nosy: msmhrt
priority: normal
severity: normal
status: open
title: sys.flags.hash_randomization doesn't return correct value
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 13 09:18:44 2013
From: report at bugs.python.org (Russell Stuart)
Date: Sat, 13 Apr 2013 07:18:44 +0000
Subject: [New-bugs-announce] [issue17709]
	http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
Message-ID: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>


New submission from Russell Stuart:

.. topic:: http://docs.python.org/2.7/objects.inv doesn't support :func:`repr` or :exc:`Exception`

  A bug report for Python 2.7's docs.

.. _intro:

Bug
===

Running::

  sphinx-build -c conf2.7 -n -b html -E . html

Produces::

  Running Sphinx v1.1.3
  loading intersphinx inventory from http://docs.python.org/2.7/objects.inv...
  building [html]: targets for 1 source files that are out of date
  updating environment: 1 added, 0 changed, 0 removed
  reading sources... [100%] bug                                                                             
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... done
  preparing documents... done
  writing output... [100%] bug                                                                              
  /home/rstuart/zzz/bug.rst:1: WARNING: py:exc reference target not found: Exception
  /home/rstuart/zzz/bug.rst:1: WARNING: py:func reference target not found: repr
  writing additional files... genindex search
  copying static files... done
  dumping search index... done
  dumping object inventory... done
  build succeeded, 2 warnings.

Note the ``WARNING`` lines.  They should not be there.

Running::

  sphinx-build -c conf3.2 -b html -n -E . html

Produces::

  Running Sphinx v1.1.3
  loading intersphinx inventory from http://docs.python.org/3.2/objects.inv...
  building [html]: targets for 1 source files that are out of date
  updating environment: 1 added, 0 changed, 0 removed
  reading sources... [100%] bug                                                                             
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... done
  preparing documents... done
  writing output... [100%] bug                                                                              
  writing additional files... genindex search
  copying static files... done
  dumping search index... done
  dumping object inventory... done
  build succeeded.

I presume this means something is wrong with 
http://docs.python.org/2.7/objects.inv it downloads.

``conf2.7.py``:

  .. include:: conf2.7/conf.py
    :literal:

``conf3.2.py``:

  .. include:: conf3.2/conf.py
    :literal:

----------
assignee: docs at python
components: Documentation
files: bug.rst
messages: 186697
nosy: docs at python, ras
priority: normal
severity: normal
status: open
title: http://docs.python.org/2.7/objects.inv doesn't support :func:`repr` or :exc:`Exception`
versions: Python 2.7
Added file: http://bugs.python.org/file29794/bug.rst

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

From report at bugs.python.org  Sat Apr 13 13:00:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Apr 2013 11:00:22 +0000
Subject: [New-bugs-announce] [issue17710] SystemError in cPickle for
	incorrect input
Message-ID: <1365850822.02.0.920252942398.issue17710@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import cPickle
>>> cPickle.loads(b"S' \np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Negative size passed to PyString_FromStringAndSize
>>> pickle.loads(b"S' \np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython2.7/Lib/pickle.py", line 1382, in loads
    return Unpickler(file).load()
  File "/home/serhiy/py/cpython2.7/Lib/pickle.py", line 858, in load
    dispatch[key](self)
  File "/home/serhiy/py/cpython2.7/Lib/pickle.py", line 966, in load_string
    raise ValueError, "insecure string pickle"
ValueError: insecure string pickle
>>> cPickle.loads(b"S'\np0\n.")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Negative size passed to PyString_FromStringAndSize
>>> pickle.loads(b"S'\np0\n.")
''

Python 3 has the same behavior except C implementation raises UnpicklingError for b"S'\np0\n.".

----------
components: Extension Modules
messages: 186704
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: SystemError in cPickle for incorrect input
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr 13 13:41:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Apr 2013 11:41:49 +0000
Subject: [New-bugs-announce] [issue17711] Persistent id in pickle with
	protocol version 0
Message-ID: <1365853309.55.0.468755952624.issue17711@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Python 2 allows pickling and unpickling non-ascii persistent ids. In Python 3 C implementation of pickle saves persistent ids with protocol version 0 as utf8-encoded strings and loads as bytes.

>>> import pickle, io
>>> class MyPickler(pickle.Pickler):
...     def persistent_id(self, obj):
...         if isinstance(obj, str):
...             return obj
...         return None
... 
>>> class MyUnpickler(pickle.Unpickler):
...     def persistent_load(self, pid):
...         return pid
... 
>>> f = io.BytesIO(); MyPickler(f).dump('\u20ac'); data = f.getvalue()
>>> MyUnpickler(io.BytesIO(data)).load()
'?'
>>> f = io.BytesIO(); MyPickler(f, 0).dump('\u20ac'); data = f.getvalue()
>>> MyUnpickler(io.BytesIO(data)).load()
b'\xe2\x82\xac'
>>> f = io.BytesIO(); MyPickler(f, 0).dump('a'); data = f.getvalue()
>>> MyUnpickler(io.BytesIO(data)).load()
b'a'

Python implementation in Python 3 doesn't works with non-ascii persistant ids at all.

----------
components: Extension Modules, Library (Lib)
messages: 186705
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Persistent id in pickle with protocol version 0
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr 13 14:30:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Apr 2013 12:30:45 +0000
Subject: [New-bugs-announce] [issue17712] test_gdb failures
Message-ID: <1365856245.17.0.785295424505.issue17712@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I'm getting multiple test_gdb failures on a new (XUbuntu 13.04) system:

======================================================================
FAIL: test_basic_command (test.test_gdb.PyLocalsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/33/Lib/test/test_gdb.py", line 822, in test_basic_command
    cmds_after_breakpoint=['py-locals'])
  File "/home/antoine/cpython/33/Lib/test/test_gdb.py", line 170, in get_stack_trace
    self.assertEqual(err, '')
AssertionError: 'warning: no loadable sections found in added symbol-file system-supplied DSO at [truncated]... != ''
- warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000


(all test methods produce the same error)

----------
components: Tests
messages: 186708
nosy: dmalcolm, pitrou
priority: normal
severity: normal
status: open
title: test_gdb failures
type: behavior
versions: Python 3.1, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Apr 13 15:49:57 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 13 Apr 2013 13:49:57 +0000
Subject: [New-bugs-announce] [issue17713] test_logging fails in
	test_compute_rollover_weekly_attime
Message-ID: <1365860997.8.0.335334018643.issue17713@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

I just pulled down the tip of CPython, built it, and ran the tests, and got this failure:

```
======================================================================
FAIL: test_compute_rollover_weekly_attime (test.test_logging.TimedRotatingFileHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ned/python/cpython/Lib/test/test_logging.py", line 3972, in test_compute_rollover_weekly_attime
    wday = datetime.datetime.fromtimestamp(currentTime).weekday()
AssertionError: 388800 != 475200

----------------------------------------------------------------------
Ran 149 tests in 17.142s

FAILED (failures=1, skipped=1)
test test_logging failed
1 test failed:
    test_logging
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/test_logging-2-gimdv3.log' mode='a' encoding='UTF-8'>
```

Others preparing for today's sprint in Boston also had the same problem.  Something to do with timezones?

----------
messages: 186717
nosy: nedbat
priority: normal
severity: normal
status: open
title: test_logging fails in test_compute_rollover_weekly_attime

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

From report at bugs.python.org  Sat Apr 13 17:39:29 2013
From: report at bugs.python.org (Alessandro Piccione)
Date: Sat, 13 Apr 2013 15:39:29 +0000
Subject: [New-bugs-announce] [issue17714] str.encode('base64') add trailing
	new line character is	not documented
Message-ID: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za>


New submission from Alessandro Piccione:

str.encode() with 'base64' as argument add a trailing new line character to the returned string. This is the difference from base64.b64encode(str) (that is used internally).

This is not documented in str.encode()
http://docs.python.org/2/library/stdtypes.html?highlight=encode#str.encode

Instead it is perfectly documented for base64.encodestring()
http://docs.python.org/2/library/base64.html#base64.encodestring

----------
messages: 186734
nosy: alex.75
priority: normal
severity: normal
status: open
title: str.encode('base64') add trailing new line character is not documented
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 13 17:57:33 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Apr 2013 15:57:33 +0000
Subject: [New-bugs-announce] [issue17715] Raising an exception in __trunc__
	gives a segmentation	fault.
Message-ID: <1365868653.81.0.515318912237.issue17715@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Python 3.4.0a0 (default:838fdf3bb0c6, Apr 13 2013, 16:54:22) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     def __trunc__(self): 1/0
... 
>>> int(A())
Segmentation fault

It looks as though the problem is in PyNumber_Long, where there's an unchecked return value for PyEval_CallObject.

----------
assignee: mark.dickinson
components: Interpreter Core
messages: 186735
nosy: mark.dickinson
priority: high
severity: normal
status: open
title: Raising an exception in __trunc__ gives a segmentation fault.
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 13 18:04:57 2013
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 13 Apr 2013 16:04:57 +0000
Subject: [New-bugs-announce] [issue17716] IMPORTANT - Process corruption on
	partly failed imports
Message-ID: <1365869097.02.0.582677403017.issue17716@psf.upfronthosting.co.za>


New submission from Pascal Chambon:

Hello,

we've encountered several times a very nasty bug on our framework, several times tests or even production code (served by mod_wsgi) ended up in a broken state, where imports like "from . import processing_exceptions", which were NOT in circular imports and were 100% existing submodules, raised exceptions like "ImportError: cannot import name processing_exceptions". Restarting the test/server fixed it, and we never knew what happened.

I've crossed several forum threads on similar issues, only recently did I find one which gave a way to reproduce the bug:
http://stackoverflow.com/questions/12830901/why-does-import-error-change-to-cannot-import-name-on-the-second-import

So here attached is a python2 sample (python3 has the same pb), showing the bug (just run their test_import.py)

What happens here, is that a package "mypkg" fails to get imported due to an exception (eg. temporarily failuure of DB), but only AFTER successfully importing a submodule mypkg.module_a.
Thus, "mypkg.module_a" IS loaded and stays in sys.modules, but "mypkg" is erased from sys.modules (like the doc on python imports describes it).

The next time we try, from within the same application, to import "mypkg", and we cross "from mypkg import module_a" in the mypkg's __init__.py code, it SEEMS that the import system checks sys.modules, and seeing "mypkg.module_a" in it, it THINKS that necessarily mypkg is already initialized and contains a name "module_a" in its global namespace. Thus the "cannot import name processing_exceptions" error.

Importing "module_a" as an absolute or relative import changes nothing, however doing "import mypkg.module_a" solves the problem (dunno why).

Another workaround is to cleanup sys.modules in mypkg/__init__.py, to ensure that a previously failed attempt at importing the package modules doesn't hinder us.
    
    # on top of "mypkg/__init__.py"
    exceeding_modules = [k for k in sys.modules.keys() if k.startswith("mypkg.")]
    for k in exceeding_modules:
        del sys.modules[k]
        
Anyway, I don't know enough python's import internals to understand why, exactly, on second import attempt, the system tries a kind of faulty getattr(mypkg, "module_a"), instead of simply returning sys.modules["mypkg.module_a"] which exists.
Could anyone help with that ? 
That's a very damaging issue, imo, since webserver workers can reach a completely broken state because of that.

PS: more generally, I guess python users lack insight on the behaviour of "from xxx import yyy", especially when yyy is both a real submodule of xxx and a variable initialized in xxx/__init__.py (it seems the real module overrides the variable), or when the __all__ list of xxx could prevent the import of a submodule of xxx by not including it.
Provided I better understand the workflow of all these stuffs - that have quite moved recently I heard - I'd be willing to summarize it for the python docs.

----------
components: Interpreter Core
files: ImportFailPy2.zip
messages: 186738
nosy: Pascal.Chambon
priority: normal
severity: normal
status: open
title: IMPORTANT - Process corruption on partly failed imports
type: behavior
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/file29798/ImportFailPy2.zip

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

From report at bugs.python.org  Sat Apr 13 18:34:32 2013
From: report at bugs.python.org (John Ehresman)
Date: Sat, 13 Apr 2013 16:34:32 +0000
Subject: [New-bugs-announce] [issue17717] Set up nasm from external.bat
Message-ID: <1365870872.82.0.912332979443.issue17717@psf.upfronthosting.co.za>


New submission from John Ehresman:

It would be nice for Tools\buildbot\external.bat to set a copy of nasm up to use.  Is there a reason this is not done?

----------
components: Windows
messages: 186752
nosy: jpe
priority: normal
severity: normal
status: open
title: Set up nasm from external.bat
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 13 19:17:57 2013
From: report at bugs.python.org (Stephen Tu)
Date: Sat, 13 Apr 2013 17:17:57 +0000
Subject: [New-bugs-announce] [issue17718] boolop constant checking for
	if/while
Message-ID: <1365873477.58.0.16753210186.issue17718@psf.upfronthosting.co.za>


New submission from Stephen Tu:

Here's a simple patch to optimize away constant boolean conjunctions/disjunctions. for example:

def foo():
    if 1 and 0:
        print("hi")

now disassembles into:
  7           0 LOAD_CONST               0 (None) 
              3 RETURN_VALUE 

while I realize more general techniques for achieving this have been proposed (ie http://bugs.python.org/issue1346238), this is a very simple, self-contained patch.

----------
components: Interpreter Core
files: constcheck.patch
keywords: patch
messages: 186767
nosy: Stephen.Tu
priority: normal
severity: normal
status: open
title: boolop constant checking for if/while
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file29807/constcheck.patch

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

From report at bugs.python.org  Sat Apr 13 19:22:57 2013
From: report at bugs.python.org (Kent Johnson)
Date: Sat, 13 Apr 2013 17:22:57 +0000
Subject: [New-bugs-announce] [issue17719] IDLE help text refers to incorrect
	Python version
Message-ID: <1365873777.93.0.00334201360325.issue17719@psf.upfronthosting.co.za>


New submission from Kent Johnson:

The IDLE help text says, "Running without a subprocess: (DEPRECATED in Python 3.5 see Issue 16123)." According to the referenced issue, this feature is scheduled to be deprecated in *3.4* and *removed* in 3.5. The attached patch corrects the help text.

----------
assignee: docs at python
components: Documentation
files: deprecated_in_3.4.patch
keywords: patch
messages: 186769
nosy: docs at python, kjohnson
priority: normal
severity: normal
status: open
title: IDLE help text refers to incorrect Python version
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file29808/deprecated_in_3.4.patch

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

From report at bugs.python.org  Sat Apr 13 20:04:49 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 13 Apr 2013 18:04:49 +0000
Subject: [New-bugs-announce] [issue17720] pickle.py's load_appends should
	call append() on objects	other than lists
Message-ID: <1365876289.91.0.454785839611.issue17720@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

In pickle.py, load_appends is currently defined as

    def load_appends(self):
        stack = self.stack
        mark = self.marker()
        list = stack[mark - 1]
        list.extend(stack[mark + 1:])
        del stack[mark:]

However, according to the spec of APPENDS, it should actually be:

    def load_appends(self):
        obj = stack[mark - 1]
        items = stack[mark + 1:]
        if isinstance(obj, list):
            obj.extend(items)
        else:
            for item in items:
                obj.append(item)

This will match with the current behaviour of _pickle.

----------
assignee: alexandre.vassalotti
components: Library (Lib)
files: loads_appends.patch
keywords: patch
messages: 186774
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: pickle.py's load_appends should call append() on objects other than lists
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29810/loads_appends.patch

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

From report at bugs.python.org  Sat Apr 13 20:07:59 2013
From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=)
Date: Sat, 13 Apr 2013 18:07:59 +0000
Subject: [New-bugs-announce] [issue17721] Help button on preference window
	doesn't work
Message-ID: <1365876479.31.0.960204905759.issue17721@psf.upfronthosting.co.za>


New submission from Guilherme Sim?es:

The Help button on the Preferences windows does not do anything. Maybe I can fix it, but I don't know what it was supposed to do in the first place. For now it probably should be removed.

----------
components: IDLE
messages: 186775
nosy: Guilherme.Sim?es
priority: normal
severity: normal
status: open
title: Help button on preference window doesn't work
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 13 22:02:20 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Apr 2013 20:02:20 +0000
Subject: [New-bugs-announce] [issue17722] 'round' function doesn't honour a
	descriptor __round__
Message-ID: <1365883340.94.0.61379859162.issue17722@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Benjamin pointed out on #python-dev that the builtin round function should be using _PyObject_LookupSpecial to look up the __round__ method.  Here's a fix.

----------
components: Interpreter Core
files: round_descriptor.patch
keywords: patch
messages: 186813
nosy: mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: 'round' function doesn't honour a descriptor __round__
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29820/round_descriptor.patch

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

From report at bugs.python.org  Sat Apr 13 23:10:54 2013
From: report at bugs.python.org (John Ehresman)
Date: Sat, 13 Apr 2013 21:10:54 +0000
Subject: [New-bugs-announce] [issue17723] Use FileRead and FileWrite in
	fileio.c on Windows
Message-ID: <1365887454.15.0.737377999184.issue17723@psf.upfronthosting.co.za>


New submission from John Ehresman:

File object's can use the win32 api FileRead and FileWrite instead of the CRT's read & write function.  This would eliminate the need to set the mode to binary on stdin & stdout, which is the underlying cause of issue 16587.  This could also possibly be the basis of adding nonblocking functionality.  An initial patch is attached, but I still need to verify what this does to the CRT mode of files that are opened by python (rather than already be opened, like stdin & stdout are).

----------
files: use_filerw.patch
keywords: patch
messages: 186849
nosy: jpe
priority: normal
severity: normal
status: open
title: Use FileRead and FileWrite in fileio.c on Windows
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29829/use_filerw.patch

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

From report at bugs.python.org  Sat Apr 13 23:17:28 2013
From: report at bugs.python.org (Max Mautner)
Date: Sat, 13 Apr 2013 21:17:28 +0000
Subject: [New-bugs-announce] [issue17724] urllib -- add_handler method
	refactoring for clarity
Message-ID: <1365887848.07.0.0995479400533.issue17724@psf.upfronthosting.co.za>


New submission from Max Mautner:

Response handlers are registered with the OpenerDirector class in the urllib.request module using the add_handler method--it's a convoluted method that I refactored for legibility's sake.

----------
files: urllib_add_handler.patch
keywords: patch
messages: 186853
nosy: Max.Mautner
priority: normal
severity: normal
status: open
title: urllib -- add_handler method refactoring for clarity
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29831/urllib_add_handler.patch

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

From report at bugs.python.org  Sun Apr 14 09:09:27 2013
From: report at bugs.python.org (Kyle Simpson)
Date: Sun, 14 Apr 2013 07:09:27 +0000
Subject: [New-bugs-announce] [issue17725] English mistake in Extending and
	Embedding Python doc	page.
Message-ID: <1365923367.93.0.414383739407.issue17725@psf.upfronthosting.co.za>


New submission from Kyle Simpson:

The second sentence in http://docs.python.org/3/extending/index.html says:

  Those modules can define new functions but also new
  object types and their methods.

The word "but" doesn't make sense here. I suppose that the
author meant to write:

  Those modules can not only define new functions but
  also new object types and their methods.

----------
assignee: docs at python
components: Documentation
messages: 186886
nosy: Kyle.Simpson, docs at python
priority: normal
severity: normal
status: open
title: English mistake in Extending and Embedding Python doc page.

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

From report at bugs.python.org  Sun Apr 14 10:26:43 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 14 Apr 2013 08:26:43 +0000
Subject: [New-bugs-announce] [issue17726] faq/design: improve clarity
Message-ID: <1365928003.07.0.655847572974.issue17726@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

I puzzled a bit on what that sentence meant.

----------
assignee: docs at python
components: Documentation
files: diff
messages: 186891
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: faq/design: improve clarity
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29848/diff

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

From report at bugs.python.org  Sun Apr 14 10:43:34 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 08:43:34 +0000
Subject: [New-bugs-announce] [issue17727] document that some distributions
	change site.py defaults
Message-ID: <1365929014.79.0.72904930991.issue17727@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>From the docs@ list:
"""
Dear all,

the first paragraph of the documentation for the site module states that site.py constructs four directories using a head and tail part, and that

one of the tail parts would be lib/pythonX.Y/site-packages on UNIX/Mac.

However, in my Python 3.2 installation on Ubuntu 12.04 this is actually lib/python3/dist-packages (so no .Y and a different subdirectory) !

This is also stated in the module?s doc string.

I don?t know why the Python documentation says something else, but that should be fixed.
"""

Attached a patch to explain why the defaults may look different on some distributions.  Please review.

----------
assignee: docs at python
components: Documentation
files: site-patch.diff
keywords: patch
messages: 186897
nosy: barry, docs at python, doko, georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: document that some distributions change site.py defaults
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29849/site-patch.diff

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

From report at bugs.python.org  Sun Apr 14 12:07:44 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:07:44 +0000
Subject: [New-bugs-announce] [issue17728] format() default precisions
	undocumented
Message-ID: <1365934064.51.0.124560833588.issue17728@psf.upfronthosting.co.za>


New submission from Georg Brandl:

The docs for % formatting say what the default precision for presentation types e, f, g is.  I couldn't find the same for format().

----------
assignee: eric.smith
components: Documentation
messages: 186902
nosy: eric.smith, georg.brandl
priority: normal
severity: normal
status: open
title: format() default precisions undocumented
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr 14 12:24:39 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Apr 2013 10:24:39 +0000
Subject: [New-bugs-announce] [issue17729] advocacy howto improvements
Message-ID: <1365935079.06.0.131915757823.issue17729@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>From docs@:

"""
The howto-advocacy is interesting.

You might consider removing the following sentences, which I found personally gave me a negative impression:

"python hasn't had all the publicity" to my mind gives the impression that python is not popular.

"python is definitely not a toy language that only usable for small tasks". This gives to me the impression that you feel many people think it is.

Section "who's going to support it?" a company needs to be able to call someone, pay for support right now, within one hour, not on a maybe basis. I feel either remove this section or suggest links to three companies providing python support.

Section "python is freely available , how good can it be?" I felt what I wanted to see was not that Linux and apache are good, but why python is good.
"""

I think the advocacy howto was written quite a while ago and could use a makeover.

----------
assignee: docs at python
components: Documentation
messages: 186903
nosy: akuchling, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: advocacy howto improvements
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr 14 13:48:37 2013
From: report at bugs.python.org (Drekin)
Date: Sun, 14 Apr 2013 11:48:37 +0000
Subject: [New-bugs-announce] [issue17730] code.interact() doesn't support no
	banner
Message-ID: <1365940117.84.0.770011673155.issue17730@psf.upfronthosting.co.za>


New submission from Drekin:

Currently, there is no way to run code.interact without a banner ? empty string still means to print an empty line. If I want that behaviour, I must subclass code.InteractiveConsole and reimplement whole .interact method including the repl logic just not to print a banner. Maybe there should be .print_banner method for this.

----------
components: Library (Lib)
messages: 186914
nosy: Drekin
priority: normal
severity: normal
status: open
title: code.interact() doesn't support no banner
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr 14 19:52:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Apr 2013 17:52:55 +0000
Subject: [New-bugs-announce] [issue17731] test_iter_importers intermittent
	failure in test_pkgutil
Message-ID: <1365961975.09.0.567055243786.issue17731@psf.upfronthosting.co.za>


New submission from R. David Murray:

A buildbot produced the following traceback, but the test passed when re-run.  

http://buildbot.python.org/all/builders/x86%20Gentoo%203.3/builds/630/steps/test/logs/stdio

test_loader_deprecated (test.test_pkgutil.ImportlibMigrationTests) ... ok

======================================================================
ERROR: test_iter_importers (test.test_pkgutil.ExtendPathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1521, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildslave/3.3.murray-gentoo/build/Lib/test/test_pkgutil.py", line 206, in test_iter_importers
    importlib.import_module(fullname)
  File "/var/lib/buildslave/3.3.murray-gentoo/build/Lib/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1586, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1567, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1524, in _find_and_load_unlocked
ImportError: No module named 'spam.eggs'; spam is not a package

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildslave/3.3.murray-gentoo/build/Lib/test/test_pkgutil.py", line 226, in test_iter_importers
    del sys.modules['spam.eggs']
KeyError: 'spam.eggs'

----------
keywords: buildbot
messages: 186938
nosy: ncoghlan, r.david.murray
priority: normal
severity: normal
status: open
title: test_iter_importers intermittent failure in test_pkgutil
type: behavior

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

From report at bugs.python.org  Sun Apr 14 20:10:32 2013
From: report at bugs.python.org (Nick Sloan)
Date: Sun, 14 Apr 2013 18:10:32 +0000
Subject: [New-bugs-announce] [issue17732] distutils.cfg Can Break venv
Message-ID: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za>


New submission from Nick Sloan:

When distutils.cfg defines an install-lib, it will be used within virtual environments created using venv as well, which makes it impossible to install things with setup.py or similar.

Steps to reproduce:

Create a distutils.cfg file and set a value for install-lib.

Create a virtual environment: $pyvenv myvenv

Activate that environment: $source myvenv/bin/activate

Attempt to install something: $python distribute_setup.py

It will attempt to install in the lib-install directory, and should fail with an error that the directory is not on the python path. This issue affects python3 from the mac homebrew project, which bundles a distutil.cfg, thus breaking pyvenv by default.

----------
assignee: eric.araujo
components: Distutils
messages: 186942
nosy: eric.araujo, nicksloan, tarek
priority: normal
severity: normal
status: open
title: distutils.cfg Can Break venv
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 14 23:26:59 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Sun, 14 Apr 2013 21:26:59 +0000
Subject: [New-bugs-announce] [issue17733] Unit tests for RFC 2231 parsing
	code
Message-ID: <1365974819.78.0.85095518093.issue17733@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
components: Tests
nosy: Ankur.Ankan, r.david.murray
priority: normal
severity: normal
status: open
title: Unit tests for RFC 2231 parsing code
type: enhancement

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

From report at bugs.python.org  Mon Apr 15 14:40:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 15 Apr 2013 12:40:13 +0000
Subject: [New-bugs-announce] [issue17734] Failure when running test_builtin
	after test_genexps
Message-ID: <1366029613.93.0.971367432491.issue17734@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I'm getting a failure in test_builtin when running the following:

    ./python -m test -w test_genexps test_builtin

======================================================================
FAIL: test_input_tty_non_ascii (test.test_builtin.BuiltinTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_builtin.py", line 1176, in test_input_tty_non_ascii
    self.check_input_tty("prompt?", b"quux\xe9", "utf-8")
  File "/home/ncoghlan/devel/py3k/Lib/test/test_builtin.py", line 1167, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +


======================================================================
FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.BuiltinTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/test/test_builtin.py", line 1180, in test_input_tty_non_ascii_unicode_errors
    self.check_input_tty("prompt?", b"quux\xe9", "ascii")
  File "/home/ncoghlan/devel/py3k/Lib/test/test_builtin.py", line 1167, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +

The problem persists after a make clean and rebuild.

----------
messages: 186979
nosy: haypo, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Failure when running test_builtin after test_genexps
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 15 14:52:20 2013
From: report at bugs.python.org (Kyle Simpson)
Date: Mon, 15 Apr 2013 12:52:20 +0000
Subject: [New-bugs-announce] [issue17735] inspect.findsource throws
	IndexError
Message-ID: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>


New submission from Kyle Simpson:

Here is one way to reproduce this bug:

1. Create a module file (bug.py in this example)

def func():
    pass

2. Run Python

>>> import bug
>>> help(bug)

3. Edit bug.py

def func():
    pass

def newfunc():
    pass

4. Use the same Python interpreter as in step 2

>>> reload(bug)
>>> help(bug)

5. Observe traceback

  [..snip..]
  File "C:\Python27\lib\inspect.py", line 578, in findsource
    if pat.match(lines[lnum]): break
IndexError: list index out of range


Note: A related but different issue is http://bugs.python.org/issue1218234.

----------
components: Library (Lib)
messages: 186983
nosy: Kyle.Simpson
priority: normal
severity: normal
status: open
title: inspect.findsource throws IndexError
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Apr 15 15:06:52 2013
From: report at bugs.python.org (Jonas Wagner)
Date: Mon, 15 Apr 2013 13:06:52 +0000
Subject: [New-bugs-announce] [issue17736] Misleading method comment in
	_elementtree.c :	get_attrib_from_keywords
Message-ID: <1366031212.38.0.552798611166.issue17736@psf.upfronthosting.co.za>


New submission from Jonas Wagner:

The attached patch corrects a wrong method comment in _elementtree.c. It happened to be at Line 316, and was thus discovered by random sampling. [1]

[1] http://www-cs-faculty.stanford.edu/~uno/316.html

----------
components: Extension Modules
files: elementtree_get_attrib_from_keywords.patch
keywords: patch
messages: 186985
nosy: Sjlver
priority: normal
severity: normal
status: open
title: Misleading method comment in _elementtree.c : get_attrib_from_keywords
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29864/elementtree_get_attrib_from_keywords.patch

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

From report at bugs.python.org  Mon Apr 15 15:41:08 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Mon, 15 Apr 2013 13:41:08 +0000
Subject: [New-bugs-announce] [issue17737] test_gdb fails on armv7hl
Message-ID: <1366033268.62.0.309892862388.issue17737@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

Hi,
it seems that test_gdb fails on armv7hl on Fedora 19 and 20 [1] (I'm also tracking my notes of the bug there). Basically, the problem seems to come down to PyObjectPtr.subclass_from_type (file python-gdb.py) returning different values for members of the stack trace (compared to successful builds - see [3] for x86_64 successful build and [4] for armv7hl failed build).
The two failed tests fail with:

======================================================================
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 678, in test_up_at_top
    cmds_after_breakpoint=['py-up'] * 4)
  File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 213, in get_stack_trace
    self.assertEqual(err, '')
AssertionError: "Python Exception <class '__main__.NullPyObjectPtr'> <__main__.PyFrameObjectPtr  [truncated]... != ''
- Python Exception <class '__main__.NullPyObjectPtr'> <__main__.PyFrameObjectPtr object at 0x23a6db0>: 
- Error occurred in Python command: <__main__.PyFrameObjectPtr object at 0x23a6db0>
======================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 759, in test_threads
    cmds_after_breakpoint=['thread apply all py-bt'])
  File "/builddir/build/BUILD/Python-3.3.1/Lib/test/test_gdb.py", line 213, in get_stack_trace
    self.assertEqual(err, '')
AssertionError: "Python Exception <class 'gdb.error'> There is no member named co_name.: \nError [truncated]... != ''
- Python Exception <class 'gdb.error'> There is no member named co_name.: 
- Error occurred in Python command: There is no member named co_name.
----------------------------------------------------------------------

The whole build log is accessible at [2]. Any clues would be appreciated. Thanks.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=951802
[2] http://arm.koji.fedoraproject.org//work/tasks/2722/1712722/build.log
[3] https://gist.github.com/bkabrda/5387906
[4] https://gist.github.com/bkabrda/5387908

----------
components: Tests
messages: 186987
nosy: bkabrda
priority: normal
severity: normal
status: open
title: test_gdb fails on armv7hl
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 15 16:10:24 2013
From: report at bugs.python.org (Jonas Wagner)
Date: Mon, 15 Apr 2013 14:10:24 +0000
Subject: [New-bugs-announce] [issue17738] Unnecessary "if" in SHA1_copy
Message-ID: <1366035024.21.0.783784062683.issue17738@psf.upfronthosting.co.za>


New submission from Jonas Wagner:

I'm puzzled by the following code in SHA1_copy (at python/Modules/sha1module.c:320

    if (Py_TYPE(self) == &SHA1type) {
        if ( (newobj = newSHA1object())==NULL)
            return NULL;
    } else {
        if ( (newobj = newSHA1object())==NULL)
            return NULL;
    }

Both branches of the if-statement are identical; it would seem that the if is unnecessary. Its condition does not have any side effect. Attached is a patch that simplifies the code.

This code happened to be at Line 316, and was thus discovered by random sampling. [1]

[1] http://www-cs-faculty.stanford.edu/~uno/316.html

----------
components: Extension Modules
files: sha1copy.patch
keywords: patch
messages: 186992
nosy: Sjlver
priority: normal
severity: normal
status: open
title: Unnecessary "if" in SHA1_copy
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29866/sha1copy.patch

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

From report at bugs.python.org  Mon Apr 15 17:14:54 2013
From: report at bugs.python.org (David D Lowe)
Date: Mon, 15 Apr 2013 15:14:54 +0000
Subject: [New-bugs-announce] [issue17739] ssl.SSLSocket.getpeercert does not
	return client	certificate
Message-ID: <1366038894.17.0.187002314395.issue17739@psf.upfronthosting.co.za>


New submission from David D Lowe:

The documentation for ssl.SSLSocket.getpeercert states:

> If the binary_form parameter is True, and a certificate was provided, this method returns the DER-encoded form of the entire certificate as a sequence of bytes, or None if the peer did not provide a certificate. This return value is independent of validation; if validation was required (CERT_OPTIONAL or CERT_REQUIRED), it will have been validated, but if CERT_NONE was used to establish the connection, the certificate, if present, will not have been validated.

However, in the case that validation is not required, getpeercert does not return a certificate, even when binary_form is set to True.

----------
components: Library (Lib)
files: test.tar.gz
messages: 186999
nosy: Flimm
priority: normal
severity: normal
status: open
title: ssl.SSLSocket.getpeercert does not return client certificate
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file29867/test.tar.gz

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

From report at bugs.python.org  Mon Apr 15 20:06:48 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 15 Apr 2013 18:06:48 +0000
Subject: [New-bugs-announce] [issue17740] :func:`socket` in socket.rst links
	to socket module, not socket.socket
Message-ID: <1366049208.35.0.954231970702.issue17740@psf.upfronthosting.co.za>


New submission from Zachary Ware:

In Doc/library/socket.rst, :func:`socket` links to #module-socket, not #socket.socket.  The attached patch changes all occurances of :func:`socket` to :func:`~socket.socket`, except the first one which keeps the explicit module name (no ~).

----------
assignee: docs at python
components: Documentation
files: socket_func_link.diff
keywords: patch
messages: 187009
nosy: docs at python, zach.ware
priority: normal
severity: normal
status: open
title: :func:`socket` in socket.rst links to socket module, not socket.socket
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29871/socket_func_link.diff

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

From report at bugs.python.org  Mon Apr 15 22:49:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Apr 2013 20:49:42 +0000
Subject: [New-bugs-announce] [issue17741] event-driven XML parser
Message-ID: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

iterparse() is a blocking operation. It is not really suitable for event-driven applications (e.g. non-blocking I/O). Here is a patch adding a IncrementalParser class.

----------
components: Library (Lib)
files: etree_incparser.patch
keywords: patch
messages: 187029
nosy: eli.bendersky, flox, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: event-driven XML parser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29874/etree_incparser.patch

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

From report at bugs.python.org  Tue Apr 16 00:03:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Apr 2013 22:03:35 +0000
Subject: [New-bugs-announce] [issue17742] Add _PyBytesWriter API
Message-ID: <1366063415.31.0.505871872027.issue17742@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3.3, I added _PyUnicodeWriter API to factorize code handling a Unicode "buffer", just the code to allocate memory and resize the buffer if needed.

I propose to do the same with a new _PyBytesWriter API. The API is very similar to _PyUnicodeWriter:

 * _PyBytesWriter_Init(writer)
 * _PyBytesWriter_Prepare(writer, count)
 * _PyBytesWriter_WriteStr(writer, bytes_obj)
 * _PyBytesWriter_WriteChar(writer, ch)
 * _PyBytesWriter_Finish(writer)
 * _PyBytesWriter_Dealloc(writer)

The patch changes ASCII, Latin1, UTF-8 and charmap encoders to use _PyBytesWriter API. A second patch changes CJK encoders.

I did not run a benchmark yet. I wrote a patch to factorize the code, not the make the code faster.

Notes on performances:

 * I peek the "small buffer allocated on the stack" idea from UTF-8 encoder, but the smaller buffer is always 500 bytes (instead of a size depending on the Unicode maximum character of the input Unicode string)
 * _PyBytesWriter overallocates by 25% (when overallocation is enabled), whereas charmap encoders doubles the buffer:

    /* exponentially overallocate to minimize reallocations */
    if (requiredsize < 2*outsize)
        requiredsize = 2*outsize;

 * I didn't check if the allocation size is the same with the patch. min_size and overallocate attributes should be set correctly to not make the code slower.
 * The code writing a single into a _PyUnicodeWriter buffer is inlined in unicodeobject.c. _PyBytesWriter API does not provide inlined function for the same purpose.

----------
files: bytes_writer.patch
keywords: patch
messages: 187035
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add _PyBytesWriter API
versions: Python 3.4
Added file: http://bugs.python.org/file29877/bytes_writer.patch

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

From report at bugs.python.org  Tue Apr 16 00:12:43 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 15 Apr 2013 22:12:43 +0000
Subject: [New-bugs-announce] [issue17743] Use extended syntax of `set`
	command in	activate.bat/deactivate.bat batch files.
Message-ID: <1366063963.5.0.506967251468.issue17743@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

This makes it possible to handle paths/usernames with special characters - see https://github.com/pypa/virtualenv/pull/352

----------
components: Library (Lib)
messages: 187037
nosy: piotr.dobrogost, vinay.sajip
priority: normal
severity: normal
status: open
title: Use extended syntax of `set` command in activate.bat/deactivate.bat batch files.
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 00:14:31 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 15 Apr 2013 22:14:31 +0000
Subject: [New-bugs-announce] [issue17744] Unset VIRTUAL_ENV environment
	variable in deactivate.bat
Message-ID: <1366064071.06.0.700925428013.issue17744@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

activate.bat sets VIRTUAL_ENV environment variable. This variable is treated as a sign that virtualenv is active. For this reason deactivate.bat should unset this variable. See https://github.com/pypa/virtualenv/pull/364

----------
components: Library (Lib)
messages: 187038
nosy: piotr.dobrogost, vinay.sajip
priority: normal
severity: normal
status: open
title: Unset VIRTUAL_ENV environment variable in deactivate.bat
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 02:01:03 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 16 Apr 2013 00:01:03 +0000
Subject: [New-bugs-announce] [issue17745] "packaging" no longer planned to
	be included
Message-ID: <1366070463.53.0.324723238706.issue17745@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

attached patch reflects current reality (me assuming that PEPs are living documents)

----------
assignee: docs at python
components: Documentation
files: diff
messages: 187040
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: "packaging" no longer planned to be included
Added file: http://bugs.python.org/file29879/diff

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

From report at bugs.python.org  Tue Apr 16 10:13:18 2013
From: report at bugs.python.org (Jean-Baptiste Lallement)
Date: Tue, 16 Apr 2013 08:13:18 +0000
Subject: [New-bugs-announce] [issue17746]
	test_shutil.TestWhich.test_non_matching_mode fails
	when	running as root
Message-ID: <1366099998.54.0.409643145074.issue17746@psf.upfronthosting.co.za>


New submission from Jean-Baptiste Lallement:

The test test_shutil.TestWhich.test_non_matching_mode fails when running as root because the temporary file is always writeable for this user.

To reproduce on linux:
$ sudo python3.3 -E -Wd -tt /usr/lib/python3.3/test/regrtest.py -v -w test_shutil
[...]
======================================================================
FAIL: test_non_matching_mode (test.test_shutil.TestWhich)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_shutil.py", line 1334, in test_non_matching_mode
    self.assertIsNone(rv)
AssertionError: '/tmp/Tmpnf1xg5/Tmptzup_q.Exe' is not None

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

Possible solutions:
- skip the test when running as root
- search for a file with executable bit set instead of writeable
- set immutable attribute on the file

----------
components: Tests
files: test_shutil.log
messages: 187054
nosy: jibel
priority: normal
severity: normal
status: open
title: test_shutil.TestWhich.test_non_matching_mode fails when running as root
versions: Python 3.3
Added file: http://bugs.python.org/file29882/test_shutil.log

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

From report at bugs.python.org  Tue Apr 16 11:20:07 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 16 Apr 2013 09:20:07 +0000
Subject: [New-bugs-announce] [issue17747] Deprecate pickle fast mode
Message-ID: <1366104007.06.0.988369979601.issue17747@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

Pickle fast mode is currently a deprecated feature of the Pickler class used to disable its memoization mechanism. It was used mainly to create smaller output by not emitting a PUT opcode for each object saved. Unfortunately, this mode only worked with non-cyclic data structures. If it encounters a such structure, this will result in a recursion exceed error (or a stack overflow if we are unlucky).

However, if correctly used, the fast mode is indeed faster.

./perf.py -b fastpickle ../cpython/python.exe ../fastmode/python.exe
Running fastpickle...
INFO:root:Running ../fastmode/python.exe ./performance/bm_pickle.py -n 50 --use_cpickle pickle
INFO:root:Running ../cpython/python.exe ./performance/bm_pickle.py -n 50 --use_cpickle pickle

Report on Darwin avassalotti.local 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan  6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64 i386
Total CPU cores: 4

### fastpickle ###
Min: 0.588284 -> 0.466613: 1.26x faster
Avg: 0.599152 -> 0.476224: 1.26x faster
Significant (t=70.69)
Stddev: 0.00862 -> 0.00877: 1.0173x larger
Timeline: http://tinyurl.com/btrxdm9

Anyhow, I am not convinced the mode is worth keeping for such limited use cases. The feature was undocumented throughout Python 2.x. So it found very few users if any. And it has currently no test coverage at all. So, in my opinion, the feature is at moment more a maintenance burden than anything else.

Now, if we are to deprecate it, I propose we change fast mode to do nothing and leave the 'fast' attribute on Pickler to not break any code that might use it. We should also emit a warning whenever the attribute is set.

----------
assignee: alexandre.vassalotti
components: Library (Lib)
keywords: needs review
messages: 187059
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate pickle fast mode
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Apr 16 11:22:52 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 16 Apr 2013 09:22:52 +0000
Subject: [New-bugs-announce] [issue17748] Condition.wait timeout can't be
	set to more than 50 ms
Message-ID: <1366104172.5.0.472723952105.issue17748@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

On Python 2, Condition.wait timeout is always taken as

min(delay * 2, remaining, .05)

which means it cannot be longer than 50 ms. I don't see a reason for this and AFAIK this is no longer true for Python 3, where timeout can be arbitrarily long. Would it be possible to replace the min() call with just "remaining" completely? If not, would it at least be possible to add an argument to wait(), that would trigger this behaviour (something like patch suggested by Jaroslav Skarvada [1] who reported this issue at [2])?

Thanks.

[1] https://bugzilla.redhat.com/attachment.cgi?id=736029&action=diff
[2] https://bugzilla.redhat.com/show_bug.cgi?id=917709

----------
components: Library (Lib)
messages: 187060
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Condition.wait timeout can't be set to more than 50 ms
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 16 11:30:28 2013
From: report at bugs.python.org (Fabian)
Date: Tue, 16 Apr 2013 09:30:28 +0000
Subject: [New-bugs-announce] [issue17749] root logging functions break
	logger configuration
Message-ID: <1366104628.63.0.334199445392.issue17749@psf.upfronthosting.co.za>


New submission from Fabian:

If I get and configure a named logger in the main module and another module that is imported uses the root logging functions (e.g., logging.info("Hello World!")) somehow affects the configuration of the first (named) logger.

The file m1.py defines the logger "testlogger" and then imports the module m2.py. In m2.py the root logger is used through logging.info(...). This message apparantly doesn't appear anywhere.

After the import in m1.py the previously defined logger is used through logger.info(...). This message appears (formatted) in the logfile:

2013-04-16 11:23:56,231   INFO   Hello from __main__

and (unformatted) at stdout:

INFO:testlogger:Hello from __main__

I did not expect this behavior, therefore I reported this bug. In my expectation the call to logging.info() should not affect the behavior of the named and configured logger.

Main module (m1.py):

import logging

def setup_logging():
    # made this a function to avoid cluttering the global namespace
    logger = logging.getLogger("testlogger")
    logger.setLevel(logging.DEBUG)
    formatter = logging.Formatter('%(asctime)s   %(levelname)s   %(message)s')
    handler = (logging.FileHandler("testlog.log"),
               logging.StreamHandler())
    handler = handler[0] # 0 : write to logfile, 1 : write to stdout
    handler.setFormatter(formatter)
    logger.addHandler(handler)
    return logger

logger = setup_logging()

import m2

logger.info("Hello from %s", __name__)

Other module (m2.py)

import logging
logging.info("Hello from %s", __name__)

I observed this behavior with Python v2.7.3

----------
components: IO
messages: 187061
nosy: fmueller
priority: normal
severity: normal
status: open
title: root logging functions break logger configuration
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 16 12:39:40 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 10:39:40 +0000
Subject: [New-bugs-announce] [issue17750] allow the testsuite to run in the
	installed location
Message-ID: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za>


New submission from Matthias Klose:

[Meta issue, opening separate issues for test cases]

The default install always installs the testsuite together with all the python batteries. So make sure that you can run the testsuite can run from the installed location too.

 - some tests require the sources to run (using the srcdir macro,
   or files not installed, e.g. xxmodule.c).

 - some tests assume write permissions.

 - some tests assume not being run as root.

----------
assignee: doko
components: Tests
messages: 187066
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: allow the testsuite to run in the installed location
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 12:46:52 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 10:46:52 +0000
Subject: [New-bugs-announce] [issue17751] ctypes/test/test_macholib.py fails
	when run from the	installed location
Message-ID: <1366109212.26.0.351017025931.issue17751@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the ctypes tests unconditionally import macholib.dyld, which is not available in an installed testsuite on other platforms. So either don't install this test, or only run the import and test when on MacOS?

----------
components: Tests
messages: 187067
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: ctypes/test/test_macholib.py fails when run from the installed location
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 12:49:34 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 10:49:34 +0000
Subject: [New-bugs-announce] [issue17752] many distutils tests fail when run
	from the installed	location
Message-ID: <1366109374.8.0.221213577793.issue17752@psf.upfronthosting.co.za>


New submission from Matthias Klose:

many distutils tests fail when run from the installed location, either depending on the 'srcdir' macro, files not installed ('xxmodule.c'), or needing write permissions in the installed location.

----------
components: Tests
messages: 187068
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: many distutils tests fail when run from the installed location
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 12:53:57 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 10:53:57 +0000
Subject: [New-bugs-announce] [issue17753] test_zipfile: requires write
	access to test and	email.test
Message-ID: <1366109637.36.0.807884734436.issue17753@psf.upfronthosting.co.za>


New submission from Matthias Klose:

test_zipfile requires write access to the installed location, when trying to byte-compile files.

======================================================================
ERROR: test_write_pyfile (test.test_zipfile.PyZipFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_zipfile.py", line 876, in test_write_pyfile
    zipfp.writepy(fn)
  File "/usr/lib/python3.3/zipfile.py", line 1622, in writepy
    fname, arcname = self._get_codename(pathname[0:-3], basename)
  File "/usr/lib/python3.3/zipfile.py", line 1674, in _get_codename
    if _compile(file_py):
  File "/usr/lib/python3.3/zipfile.py", line 1639, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "/usr/lib/python3.3/py_compile.py", line 141, in compile
    with open(cfile, 'wb') as fc:
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.3/test/__pycache__/test_zipfile.cpython-33.pyc'

======================================================================
ERROR: test_write_with_optimization (test.test_zipfile.PyZipFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_zipfile.py", line 920, in test_write_with_optimization
    zipfp.writepy(packagedir)
  File "/usr/lib/python3.3/zipfile.py", line 1585, in writepy
    fname, arcname = self._get_codename(initname[0:-3], basename)
  File "/usr/lib/python3.3/zipfile.py", line 1689, in _get_codename
    if not _compile(file_py, optimize=self._optimize):
  File "/usr/lib/python3.3/zipfile.py", line 1639, in _compile
    py_compile.compile(file, doraise=True, optimize=optimize)
  File "/usr/lib/python3.3/py_compile.py", line 141, in compile
    with open(cfile, 'wb') as fc:
PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.3/email/__pycache__/__init__.cpython-33.pyo'

----------
components: Tests
messages: 187069
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_zipfile: requires write access to test and email.test
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 13:14:31 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 11:14:31 +0000
Subject: [New-bugs-announce] [issue17754] test_ctypes assumes LANG=C LC_ALL=C
Message-ID: <1366110871.25.0.649633802528.issue17754@psf.upfronthosting.co.za>


New submission from Matthias Klose:

this test assumes LANG=C LC_ALL=C

test.test_ctypes (unittest.loader.LoadTestsFailure) ... ERROR

======================================================================
ERROR: test.test_ctypes (unittest.loader.LoadTestsFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_ctypes.py", line 11, in load_tests
    skipped, testcases = ctypes.test.get_tests(ctypes.test, "test_*.py", verbosity=0)
  File "/usr/lib/python3.3/ctypes/test/__init__.py", line 64, in get_tests
    mod = __import__(modname, globals(), locals(), ['*'])
  File "/usr/lib/python3.3/ctypes/test/test_find.py", line 17, in <module>
    lib_gle = find_library("gle")
  File "/usr/lib/python3.3/ctypes/util.py", line 242, in find_library
    return _findSoname_ldconfig(name) or _get_soname(_findLib_gcc(name))
  File "/usr/lib/python3.3/ctypes/util.py", line 99, in _findLib_gcc
    trace = f.read()
  File "/usr/lib/python3.3/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 471: ordinal not in range(128)

----------
components: Tests
messages: 187070
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ctypes assumes LANG=C LC_ALL=C
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 13:23:32 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 11:23:32 +0000
Subject: [New-bugs-announce] [issue17755] test_builtin assumes LANG=C
Message-ID: <1366111412.63.0.121023508439.issue17755@psf.upfronthosting.co.za>


New submission from Matthias Klose:

I'm not sure about this one ... but it fails with an utf8 locale which happended to be set as the default, run from the installed location.

======================================================================
FAIL: test_input_tty_non_ascii (test.test_builtin.BuiltinTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tmp/lib/python3.4/test/test_builtin.py", line 1176, in test_input_tty_non_ascii
    self.check_input_tty("prompt\xe9", b"quux\xe9", "utf-8")
  File "/home/tmp/lib/python3.4/test/test_builtin.py", line 1167, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +


======================================================================
FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.BuiltinTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tmp/lib/python3.4/test/test_builtin.py", line 1180, in test_input_tty_non_ascii_unicode_errors
    self.check_input_tty("prompt\xe9", b"quux\xe9", "ascii")
  File "/home/tmp/lib/python3.4/test/test_builtin.py", line 1167, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +

----------
components: Tests
messages: 187072
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_builtin assumes LANG=C
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 13:32:39 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 11:32:39 +0000
Subject: [New-bugs-announce] [issue17756] test_syntax_error fails when run
	in the installed	location
Message-ID: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za>


New submission from Matthias Klose:

no idea yet about that one ...

======================================================================
FAIL: test_syntax_error (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_code_module.py", line 57, in test_syntax_error
    raise AssertionError("No syntax error from console")
AssertionError: No syntax error from console

----------
components: Tests
messages: 187073
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_syntax_error fails when run in the installed location
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 13:39:21 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 11:39:21 +0000
Subject: [New-bugs-announce] [issue17757] test_executable_without_cwd fails
	when run in the	installed location
Message-ID: <1366112361.07.0.169777986559.issue17757@psf.upfronthosting.co.za>


New submission from Matthias Klose:

this test already has a:

    @unittest.skipIf(sysconfig.is_python_build(),
                     "need an installed Python. See #7774")

but fails in the installed location.

======================================================================
FAIL: test_executable_without_cwd (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_subprocess.py", line 385, in test_executable_without_cwd
    self._assert_cwd('', "somethingyoudonthave", executable=sys.executable)
  File "/usr/lib/python3.3/test/test_subprocess.py", line 313, in _assert_cwd
    normcase(p.stdout.read().decode("utf-8")))
AssertionError: '' != '/tmp/tmp.eN4iQiwrR5/ubtree0t-testsuite-testtmp/tmpdir/test_python_21982'
+ /tmp/tmp.eN4iQiwrR5/ubtree0t-testsuite-testtmp/tmpdir/test_python_21982

======================================================================
FAIL: test_executable_without_cwd (test.test_subprocess.ProcessTestCaseNoPoll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_subprocess.py", line 385, in test_executable_without_cwd
    self._assert_cwd('', "somethingyoudonthave", executable=sys.executable)
  File "/usr/lib/python3.3/test/test_subprocess.py", line 313, in _assert_cwd
    normcase(p.stdout.read().decode("utf-8")))
AssertionError: '' != '/tmp/tmp.eN4iQiwrR5/ubtree0t-testsuite-testtmp/tmpdir/test_python_21982'
+ /tmp/tmp.eN4iQiwrR5/ubtree0t-testsuite-testtmp/tmpdir/test_python_21982

----------
components: Tests
messages: 187074
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_executable_without_cwd fails when run in the installed location
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 15:51:19 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 13:51:19 +0000
Subject: [New-bugs-announce] [issue17758] test_site fails when the user does
	not have a home	directory
Message-ID: <1366120279.38.0.306129828747.issue17758@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen when running the testsuite as user nobody, with
test_site fails when the user's home directory does not exist, and is not creatable (e.g. /nonexistent).

FAILED (failures=3)
test test_pydoc failed
Re-running test 'test_site' in verbose mode
test test_site crashed -- Traceback (most recent call last):
  File "/usr/lib/python3.3/test/regrtest.py", line 1213, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/usr/lib/python3.3/test/test_site.py", line 29, in <module>
    os.makedirs(site.USER_SITE)
  File "/usr/lib/python3.3/os.py", line 258, in makedirs
    makedirs(head, mode, exist_ok)
  File "/usr/lib/python3.3/os.py", line 258, in makedirs
    makedirs(head, mode, exist_ok)
  File "/usr/lib/python3.3/os.py", line 258, in makedirs
    makedirs(head, mode, exist_ok)
  File "/usr/lib/python3.3/os.py", line 258, in makedirs
    makedirs(head, mode, exist_ok)
  File "/usr/lib/python3.3/os.py", line 269, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/nonexistent'

----------
components: Tests
messages: 187078
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_site fails when the user does not have a home directory
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 15:59:48 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 16 Apr 2013 13:59:48 +0000
Subject: [New-bugs-announce] [issue17759] test_urllibnet.test_bad_address()
	fails on Ubuntu 13.04
Message-ID: <1366120788.32.0.41011359208.issue17759@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

socket.gethostbyname('sadflkjsasf.i.nvali.d') gives a TimeoutError instead of an IOError on Ubuntu 13.04, causing the test to fail.

% ./python -m unittest test.test_urllibnet
.E../home/barry/projects/python/cpython/Lib/test/test_urllibnet.py:94: DeprecationWarning: FancyURLopener style of invoking requests is deprecated. Use newer urlopen functions/methods
  open_url = urllib.request.FancyURLopener().open(URL)
.........
======================================================================
ERROR: test_bad_address (test.test_urllibnet.urlopenNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/barry/projects/python/cpython/Lib/test/test_urllibnet.py", line 118, in test_bad_address
    socket.gethostbyname(bogus_domain)
TimeoutError: [Errno 110] Connection timed out

----------------------------------------------------------------------
Ran 13 tests in 6.116s

FAILED (errors=1)

----------
messages: 187079
nosy: barry, doko
priority: normal
severity: normal
status: open
title: test_urllibnet.test_bad_address() fails on Ubuntu 13.04
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 16:42:25 2013
From: report at bugs.python.org (Olivier Berger)
Date: Tue, 16 Apr 2013 14:42:25 +0000
Subject: [New-bugs-announce] [issue17760] No i18n of IDLE's interface in
	french
Message-ID: <1366123345.09.0.872714866587.issue17760@psf.upfronthosting.co.za>


New submission from Olivier Berger:

The IDLE UI isn't internationalized, AFAICS.

This doesn't help when teachning Python to non-english native speakers.

While learning basic english skills is no problem for wanabe Python hackers, it isn't so for young programmers being tought informatics through Python classes.

Maybe this is a FAQ... but I couldn't discriminate enough my search terms to find prior reports :-/

Thanks in advance.

----------
components: IDLE
messages: 187086
nosy: olberger
priority: normal
severity: normal
status: open
title: No i18n of IDLE's interface in french
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 16 16:49:04 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 14:49:04 +0000
Subject: [New-bugs-announce] [issue17761] platform._parse_release_file
	doesn't close the	/etc/lsb-release file, doesn't know about 'Ubuntu'
Message-ID: <1366123744.99.0.817269180469.issue17761@psf.upfronthosting.co.za>


New submission from Matthias Klose:

platform._parse_release_file doesn't close the /etc/lsb-release file, and is missing Ubuntu in _supported_dists.

----------
components: Library (Lib)
messages: 187087
nosy: doko
priority: normal
severity: normal
stage: patch review
status: open
title: platform._parse_release_file doesn't close the /etc/lsb-release file, doesn't know about 'Ubuntu'
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 17:01:08 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 15:01:08 +0000
Subject: [New-bugs-announce] [issue17762] platform.linux_distribution()
	should honor	/etc/os-release
Message-ID: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za>


New submission from Matthias Klose:

http://www.freedesktop.org/software/systemd/man/os-release.html
is a recent standard describing release information for an operating system. platform.linux_distribution() should know about it.

 - should that be the first file to be parsed?

 - names returned for the ID are different than the ones
   returned from /etc/lsb-release. The os-release thing
   only allows lower case letters for the ID (e.g. Ubuntu
   vs. ubuntu).  The list of _supported_distros may
   need to list both.

 - take the version from VERSION_ID

 - there is no real attribute for the code name. The closest
   maybe is VERSION.

----------
components: Library (Lib)
messages: 187089
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: platform.linux_distribution() should honor /etc/os-release
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr 16 17:23:36 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Apr 2013 15:23:36 +0000
Subject: [New-bugs-announce] [issue17763] test_pydoc fails with the
	installed testsuite
Message-ID: <1366125816.55.0.847870350484.issue17763@psf.upfronthosting.co.za>


New submission from Matthias Klose:

this fails on an Ubuntu installation, running the installed tests. confirmed by a coworker. Where does the 'invalid distro' come from?

======================================================================
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_pydoc.py", line 457, in test_apropos_with_bad_package
    result = run_pydoc('zqwykjv', '-k', PYTHONPATH=TESTFN)
  File "/usr/lib/python3.3/test/test_pydoc.py", line 219, in run_pydoc
    rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/usr/lib/python3.3/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python3.3/test/script_helper.py", line 47, in _assert_python
    "stderr follows:\n%s" % (rc, cmd_line, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 2, cmd is: ['/usr/bin/python3.3dm', '-B', '/usr/lib/python3.3/pydoc.py', '-k', 'zqwykjv'], stderr follows:
invalid distro: 'Ubuntu'
Usage: pydoc.py [options]
A simple dialog based tool for basic configuration of Speech Dispatcher
and problem diagnostics.

pydoc.py: error: no such option: -k

======================================================================
FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_pydoc.py", line 467, in test_apropos_with_unreadable_dir
    result = run_pydoc('zqwykjv', '-k', PYTHONPATH=TESTFN)
  File "/usr/lib/python3.3/test/test_pydoc.py", line 219, in run_pydoc
    rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/usr/lib/python3.3/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python3.3/test/script_helper.py", line 47, in _assert_python
    "stderr follows:\n%s" % (rc, cmd_line, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 2, cmd is: ['/usr/bin/python3.3dm', '-B', '/usr/lib/python3.3/pydoc.py', '-k', 'zqwykjv'], stderr follows:
invalid distro: 'Ubuntu'
Usage: pydoc.py [options]
A simple dialog based tool for basic configuration of Speech Dispatcher
and problem diagnostics.

pydoc.py: error: no such option: -k

======================================================================
FAIL: test_url_requests (test.test_pydoc.PydocUrlHandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.3/test/test_pydoc.py", line 560, in test_url_requests
    self.assertEqual(result, title)
AssertionError: 'Pydoc: Error - search?key=pydoc' != 'Pydoc: Search Results'
- Pydoc: Error - search?key=pydoc
+ Pydoc: Search Results

----------
components: Tests
messages: 187094
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pydoc fails with the installed testsuite
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 16 18:28:50 2013
From: report at bugs.python.org (Malte Swart)
Date: Tue, 16 Apr 2013 16:28:50 +0000
Subject: [New-bugs-announce] [issue17764] Support http.server passing bind
	address via commend	line argument
Message-ID: <1366129730.55.0.013246712373.issue17764@psf.upfronthosting.co.za>


New submission from Malte Swart:

The http.server supports a shortcut to start it directly via the interpreter. To be able to use this shortcut on server with insecure interfaces, this patch adds a --bind, -b option to specify a bind address.

----------
components: Library (Lib)
files: http-server-bind-arg.patch
keywords: patch
messages: 187102
nosy: malte.swart
priority: normal
severity: normal
status: open
title: Support http.server passing bind address via commend line argument
type: enhancement
Added file: http://bugs.python.org/file29886/http-server-bind-arg.patch

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

From report at bugs.python.org  Tue Apr 16 21:11:10 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Apr 2013 19:11:10 +0000
Subject: [New-bugs-announce] [issue17765] weakref.ref ignores a 'callback'
	keyword argument
Message-ID: <1366139470.36.0.39573405184.issue17765@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

Passing a weakref.ref callback by keyword currently fails silently:

Python 3.4.0a0 (default:537c1f1ab53c, Apr 16 2013, 20:07:47) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import weakref
>>> weakref.ref({1, 2, 3}, callback=lambda ref:print("collected"))
<weakref at 0x1006189d8; dead>

For Python 3.4, I'd suggest that either (1) this should be an exception, or (2) it should be permissible to pass the callback by keyword.

----------
messages: 187115
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: weakref.ref ignores a 'callback' keyword argument
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Apr 16 21:17:07 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 16 Apr 2013 19:17:07 +0000
Subject: [New-bugs-announce] [issue17766] Fix test discovery for
	test_iterlen.py
Message-ID: <1366139827.64.0.673243838717.issue17766@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Just subclassing and test_main in this one.

----------
components: Tests
files: test_iterlen_discovery.diff
keywords: patch
messages: 187116
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_iterlen.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29890/test_iterlen_discovery.diff

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

From report at bugs.python.org  Tue Apr 16 21:51:12 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 16 Apr 2013 19:51:12 +0000
Subject: [New-bugs-announce] [issue17767] Fix test discovery for
	test_locale.py
Message-ID: <1366141872.94.0.252098297991.issue17767@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This one actually had Failures rather than Errors; those failures arose from enUS_locale being None because it was being changed in test_main.  This patch attempts to fix things by adapting get_enUS_locale() to return a tuple of a suitable setting for enUS_locale and a reason for skipping the tests that were formerly ignored if enUS_locale was None.

----------
components: Tests
files: test_locale_discovery.diff
keywords: patch
messages: 187117
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_locale.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29891/test_locale_discovery.diff

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

From report at bugs.python.org  Tue Apr 16 22:05:33 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 16 Apr 2013 20:05:33 +0000
Subject: [New-bugs-announce] [issue17768] _decimal: allow NUL fill character
Message-ID: <1366142733.14.0.416773869119.issue17768@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Making the _decimal part of #17705 a separate issue. I noticed that
decimal.py does not allow a newline as a fill character:


Python 3.3.0rc2+ (default:50dd7426b880, Sep 25 2012, 15:52:28) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_decimal'] = None
>>> from decimal import *
>>> format(Decimal(123), "\n<10")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.3/decimal.py", line 3768, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/local/lib/python3.3/decimal.py", line 6176, in _parse_format_specifier
    raise ValueError("Invalid format specifier: " + format_spec)
ValueError: Invalid format specifier: 
<10


The feature isn't particularly useful, but it would be easiest for
_decimal to support it rather than having another special case.

Are you okay with the decimal.py patch?

----------
assignee: skrah
components: Extension Modules
files: decimal_newline_fillchar.diff
keywords: patch
messages: 187119
nosy: Jason.Michalski, Julian, eric.smith, mark.dickinson, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: _decimal: allow NUL fill character
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29892/decimal_newline_fillchar.diff

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

From report at bugs.python.org  Tue Apr 16 22:22:14 2013
From: report at bugs.python.org (Max Cantor)
Date: Tue, 16 Apr 2013 20:22:14 +0000
Subject: [New-bugs-announce] [issue17769] python-config --ldflags gives
	broken output when	statically linking Python with --as-needed
Message-ID: <1366143734.86.0.154931116413.issue17769@psf.upfronthosting.co.za>


New submission from Max Cantor:

On certain Linux distributions such as Ubuntu, the linker is invoked by default with --as-needed, which has an undesireable side effect when linking static libraries: it is bad at detecting required symbols, and the order of libraries on the command line become significant.

Right now, on my Ubuntu 12.10 system with a custom 32-bit version of Python, I get the following command output:

mcantor at hpmongo:~$ /opt/pym32/bin/python-config --ldflags
-L/opt/pym32/lib/python2.7/config -lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic

When linking a project with those flags, I get the following error:

/usr/bin/ld: /opt/pym32/lib/python2.7/config/libpython2.7.a(dynload_shlib.o): undefined reference to symbol 'dlopen@@GLIBC_2.1'
/usr/bin/ld: note: 'dlopen@@GLIBC_2.1' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu/libdl.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../i386-linux-gnu/libdl.so: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

To resolve the error, I moved -ldl and -lutil *AFTER* -lpython2.7, so the relevant chunk of my gcc command line looked like this:

-L/opt/pym32/lib/python2.7/config -lpthread -lm -lpython2.7 -ldl -lutil -Xlinker -export-dynamic

I have no idea why --as-needed has such an unpleasant side effect when static libraries are being used, and it's arguable from my perspective that this behavior is the real bug. However it's equally likely that there's a good reason for that behavior, like it causes a slowdown during leap-years on Apple IIs or something. So here I am. python-config ought to respect the quirks of --as-needed when outputting its ldflags.

----------
components: Build, Cross-Build
messages: 187121
nosy: Max.Cantor
priority: normal
severity: normal
status: open
title: python-config --ldflags gives broken output when statically linking Python with --as-needed
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 17 05:23:07 2013
From: report at bugs.python.org (Harry Johnston)
Date: Wed, 17 Apr 2013 03:23:07 +0000
Subject: [New-bugs-announce] [issue17770] MSI installer default behaviour
	inconsistent
Message-ID: <1366168987.71.0.824205265915.issue17770@psf.upfronthosting.co.za>


New submission from Harry Johnston:

When installing python-2.7.4.msi via the GUI, the default setting for the installation type is "All Users".

When installing it passively, e.g.

msiexec /package python-2.7.4.msi /passive

the default installation type is "Just For Me", or at least that is how it is behaving - no entry is added to Uninstall Programs, the Start Menu entries are created for the current user only, and registry entries are created in HKCU instead of HKLM.

This makes enterprise deployments difficult.

I'm running Windows 7 x64 SP1.

----------
components: Installation
messages: 187133
nosy: Harry.Johnston
priority: normal
severity: normal
status: open
title: MSI installer default behaviour inconsistent
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 17 06:01:31 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Wed, 17 Apr 2013 04:01:31 +0000
Subject: [New-bugs-announce] [issue17771] Missing period in concurrent
	execution doc in standard	library
Message-ID: <1366171291.19.0.507321849064.issue17771@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

No period after the first sentence of the first paragraph in /Doc/build/html/library/concurrency.html.

"The appropriate choice of tool will depend on the task to be executed (CPU bound vs IO bound) and preferred style of development (event driven cooperative multitasking vs preemptive multitasking) Here?s an overview:"

----------
assignee: docs at python
components: Documentation
messages: 187137
nosy: amysyk, docs at python
priority: normal
severity: normal
status: open
title: Missing period in concurrent execution doc in standard library
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 17 12:16:23 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Apr 2013 10:16:23 +0000
Subject: [New-bugs-announce] [issue17772] test_gdb doesn't detect a gdb
	built with python3.3 (or	higher)
Message-ID: <1366193783.12.0.853305189614.issue17772@psf.upfronthosting.co.za>


New submission from Matthias Klose:

test_gdb skipped -- gdb not built with embedded python support

$ gdb --version
GNU gdb (GDB) 7.5.91.20130408
$ ldd /usr/bin/gdb|grep python
	libpython3.3m.so.1.0 => /usr/lib/libpython3.3m.so.1.0

----------
messages: 187151
nosy: dmalcolm, doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb doesn't detect a gdb built with python3.3 (or higher)
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 17 12:38:58 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Apr 2013 10:38:58 +0000
Subject: [New-bugs-announce] [issue17773] test_pydoc fails with the
	installed testsuite (2.7)
Message-ID: <1366195138.79.0.33949510354.issue17773@psf.upfronthosting.co.za>


New submission from Matthias Klose:

these are failures not seen with 3.x, running with -S doesn't help.

test_pydoc
test test_pydoc failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_pydoc
Re-running failed tests in verbose mode
Re-running test 'test_pydoc' in verbose mode
test_html_doc (test.test_pydoc.PyDocDocTest) ... 
--- expected
+++ got
@@ -19 +19 @@
-<dt><font face="helvetica, arial"><a href="test.pydoc_mod.html#B">B</a>
+<dt><font face="helvetica, arial">B
@@ -22 +22 @@
-<dt><font face="helvetica, arial"><a href="test.pydoc_mod.html#A">A</a>
+<dt><font face="helvetica, arial">A
@@ -56,12 +55,0 @@
-<tr bgcolor="#eeaa77">
-<td colspan=3 valign=bottom>&nbsp;<br>
-<font color="#ffffff" face="helvetica, arial"><big><strong>Functions</strong></big></font></td></tr>
-    
-<tr><td bgcolor="#eeaa77"><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</tt></td><td>&nbsp;</td>
-<td width="100%"><dl><dt><a name="-doc_func"><strong>doc_func</strong></a>()</dt><dd><tt>This&nbsp;function&nbsp;solves&nbsp;all&nbsp;of&nbsp;the&nbsp;world's&nbsp;problems:<br>
-hunger<br>
-lack&nbsp;of&nbsp;Python<br>
-war</tt></dd></dl>
- <dl><dt><a name="-nodoc_func"><strong>nodoc_func</strong></a>()</dt></dl>
-</td></tr></table><p>
-<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="section">

FAIL
test_input_strip (test.test_pydoc.PyDocDocTest) ... ok
test_issue8225 (test.test_pydoc.PyDocDocTest) ... ok
test_non_str_name (test.test_pydoc.PyDocDocTest) ... ok
test_not_here (test.test_pydoc.PyDocDocTest) ... ok
test_stripid (test.test_pydoc.PyDocDocTest) ... ok
test_text_doc (test.test_pydoc.PyDocDocTest) ... 
--- expected
+++ got
@@ -34,9 +33,0 @@
-FUNCTIONS
-    doc_func()
-        This function solves all of the world's problems:
-        hunger
-        lack of Python
-        war
-    
-    nodoc_func()
-

FAIL
test_apropos_with_bad_package (test.test_pydoc.PydocImportTest) ... FAIL
test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest) ... FAIL
test_badimport (test.test_pydoc.PydocImportTest) ... ok
test_class (test.test_pydoc.TestDescriptions) ... ok
test_classic_class (test.test_pydoc.TestDescriptions) ... ok
test_module (test.test_pydoc.TestDescriptions) ... ok
test_namedtuple_public_underscore (test.test_pydoc.TestDescriptions) ... ERROR
test_builtin (test.test_pydoc.TestHelper) ... ok
test_keywords (test.test_pydoc.TestHelper) ... test test_pydoc failed -- multiple errors occurred
ok

======================================================================
ERROR: test_namedtuple_public_underscore (test.test_pydoc.TestDescriptions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 383, in test_namedtuple_public_underscore
    help(NT)
NameError: global name 'help' is not defined

======================================================================
FAIL: test_html_doc (test.test_pydoc.PyDocDocTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 248, in test_html_doc
    self.fail("outputs are not equal, see diff above")
AssertionError: outputs are not equal, see diff above

======================================================================
FAIL: test_text_doc (test.test_pydoc.PyDocDocTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 259, in test_text_doc
    self.fail("outputs are not equal, see diff above")
AssertionError: outputs are not equal, see diff above

======================================================================
FAIL: test_apropos_with_bad_package (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 341, in test_apropos_with_bad_package
    result = run_pydoc('zqwykjv', '-k', PYTHONPATH=TESTFN)
  File "/usr/lib/python2.7/test/test_pydoc.py", line 196, in run_pydoc
    rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/usr/lib/python2.7/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python2.7/test/script_helper.py", line 47, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -11, stderr follows:


======================================================================
FAIL: test_apropos_with_unreadable_dir (test.test_pydoc.PydocImportTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_pydoc.py", line 351, in test_apropos_with_unreadable_dir
    result = run_pydoc('zqwykjv', '-k', PYTHONPATH=TESTFN)
  File "/usr/lib/python2.7/test/test_pydoc.py", line 196, in run_pydoc
    rc, out, err = assert_python_ok('-B', pydoc.__file__, *args, **env)
  File "/usr/lib/python2.7/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/lib/python2.7/test/script_helper.py", line 47, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -11, stderr follows:


----------------------------------------------------------------------
Ran 16 tests in 3.323s

FAILED (failures=4, errors=1)
[47527 refs]

----------
components: Tests
messages: 187152
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pydoc fails with the installed testsuite (2.7)
versions: Python 2.7

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

From report at bugs.python.org  Wed Apr 17 15:03:01 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Apr 2013 13:03:01 +0000
Subject: [New-bugs-announce] [issue17774] unable to disable -r in
	run_tests.py
Message-ID: <1366203781.64.0.116345501767.issue17774@psf.upfronthosting.co.za>


New submission from Matthias Klose:

it is not possible to disable -r in run_tests.py. Other options like -u or -j can be overwritten, but not removing -r.

----------
components: Tests
messages: 187160
nosy: doko
priority: normal
severity: normal
stage: needs patch
status: open
title: unable to disable -r in run_tests.py
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 17 15:57:06 2013
From: report at bugs.python.org (David Walker)
Date: Wed, 17 Apr 2013 13:57:06 +0000
Subject: [New-bugs-announce] [issue17775] Error with Hello, World in 3.3.1
Message-ID: <1366207026.0.0.721321770199.issue17775@psf.upfronthosting.co.za>


New submission from David Walker:

I'm brand new to Python (and programming in general) and I'm reading "Python for Dummies" while trying to learn this.  I downloaded 3.3.1 and when I entered the command

>>> print "Hello, World!"

it would give the following error:

SyntaxError: invalid syntax
  File "<stdin>", line 1
     print "Hello, World!"

Yet when I do the same thing in v 2.7.4 it works fine.  Is there something I'm doing wrong?  Thanks in advance

----------
components: Windows
messages: 187161
nosy: walkah21
priority: normal
severity: normal
status: open
title: Error with Hello, World in 3.3.1
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 17 16:13:03 2013
From: report at bugs.python.org (=?utf-8?q?Damien_Mari=C3=A9?=)
Date: Wed, 17 Apr 2013 14:13:03 +0000
Subject: [New-bugs-announce] [issue17776] IDLE Internationalization
Message-ID: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za>


New submission from Damien Mari?:

Following the issue 17760

Internationalization should be implemented.
I propose to implement it as an optionnal settings first. And with the gettext library.

I'm not experienced with the idlelib module but here is a first patch, don't hesitate to comment it. It just add i18n to the menu for now.

----------
components: IDLE
files: patch.diff
keywords: patch
messages: 187165
nosy: Damien.Mari?
priority: normal
severity: normal
status: open
title: IDLE Internationalization
type: enhancement
Added file: http://bugs.python.org/file29904/patch.diff

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

From report at bugs.python.org  Wed Apr 17 17:37:35 2013
From: report at bugs.python.org (Reynir Reynisson)
Date: Wed, 17 Apr 2013 15:37:35 +0000
Subject: [New-bugs-announce] [issue17777] Unrecognized string literal escape
	sequences give	SyntaxErrors
Message-ID: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>


New submission from Reynir Reynisson:

Strings like "\u" trigger a SyntaxError. According to the language reference "all unrecognized escape sequences are left in the string unchanged"[0]. The string "\u" clearly doesn't match any of the escape sequences (in particular \uxxxx).

This may be intentional, but it is not clear from the language reference that this is the case. If it is intentional it should probably be stated more explicit in the language reference.

I think this may be confusing for new users since the syntax errors may lead them to believe the interpreter will give syntax error for all unrecognized escape sequences.

[0]: http://docs.python.org/3/reference/lexical_analysis.html#literals

----------
assignee: docs at python
components: Documentation, Unicode
messages: 187173
nosy: docs at python, ezio.melotti, reynir
priority: normal
severity: normal
status: open
title: Unrecognized string literal escape sequences give SyntaxErrors
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 17 19:01:22 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 17 Apr 2013 17:01:22 +0000
Subject: [New-bugs-announce] [issue17778] Fix test discovery for
	test_multiprocessing.py
Message-ID: <1366218082.59.0.595129290582.issue17778@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I think this one only didn't work with discovery by accident: the only change necessary to make discovery pass was to make _TestPoll match all other _Test* classes by inheriting from BaseTestCase instead of unittest.TestCase.  The remainder of the changes are to eliminate test_main by converting it instead to setUpModule.  setUpModule is, I think, necessary on this one due to a failing test in WithProcessesTestLogging when the initial call to multiprocessing.get_logger().setLevel() (originally in test_main) is moved to top-level code.

----------
components: Tests
files: test_multiprocessing_discovery.diff
keywords: patch
messages: 187181
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_multiprocessing.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29905/test_multiprocessing_discovery.diff

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

From report at bugs.python.org  Wed Apr 17 20:29:16 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 17 Apr 2013 18:29:16 +0000
Subject: [New-bugs-announce] [issue17779] Fix test discovery for
	test_osx_env.py
Message-ID: <1366223356.18.0.930448045627.issue17779@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch converts test_osx_env.py to use a skip decorator instead of just not running the test at all.

----------
components: Tests
files: test_osx_env_discovery.diff
keywords: patch
messages: 187189
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_osx_env.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29906/test_osx_env_discovery.diff

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

From report at bugs.python.org  Wed Apr 17 20:36:06 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Apr 2013 18:36:06 +0000
Subject: [New-bugs-announce] [issue17780] the test suite should use a
	TEMPDIR in the build	directory, not the source directory
Message-ID: <1366223766.74.0.431919060709.issue17780@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the test suite should use a TEMPDIR in the build directory, not the source directory, e.g. the source directory might not be writeable.

looks like regrtest._make_temp_dir_for_build() needs just to use abs_builddir instead of srcdir.

----------
components: Tests
messages: 187190
nosy: doko
priority: normal
severity: normal
status: open
title: the test suite should use a TEMPDIR in the build directory, not the source directory
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 17 20:40:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Apr 2013 18:40:08 +0000
Subject: [New-bugs-announce] [issue17781] optimize compilation options
Message-ID: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Ubuntu's system Python 3.3 shows consistently better performance than a vanilla Python 3.3: around 10-15% faster in general (see attached benchmark numbers).

If this can be attributed to different compilation options, it would be nice to backport those options to our standard build config.

----------
components: Build
files: perflog.txt
messages: 187192
nosy: barry, doko, pitrou
priority: low
severity: normal
status: open
title: optimize compilation options
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file29907/perflog.txt

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

From report at bugs.python.org  Wed Apr 17 21:25:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Apr 2013 19:25:27 +0000
Subject: [New-bugs-announce] [issue17782] Fix test_signal failure on x32
Message-ID: <1366226727.47.0.55075488936.issue17782@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

x32 is a special Linux ABI on x86-64 CPUs. When compiling for x32, there's a failure in test_sigtimedwait. The failure is due to the fact that on x32, "long" is 32 bits but "timespec.tv_nsec" is 64 bits. Therefore we can't pass the pointer to tv_nsec directly to _PyTime_ObjectToTimespec.

Patch attached.

----------
components: Interpreter Core
files: x32_timespec.patch
keywords: patch
messages: 187197
nosy: haypo, mark.dickinson, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Fix test_signal failure on x32
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29908/x32_timespec.patch

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

From report at bugs.python.org  Wed Apr 17 21:38:00 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Apr 2013 19:38:00 +0000
Subject: [New-bugs-announce] [issue17783] run the testsuite in batched mode
Message-ID: <1366227480.23.0.0819092121273.issue17783@psf.upfronthosting.co.za>


New submission from Matthias Klose:

running all the tests in one batch sometimes can go wrong. there is of course the --single mode, but starting the testsuite for each single test seems to be a bit of overhead.  So extend the --single API to something like --next=<n> which runs the next <n> tests. or would --batch be a better name? and maybe don't change the single default parameter in the signature, and introduce a new parameter.

the proposed patch is currently against the 3.3 branch, and without doc changes.

----------
components: Tests
files: batch-test.diff
keywords: patch
messages: 187199
nosy: doko
priority: normal
severity: normal
stage: patch review
status: open
title: run the testsuite in batched mode
versions: Python 3.4
Added file: http://bugs.python.org/file29909/batch-test.diff

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

From report at bugs.python.org  Wed Apr 17 23:44:44 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 17 Apr 2013 21:44:44 +0000
Subject: [New-bugs-announce] [issue17784] the test suite should honor an
	http_proxy for running	the test suite
Message-ID: <1366235084.83.0.373131563913.issue17784@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the test suite should honor an http_proxy for running the test suite, at least for all the tests using the urlfetch resource. maybe for some tests using the network resource too. this would allow running tests in somehow constrained environments.

----------
components: Tests
messages: 187208
nosy: doko
priority: normal
severity: normal
status: open
title: the test suite should honor an http_proxy for running the test suite

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

From report at bugs.python.org  Thu Apr 18 01:52:57 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 17 Apr 2013 23:52:57 +0000
Subject: [New-bugs-announce] [issue17785] Use faster URL shortener for
	perf.py
Message-ID: <1366242777.62.0.0914691479989.issue17785@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

As noted previously, TinyURL URL shortening API is rather slow and not always available. Each requests takes between 0.5 and 1.5 seconds.

We should change it to use Google URL Shortener which returns a response within 10 milliseconds and is much more available.

----------
assignee: alexandre.vassalotti
components: Benchmarks
files: use_google_shortener.patch
keywords: patch
messages: 187215
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Use faster URL shortener for perf.py
type: performance
Added file: http://bugs.python.org/file29912/use_google_shortener.patch

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

From report at bugs.python.org  Thu Apr 18 10:03:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Apr 2013 08:03:52 +0000
Subject: [New-bugs-announce] [issue17786] Crash in
	test_ctypes.test_callbacks() on AMD64 NetBSD	5.1.2 [SB] 3.x
Message-ID: <1366272232.44.0.752593622389.issue17786@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Fatal Python error: Segmentation fault

Current thread 0x0000000000000000:
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/ctypes/test/test_as_parameter.py", line 87 in test_callbacks
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/case.py", line 496 in run
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/case.py", line 535 in __call__
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/suite.py", line 105 in run
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/suite.py", line 105 in run
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/suite.py", line 105 in run
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/suite.py", line 67 in __call__
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/unittest/runner.py", line 168 in run
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/support.py", line 1557 in _run_suite
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/support.py", line 1591 in run_unittest
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/regrtest.py", line 1286 in <lambda>
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/regrtest.py", line 1287 in runtest_inner
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/regrtest.py", line 999 in runtest
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/regrtest.py", line 797 in main
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/regrtest.py", line 1572 in main_in_temp_cwd
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/test/__main__.py", line 3 in <module>
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/runpy.py", line 73 in _run_code
  File "/home/cpython/buildslave/3.x.snakebite-netbsd51-amd64-1/build/Lib/runpy.py", line 160 in _run_module_as_main
[1]   Segmentation fault      ./python ./Tools...

The crash occurs since the build http://buildbot.python.org/all/builders/AMD64%20NetBSD%205.1.2%20%5BSB%5D%203.x/builds/891/.

The build was triggered because of the new changeset ae5c4a9118b8a3f490f77f2084d46163ca229aef, but I don't see a link between this changeset and ctypes. I may be another change in the toolchain, a system upgrade, or sometimes like that.

It looks like the crash is specific to Python 3.4.

----------
components: Extension Modules
messages: 187228
nosy: ezio.melotti, haypo, pitrou, trent
priority: normal
severity: normal
status: open
title: Crash in test_ctypes.test_callbacks() on AMD64 NetBSD 5.1.2 [SB] 3.x
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 18 11:37:48 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 18 Apr 2013 09:37:48 +0000
Subject: [New-bugs-announce] [issue17787] Optimize pickling function lookups
	in hot loops.
Message-ID: <1366277868.22.0.694548621851.issue17787@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

I found through profiling that batch_list_exact and batch_dict_exact spent a fair amount of time looking up the pickling function. I have found a way to optimize the lookup using a simple heuristic that assume items in dicts and lists have often a common type. So we have save some time by jumping right to the pickling function we need. Here are the result of running the benchmarks:

### fastpickle ###
Min: 0.593904 -> 0.541918: 1.10x faster
Avg: 0.606811 -> 0.564606: 1.07x faster
Significant (t=10.18)
Stddev: 0.01061 -> 0.02733: 2.5760x larger
Timeline: http://tinyurl.com/bwbvw7j

### pickle_list ###
Min: 0.907891 -> 0.915905: 1.01x slower
Avg: 0.970537 -> 0.948349: 1.02x faster
Significant (t=2.08)
Stddev: 0.07107 -> 0.02526: 2.8136x smaller
Timeline: http://tinyurl.com/cmlymq7

----------
assignee: alexandre.vassalotti
files: optimize_save_dispatch.patch
keywords: patch
messages: 187230
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize pickling function lookups in hot loops.
type: performance
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29918/optimize_save_dispatch.patch

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

From report at bugs.python.org  Thu Apr 18 12:02:40 2013
From: report at bugs.python.org (Eric Wieser)
Date: Thu, 18 Apr 2013 10:02:40 +0000
Subject: [New-bugs-announce] [issue17788] Add a with expression,
	for use in comprehensions
Message-ID: <1366279360.22.0.996047925833.issue17788@psf.upfronthosting.co.za>


New submission from Eric Wieser:

It would be nice if there was a `with` "expression". Such that instead of:

    with open(...) as f:
        result = foo(f)

One could write:

    result = foo(f) with open(...) as f

This would be particularly useful in comprehensions. Instead of:

    files = {}
    for fname in os.listdir('.'):
        if predicate(fname):
            with open(fname) as f:
                files[fname] = foo(f)

    files = {
        fname: foo(f) with open(fname) as f
        for fname in os.listdir('.') if predicate(fname)
    }

----------
messages: 187232
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: Add a with expression, for use in comprehensions
type: enhancement

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

From report at bugs.python.org  Thu Apr 18 17:03:51 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 18 Apr 2013 15:03:51 +0000
Subject: [New-bugs-announce] [issue17789] Fix test discovery for
	test_random.py
Message-ID: <1366297431.16.0.642469069527.issue17789@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This one had subclassing issues, and SystemRandom_TestBasicOps was being skipped by exclusion from the list of tests passed to support.run_unittest, so it's been converted to a skip decorator.

----------
components: Tests
files: test_random_discovery.diff
keywords: patch
messages: 187257
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_random.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29922/test_random_discovery.diff

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

From report at bugs.python.org  Thu Apr 18 17:18:13 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 18 Apr 2013 15:18:13 +0000
Subject: [New-bugs-announce] [issue17790] Fix test discovery for test_set.py
Message-ID: <1366298293.17.0.875965063337.issue17790@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Just subclassing and test_main in this one.

----------
components: Tests
files: test_set_discovery.diff
keywords: patch
messages: 187259
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_set.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29923/test_set_discovery.diff

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

From report at bugs.python.org  Thu Apr 18 21:46:19 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 18 Apr 2013 19:46:19 +0000
Subject: [New-bugs-announce] [issue17791] PC/pyconfig.h defines PREFIX macro
Message-ID: <1366314379.89.0.227357780835.issue17791@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The pyconfig.h file of the Windows build environment defines at least two macros without a Py/PY prefix:

PC/pyconfig.h:#define PREFIX ""
PC/pyconfig.h:#define EXEC_PREFIX ""

This has caused multiple issues in the past. For example libexpat uses PREFIX, too. When I was working on my XML patches it took me about half an hour to fix the build on Windows. PyLucence's JCC has run into the same issue, too. http://mail-archives.apache.org/mod_mbox/lucene-pylucene-dev/201304.mbox/browser

Can we change the name of PREFIX to PY_PREFIX nad EXEC_PREFIX to PY_EXEC_PREFIX?

----------
components: Build, Windows
messages: 187284
nosy: christian.heimes, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: PC/pyconfig.h defines PREFIX macro
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr 19 01:55:22 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 18 Apr 2013 23:55:22 +0000
Subject: [New-bugs-announce] [issue17792] Unhelpful UnboundLocalError due to
	del'ing of exception	target
Message-ID: <1366329322.51.0.489771554551.issue17792@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

As described here:

http://www.wefearchange.org/2013/04/python-3-language-gotcha-and-short.html

the following code will produce an UnboundLocalError when the exception is triggered:

def bad():
    e = None
    try:
        do_something()
    except KeyError as e:
        print('ke')
    except ValueError as e:
        print('ve')
    print(e)

The reason is that the exception handling machinery del's `e` from the local namespace in order to break circular references caused by __traceback__.  The ULE is pretty mysterious and certainly not helpful for figuring out what's going wrong (the blog post above describes how long it took me to find it ;).

Can we do better?  What if instead of del'ing the target, we set it to None?  We wouldn't get a ULE but the fact that print(e) would print None might be just as mysterious.  Any other ideas?

(BTW, there's likely nothing to be done for Python < 3.4.)

----------
messages: 187313
nosy: barry
priority: normal
severity: normal
status: open
title: Unhelpful UnboundLocalError due to del'ing of exception target
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr 19 02:11:46 2013
From: report at bugs.python.org (Hank Christian)
Date: Fri, 19 Apr 2013 00:11:46 +0000
Subject: [New-bugs-announce] [issue17793] Invitation to connect on LinkedIn
Message-ID: <1882930326.14999090.1366330303995.JavaMail.app@ela4-app0129.prod>


New submission from Hank Christian:

LinkedIn
------------

Python,

I'd like to add you to my professional network on LinkedIn.

- Henry

Henry Christian
ADJUNCT PROFESSOR at Central Texas College
Greater Los Angeles Area

Confirm that you know Henry Christian:
https://www.linkedin.com/e/-3qcne3-hfols9uw-6g/isd/10674146693/f8KKDSuG/?hs=false&tok=0bzd0NdaLbulI1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hfols9uw-6g/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4172161560_1/?hs=false&tok=07YV1ohYLbulI1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

----------
messages: 187316
nosy: hankchristian
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Fri Apr 19 02:37:22 2013
From: report at bugs.python.org (Carlos Ferreira)
Date: Fri, 19 Apr 2013 00:37:22 +0000
Subject: [New-bugs-announce] [issue17794] Priority Queue
Message-ID: <1366331842.58.0.144732937336.issue17794@psf.upfronthosting.co.za>


New submission from Carlos Ferreira:

I'm using Priority Queues and followed the Python documentation for a simple example.

>From Queue documentation in Python 3.3
http://docs.python.org/3.3/library/queue.html
"
The lowest valued entries are retrieved first (the lowest valued entry is the one returned by sorted(list(entries))[0]). A typical pattern for entries is a tuple in the form: (priority_number, data).
"

Then I tried this simple code.

>>> pq = PriorityQueue()
>>> pq.put_nowait((0, {'a':1}))
>>> pq.put_nowait((0, {'a':2}))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.3/queue.py", line 187, in put_nowait
return self.put(item, block=False)
File "/usr/lib/python3.3/queue.py", line 146, in put
self._put(item)
File "/usr/lib/python3.3/queue.py", line 230, in _put
heappush(self.queue, item)
TypeError: unorderable types: dict() < dict()

Is this a normal behaviour? I'm not sure if this should be declared as a bug...

Instead of sticking to the first argument that indicates the priority, the heapq algorithm checks the second field and tries to order the dictionaries.

I solved this annoyance by adding a  third field, the object ID. Since the object ID is actually its address in memory, every object will have a different ID. Also, since the queue entries will have the same priority (zero), the id value is used to order the tuples in the heap queue.

>>> pq = PriorityQueue()
>>> a = {'a':1}
>>> b = {'a':2}
>>> pq.put_nowait((0, id(a), a))
>>> pq.put_nowait((0, id(b), b))

----------
components: Interpreter Core
messages: 187321
nosy: Claymore
priority: normal
severity: normal
status: open
title: Priority Queue
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Apr 19 08:58:32 2013
From: report at bugs.python.org (Mike Lundy)
Date: Fri, 19 Apr 2013 06:58:32 +0000
Subject: [New-bugs-announce] [issue17795] backwards-incompatible change in
	SysLogHandler with unix	domain sockets
Message-ID: <1366354712.85.0.15970946625.issue17795@psf.upfronthosting.co.za>


New submission from Mike Lundy:

The changed merged from http://bugs.python.org/issue16168 causes a regression in SysLogHandler behavior. The socktype of /dev/log is dependent on syslog configuration, and the fallback behavior (trying SOCK_DGRAM and then SOCK_STREAM if the former failed) was very useful.

A better fix for this would preserve the fallback behavior in cases where the caller has not specifically requested a socktype. I've attached a patch with one such approach.

----------
components: Library (Lib)
files: 0001-Restore-SysLogHandler-fallback-for-AF_UNIX-sockets.patch
keywords: patch
messages: 187347
nosy: Mike.Lundy
priority: normal
severity: normal
status: open
title: backwards-incompatible change in SysLogHandler with unix domain sockets
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29937/0001-Restore-SysLogHandler-fallback-for-AF_UNIX-sockets.patch

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

From report at bugs.python.org  Fri Apr 19 09:30:49 2013
From: report at bugs.python.org (LCID Fire)
Date: Fri, 19 Apr 2013 07:30:49 +0000
Subject: [New-bugs-announce] [issue17796] No mimetype guessed for tar.xz url
Message-ID: <1366356649.95.0.33781199343.issue17796@psf.upfronthosting.co.za>


New submission from LCID Fire:

mimetypes.guess_type( "http://ftp.gnome.org/pub/GNOME/sources/libxml++/2.36/libxml++-2.36.0.tar.xz"), strict=False )

gives

(None, None)

----------
components: Library (Lib)
messages: 187348
nosy: lcid-fire
priority: normal
severity: normal
status: open
title: No mimetype guessed for tar.xz url
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Apr 19 14:18:32 2013
From: report at bugs.python.org (Mateusz Loskot)
Date: Fri, 19 Apr 2013 12:18:32 +0000
Subject: [New-bugs-announce] [issue17797] Visual C++ 11.0 reports
	fileno(stdin) == 0 for	non-console program
Message-ID: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>


New submission from Mateusz Loskot:

In pythonrun.c, there is function initstdio() with the following test:

static int
initstdio(void)
{
...
    /* Set sys.stdin */
    fd = fileno(stdin);
    /* Under some conditions stdin, stdout and stderr may not be connected
     * and fileno() may point to an invalid file descriptor. For example
     * GUI apps don't have valid standard streams by default.
     */
    if (fd < 0) {
#ifdef MS_WINDOWS
        std = Py_None;
        Py_INCREF(std);
#else
        goto error;
#endif
    }
    else {
...
}

This function is fails for non-console applications (i.e. MFC) built using Visual C++ 11.0 (Visual Studio 2012), becasue **strangely**, fileno(stdin) == 0, so this test results in false and Python initialisation routines attempt to setup streams.

Apparently, fileno(stdin) return value has changed between Visual C++ 10.0 (VS 2010)
and 11.0. The VC++ 10.0 reports fileno(stdin) == -2.

----------
components: IO, Interpreter Core
messages: 187351
nosy: mloskot
priority: normal
severity: normal
status: open
title: Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program
versions: Python 3.2

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

From report at bugs.python.org  Sat Apr 20 04:45:14 2013
From: report at bugs.python.org (Roger Serwy)
Date: Sat, 20 Apr 2013 02:45:14 +0000
Subject: [New-bugs-announce] [issue17798] IDLE: can not edit new file names
	when using -e
Message-ID: <1366425914.88.0.469107315169.issue17798@psf.upfronthosting.co.za>


New submission from Roger Serwy:

This is a split from #13495 as it is truly a separate issue. Here's a partial quote from msg151278:

"""
IDLE 3 no longer allows for editing of new files from the command line. 

For example:

   idle -e /tmp/newfile.py 

will momentarily flash an editor window before it is closed. This is due to "good_load" not being set. What's worse is that the IDLE process will continue running without having any visible windows open. 
"""

Rather than remove the good_load behavior as was done in an earlier patch in #13495, I added an extra line in the initialization logic so that the editor can edit newly named files while still rejecting files that didn't load properly.

----------
assignee: roger.serwy
components: IDLE
files: goodload.patch
keywords: patch
messages: 187399
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: can not edit new file names when using -e
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29947/goodload.patch

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

From report at bugs.python.org  Sat Apr 20 05:36:20 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 20 Apr 2013 03:36:20 +0000
Subject: [New-bugs-announce] [issue17799] settrace docs are wrong about
	"c_call" events
Message-ID: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

Looking into this Stack Overflow question:  http://stackoverflow.com/questions/16115027/pythons-sys-settrace-wont-create-c-call-events

Reading the code in c_eval.c and friends, it looks like "c_call" events are never passed to the trace function, only to the profile function.  The docs are wrong and should be fixed.

The setprofile docs simply point to settrace for details, so the text needs to accommodate both functions' needs.

----------
assignee: docs at python
components: Documentation
messages: 187406
nosy: docs at python, nedbat
priority: low
severity: normal
status: open
title: settrace docs are wrong about "c_call" events
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Apr 20 08:38:21 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Apr 2013 06:38:21 +0000
Subject: [New-bugs-announce] [issue17800] Expose __del__ when tp_del is
	populated from C code
Message-ID: <1366439901.03.0.82185599108.issue17800@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This came up in issue 17468: currently, populating tp_del from C (as generators now do) doesn't automatically create a __del__ wrapper visible from Python.

The rationale given in the initial commit is that there's no need to define a wrapper, since tp_del won't be populated from C code (that will use tp_dealloc instead), but there's now at least one case where it *is* populated from C (generators), which means it behaves *as if* __del__ is defined (since the interpreter actually checks the tp_del slot), but *looks* like __del__ *isn't* defined (since there is no wrapper created).

Independent of the memory leak concerns with generators defining tp_del, it would be better if a wrapper function was defined so the existence of the method was at least visible from Python code.

----------
components: Interpreter Core
messages: 187409
nosy: ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Expose __del__ when tp_del is populated from C code
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 20 09:21:11 2013
From: report at bugs.python.org (C Anthony Risinger)
Date: Sat, 20 Apr 2013 07:21:11 +0000
Subject: [New-bugs-announce] [issue17801] Tools/scripts/gprof2html.py: `#!
	/usr/bin/env python32.3`
Message-ID: <1366442471.25.0.489918291616.issue17801@psf.upfronthosting.co.za>


New submission from C Anthony Risinger:

http://hg.python.org/cpython/file/d499189e7758/Tools/scripts/gprof2html.py#l1

...should be self explanatory.

i didn't run into this myself, but i saw that the Archlinux package was fixing it via `sed`, without the customary link to upstream... so here it is ;)

----------
components: Demos and Tools
messages: 187411
nosy: C.Anthony.Risinger
priority: normal
severity: normal
status: open
title: Tools/scripts/gprof2html.py: `#! /usr/bin/env python32.3`
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/issue17801>
_______________________________________

From report at bugs.python.org  Sat Apr 20 12:58:16 2013
From: report at bugs.python.org (Baptiste Mispelon)
Date: Sat, 20 Apr 2013 10:58:16 +0000
Subject: [New-bugs-announce] [issue17802] html.HTMLParser raises
	UnboundLocalError:
Message-ID: <1366455496.44.0.252693262326.issue17802@psf.upfronthosting.co.za>


New submission from Baptiste Mispelon:

When trying to parse the string `a&b`, the parser raises an UnboundLocalError:

{{{
>>> from html.parser import HTMLParser
>>> p = HTMLParser()
>>> p.feed('a&b')
>>> p.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/html/parser.py", line 149, in close
    self.goahead(1)
  File "/usr/lib/python3.3/html/parser.py", line 252, in goahead
    if k <= i:
UnboundLocalError: local variable 'k' referenced before assignment
}}}

Granted, the HTML is invalid, but this error looks like it might have been an oversight.

----------
components: Library (Lib)
messages: 187414
nosy: bmispelon
priority: normal
severity: normal
status: open
title: html.HTMLParser raises UnboundLocalError:
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 20 13:57:47 2013
From: report at bugs.python.org (Yasuhiro Fujii)
Date: Sat, 20 Apr 2013 11:57:47 +0000
Subject: [New-bugs-announce] [issue17803] Calling Tkinter.Tk() with a
	baseName keyword argument	throws UnboundLocalError
Message-ID: <1366459067.56.0.563805479218.issue17803@psf.upfronthosting.co.za>


New submission from Yasuhiro Fujii:

Calling Tkinter.Tk() with baseName keyword argument throws UnboundLocalError on Python 2.7.4.

A process to reproduce the bug:
>>> import Tkinter
>>> Tkinter.Tk(baseName="test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1748, in __init__
    if not sys.flags.ignore_environment:
UnboundLocalError: local variable 'sys' referenced before assignment

A patch to fix the bug:
--- Lib/lib-tk/Tkinter.py.orig
+++ Lib/lib-tk/Tkinter.py
@@ -1736,7 +1736,7 @@
         # ensure that self.tk is always _something_.
         self.tk = None
         if baseName is None:
-            import sys, os
+            import os
             baseName = os.path.basename(sys.argv[0])
             baseName, ext = os.path.splitext(baseName)
             if ext not in ('.py', '.pyc', '.pyo'):

----------
components: Tkinter
messages: 187418
nosy: y-fujii
priority: normal
severity: normal
status: open
title: Calling Tkinter.Tk() with a baseName keyword argument throws UnboundLocalError
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 20 22:33:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Apr 2013 20:33:23 +0000
Subject: [New-bugs-announce] [issue17804] streaming struct unpacking
Message-ID: <1366490003.51.0.571307288216.issue17804@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

For certain applications, you want to unpack repeatedly the same pattern. This came in issue17618 (base85 decoding), where you want to unpack a stream of bytes as 32-bit big-endian unsigned ints. The solution adopted in issue17618 patch (struct.Struct("!{}I")) is clearly suboptimal.

I would suggest something like a iter_unpack() function which would repeatedly yield tuples until the bytes object is over.

----------
components: Library (Lib)
messages: 187455
nosy: mark.dickinson, meador.inge, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: streaming struct unpacking
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 20 23:44:09 2013
From: report at bugs.python.org (Takafumi Arakaki)
Date: Sat, 20 Apr 2013 21:44:09 +0000
Subject: [New-bugs-announce] [issue17805] No such class:
	multiprocessing.pool.AsyncResult
Message-ID: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za>


New submission from Takafumi Arakaki:

Document mentions AsyncResult but there is no such class.
http://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.AsyncResult

You can check it by simply running:
python -c 'from multiprocessing.pool import AsyncResult'

I think it means ApplyResult so I made a patch (attached).

Note that there managers.py also uses name 'AsyncResult':
% hg grep AsyncResult
Doc/library/multiprocessing.rst:83232:.. class:: AsyncResult
Lib/multiprocessing/managers.py:81039:    'apply_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:    'map_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:    'starmap_async': 'AsyncResult',
Lib/multiprocessing/managers.py:81039:SyncManager.register('AsyncResult', create_method=False)

Probably renaming them would be better?

----------
assignee: docs at python
components: Documentation
files: ApplyResult.patch
keywords: patch
messages: 187466
nosy: docs at python, tkf
priority: normal
severity: normal
status: open
title: No such class: multiprocessing.pool.AsyncResult
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/file29954/ApplyResult.patch

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

From report at bugs.python.org  Sun Apr 21 03:19:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Apr 2013 01:19:14 +0000
Subject: [New-bugs-announce] [issue17806] Add keyword args support to
	str/bytes.expandtabs()
Message-ID: <1366507154.61.0.217389659931.issue17806@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The attached patch adds keyword args support to str/bytes.expandtabs():
>>> 'a\tb'.expandtabs(tabsize=8)
'a       b'
>>> b'a\tb'.expandtabs(tabsize=8)
b'a       b'

----------
assignee: ezio.melotti
components: Interpreter Core
files: expandtabs.diff
keywords: patch
messages: 187481
nosy: ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: Add keyword args support to str/bytes.expandtabs()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29958/expandtabs.diff

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

From report at bugs.python.org  Sun Apr 21 03:37:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Apr 2013 01:37:31 +0000
Subject: [New-bugs-announce] [issue17807] Generator cleanup without tp_del
Message-ID: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This experimental patch proposes to defer generator cleanup to the frame itself. In this scheme, the generator frame's tp_clear throws the GeneratorExit if necessary, so as to call cleanup code. The generator doesn't have any tp_del anymore, as it is now impossible to resurrect a generator (the frame, though, can be resurrected; I have to add a test for that).

The net effect is that generators caught in a reference cycle can always be reclaimed, and their cleanup code is run in a valid frame.

----------
components: Interpreter Core
files: gen2.patch
keywords: patch
messages: 187482
nosy: benjamin.peterson, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Generator cleanup without tp_del
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29959/gen2.patch

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

From report at bugs.python.org  Sun Apr 21 04:57:33 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sun, 21 Apr 2013 02:57:33 +0000
Subject: [New-bugs-announce] [issue17808] No code example for Event object
	in threading module
Message-ID: <1366513053.37.0.736959521672.issue17808@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

Documentation for Event objects in threading module could be more clear with a code example.

http://docs.python.org/3.4/library/threading.html#event-objects

----------
messages: 187486
nosy: amysyk
priority: normal
severity: normal
status: open
title: No code example for Event object in threading module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 21 07:37:29 2013
From: report at bugs.python.org (koobs)
Date: Sun, 21 Apr 2013 05:37:29 +0000
Subject: [New-bugs-announce] [issue17809] FAIL: test_expanduser when $HOME
	ends with /
Message-ID: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za>


New submission from koobs:

test_expanduser in test.test_posixpath.PosixPathTest fails when the users $HOME ends with "/"

======================================================================
FAIL: test_expanduser (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd/build/Lib/test/test_posixpath.py", line 264, in test_expanduser
    self.assertEqual(posixpath.expanduser("~"), home)
AssertionError: '/usr/home/buildbot' != '/usr/home/buildbot/'
- /usr/home/buildbot
+ /usr/home/buildbot/
?                   +
----------------------------------------------------------------------

Test failures can be seen in the following FreeBSD 9-STABLE buildbots on all branches except 2.7:

3.x - http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.x/builds/1256/steps/test/logs/stdio
3.3 - http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.3/builds/546/steps/test/logs/stdio
3.2 - http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%20dtrace%203.2/builds/490/steps/test/logs/stdio

It is also reproducible outside of the buildbot environment using fresh Python 3.3.1 sources with default build configuration (see attached expanduser.log)

Commenting out Lib/test/test_posixpath.py#l264 results in the test passing

----------
components: Library (Lib), Tests
files: expanduser.log
messages: 187494
nosy: koobs
priority: normal
severity: normal
status: open
title: FAIL: test_expanduser when $HOME ends with /
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29964/expanduser.log

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

From report at bugs.python.org  Sun Apr 21 08:48:58 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 21 Apr 2013 06:48:58 +0000
Subject: [New-bugs-announce] [issue17810] Implement PEP 3154 (pickle
	protocol 4)
Message-ID: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

I have restarted the work on PEP 3154. Stefan Mihaila had begun an implementation as part of the Google Summer of Code 2012. Unfortunately, he hit multiple roadblocks which prevented him to finish his work by the end of the summer. He previously shown interest in completing his implementation. However he got constrained by time and never resumed his work.

So I am taking over the implementation of the PEP. I have decided to go forward with a brand new code, using Stefan's work only as a guide. At the moment, I have completed about half of the PEP---missing only support for calling __new__ with keyword arguments and the use of new qualified name for referring objects.

Design-wise, there is still a few things that we should discuss. For example, I think Stefan's idea, which is not specified in the PEP, to eliminate PUT opcodes is interesting. His proposal was to emit an implicit PUT opcode after each object pickled and make the Pickler and Unpickler classes agree on the scheme. A drawback of this implicit scheme is we cannot be selective about which object we save in the memo during unpickling. That means, for example, we won't be able to make pickletools.optimize work with protocol 4 to reduce the memory footprint of the unpickling process. This scheme also alters the meaning of all previously defined opcodes because of the implicit PUTs, which is sort of okay because we are changing protocol. Alternatively, we could use an explicit scheme by defining new "fat" opcodes, for the built-in types we care about, which includes memoization. This scheme would a bit more flexible however it would also be slightly more involved implementation-wise. In any case, I will run benchmarks to see if either schemes are worthwhile.

----------
assignee: alexandre.vassalotti
components: Library (Lib)
hgrepos: 184
messages: 187496
nosy: alexandre.vassalotti, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Implement PEP 3154 (pickle protocol 4)
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 21 23:24:28 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 21:24:28 +0000
Subject: [New-bugs-announce] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
Message-ID: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

The os.writev and os.readv functions are currently documented as:

os.writev(fd, buffers)

    Write the contents of buffers to file descriptor fd, where buffers is an arbitrary sequence of buffers. Returns the total number of bytes written.

os.readv(fd, buffers)

    Read from a file descriptor into a number of writable buffers. buffers is an arbitrary sequence of writable buffers. Returns the total number of bytes read.


This is rather confusing, mostly because it's not clear what can be passed as *buffer* (since buffer objects don't exist in Python 3 anymore), and (as a consequence) how the input will be distributed among the list of buffers.

Reading the code, it seems to me that any object that implements the buffer protocol would be fine, but that still doesn't help much in practice. From the memoryview documentation, I can infer that `bytes` implements the buffer protocol, but is also immutable, so how can something be written into it?

I'd be happy to write a patch to the documentation, but someone would need to explain to me first what kind of buffers are actually acceptable (and I suspect this will be different for readv and writev).

----------
assignee: docs at python
components: Documentation
messages: 187526
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Improve os.readv() and os.writev() documentation and docstring
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 21 23:34:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 21 Apr 2013 21:34:19 +0000
Subject: [New-bugs-announce] [issue17812] Quadratic complexity in b32encode
Message-ID: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

b32encode accumulates encoded data in a bytes object and this operation has quadratic complexity.

Here is a patch, which fixes this issue by accumulating in a list.

----------
components: Library (Lib)
files: base32_fix.patch
keywords: patch
messages: 187527
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Quadratic complexity in b32encode
type: performance
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29971/base32_fix.patch

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

From report at bugs.python.org  Mon Apr 22 00:05:07 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 22:05:07 +0000
Subject: [New-bugs-announce] [issue17813] lzma and bz2 decompress methods
	lack max_size attribute
Message-ID: <1366581907.51.0.777368903496.issue17813@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

The zlib Decompress.decompress has a max_length parameter that limits the size of the returned uncompressed data.

The lzma and bz2 decompress methods do not have such a parameter.

Therefore, it is not possible to decompress untrusted lzma or bz2 data without becoming susceptible to a DoS attack, as the attacker can force allocation of gigantic buffers by sending just a tiny amount of compressed data:

$ dd if=/dev/zero bs=128k count=10k | bzip2 -9 > nasty.bz2
10240+0 records in
10240+0 records out
1342177280 bytes (1.3 GB) copied, 11.0892 s, 121 MB/s
$ dir nasty.bz2 
-rw-rw-r-- 1 nikratio nikratio 977 Apr 21 14:58 nasty.bz2


It would be great if the lzma and bz2 decompressor methods could also get a max_length parameters to make this situation less threatening.

----------
components: Library (Lib)
messages: 187532
nosy: Nikratio
priority: normal
severity: normal
status: open
title: lzma and bz2 decompress methods lack max_size attribute
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Apr 22 01:14:46 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 21 Apr 2013 23:14:46 +0000
Subject: [New-bugs-announce] [issue17814] Popen.stdin/stdout/stderr
	documentation should mention	object type
Message-ID: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

The subprocess documentation currently just says that Popen.stdin et all are "file objects", which is linked to the glossary entry. This isn't very helpful, as it doesn't tell whether the streams are bytes or text streams.

Suggested patch:

diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
--- a/Doc/library/subprocess.rst
+++ b/Doc/library/subprocess.rst
@@ -677,21 +677,29 @@
 
 .. attribute:: Popen.stdin
 
-   If the *stdin* argument was :data:`PIPE`, this attribute is a :term:`file
-   object` that provides input to the child process.  Otherwise, it is ``None``.
+   If the *stdin* argument was :data:`PIPE`, this attribute is a
+   :class:`io.BufferedWriter` (if the *universal_newlines* argument
+   was False) or :class:`io.TextIOWrapper` (if the
+   *universal_newlines* argument was True) object that provides input
+   to the child process. Otherwise, it is ``None``.
 
 
 .. attribute:: Popen.stdout
 
-   If the *stdout* argument was :data:`PIPE`, this attribute is a :term:`file
-   object` that provides output from the child process.  Otherwise, it is ``None``.
+   If the *stdout* argument was :data:`PIPE`, this attribute is a
+   :class:`io.BufferedReader` (if the *universal_newlines* argument
+   was False) or :class:`io.TextIOWrapper` (if the
+   *universal_newlines* argument was True) object that provides output
+   from the child process. Otherwise, it is ``None``.
 
 
 .. attribute:: Popen.stderr
 
-   If the *stderr* argument was :data:`PIPE`, this attribute is a :term:`file
-   object` that provides error output from the child process.  Otherwise, it is
-   ``None``.
+   If the *stderr* argument was :data:`PIPE`, this attribute is a
+   :class:`io.BufferedReader` (if the *universal_newlines* argument
+   was False) or :class:`io.TextIOWrapper` (if the
+   *universal_newlines* argument was True) object that provides output
+   from the child process. Otherwise, it is ``None``.
 
 
 .. attribute:: Popen.pid

----------
assignee: docs at python
components: Documentation
messages: 187535
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Popen.stdin/stdout/stderr documentation should mention object type
type: enhancement

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

From report at bugs.python.org  Mon Apr 22 17:15:08 2013
From: report at bugs.python.org (Theodoros Ikonomou)
Date: Mon, 22 Apr 2013 15:15:08 +0000
Subject: [New-bugs-announce] [issue17815] itertools.combinations example is
	overly complicated
Message-ID: <1366643708.73.0.241168668546.issue17815@psf.upfronthosting.co.za>


New submission from Theodoros Ikonomou:

I find the code presented as equivalent for itertools.combinations is overly complex.
I think we can change it to something easier like the following:

def combinations(iterable, r):
    i, size = 0, len(iterable)
    while i + r - 1 < size:
        subindex = i+1
        while subindex + r - 2 < size:
                yield (iterable[i],) + tuple(iterable[subindex:subindex+r-1])
                subindex += r - 1
        i += 1

----------
assignee: docs at python
components: Documentation
messages: 187566
nosy: Theodoros.Ikonomou, docs at python
priority: normal
severity: normal
status: open
title: itertools.combinations example is overly complicated
type: behavior
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/issue17815>
_______________________________________

From report at bugs.python.org  Mon Apr 22 18:41:04 2013
From: report at bugs.python.org (Nils Bruin)
Date: Mon, 22 Apr 2013 16:41:04 +0000
Subject: [New-bugs-announce] [issue17816] Weak*Dictionary KeyErrors during
	callbacks
Message-ID: <1366648864.21.0.829843721965.issue17816@psf.upfronthosting.co.za>


New submission from Nils Bruin:

The following program is a little dependent on memory layout but will usually generate lots of

    Exception KeyError: (A(9996),) in <function remove at 0xa47050> ignored

messages in Python 2.7.

    import weakref

    class A(object):
        def __init__(self,n):
            self.n=n
        def __repr__(self):
            return "A(%d)"%self.n

    def mess(n):
        D=weakref.WeakValueDictionary()
        L=[A(i) for i in range(n)]
        for i in range(n-1):
            j=(i+10)%n
            D[L[i]]=L[j]
        return D

    D=mess(10000)
    D.clear()

The reason is that on D.clear() all entries are removed from D before actually deleting those entries. Once the entries are deleted one-by-one, sometimes the removal of a key will result in deallocation of that key, which may be a not-yet-deleted ex-value of the dictionary as well. The callback triggers on the weakref, but the dict itself was already emptied, so nothing is found.

I've checked and on Python 3.2.3 this problem does not seem to occur. I haven't checked the Python source to see how Python 3 behaves differently and whether that behaviour would be easy to backport to fix this bug in 2.7.

----------
components: Library (Lib)
messages: 187570
nosy: Nils.Bruin
priority: normal
severity: normal
status: open
title: Weak*Dictionary KeyErrors during callbacks
versions: Python 2.7

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

From report at bugs.python.org  Mon Apr 22 19:57:22 2013
From: report at bugs.python.org (=?utf-8?q?Ricardo_Gonz=C3=A1lez?=)
Date: Mon, 22 Apr 2013 17:57:22 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue17817=5D_=C2=BFBug_Python_2?=
 =?utf-8?b?LjcuNCBhbmQgdmVyc2lvbiAzLjMuMT8=?=
Message-ID: <1366653442.82.0.335522989154.issue17817@psf.upfronthosting.co.za>


New submission from Ricardo Gonz?lez:

Hello,

There seems to be a bug in versions 2.7.4 and 3.3.1 by typing the following error in IDLE (Python GUI) Windows 8 64 bit:

Python 2.7.4 (default, Apr  6 2013, 19:55:15) [MSC v.1500 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> exit()
>>> modules

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    modules
NameError: name 'modules' is not defined
>>> help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/2.7/tutorial/
.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help>
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    help()
  File "C:\Python27\lib\site.py", line 467, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Python27\lib\pydoc.py", line 1751, in __call__
    self.interact()
  File "C:\Python27\lib\pydoc.py", line 1763, in interact
    request = self.getline('help> ')
  File "C:\Python27\lib\pydoc.py", line 1774, in getline
    return raw_input(prompt)
  File "C:\Python27\lib\idlelib\PyShell.py", line 1347, in readline
    raise ValueError("read from closed file")
ValueError: read from closed file
>>> quit
Use quit() or Ctrl-Z plus Return to exit
>>> quit()
>>>

Pressing Ctrl-Z is not closed and if we write exit() or quit() either, this happens in both 2.7.4 and 3.3.1 versions.

Regards.

----------
components: IDLE, Windows
messages: 187575
nosy: Ricardo
priority: normal
severity: normal
status: open
title: ?Bug Python 2.7.4 and version 3.3.1?
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 22 21:37:34 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 22 Apr 2013 19:37:34 +0000
Subject: [New-bugs-announce] [issue17818]
	aifc.Aifc_read/Aifc_write.getparams can return a	namedtuple
Message-ID: <1366659454.45.0.422161537493.issue17818@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello!

Given the fact that issue 17487 was accepted, I think that is a good idea for aifc.Aifc_read/Aifc_write.getparams to return a namedtuple as well, so that both modules will behave consistently with each other. 
I've attached a patch for this. 
Thanks in advance!

----------
components: Library (Lib)
files: aifc.patch
keywords: patch
messages: 187584
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: aifc.Aifc_read/Aifc_write.getparams can return a namedtuple
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29980/aifc.patch

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

From report at bugs.python.org  Tue Apr 23 02:22:35 2013
From: report at bugs.python.org (Antonio Cavallo)
Date: Tue, 23 Apr 2013 00:22:35 +0000
Subject: [New-bugs-announce] [issue17819] removes need for CONFIG_SITE
	external configuration
Message-ID: <1366676555.13.0.0940928027778.issue17819@psf.upfronthosting.co.za>


New submission from Antonio Cavallo:

This patch introduces two new options (--enable-ptmx, --enable-ptc) to  
the configure script.

In cross compile the actual code requires an external config.site config file to
set the result values for the AC_CHECK_FILE macros on /dev/ptmx, /dev/ptc.

These flags forces (if given) the result of the AC_CHECK_FILE macros: if the flags aren't given then the AC_CHECK_FILE tests are run as normal providing an error message when in cross compile mode (explicit behavior).


(patch applied on revision 251c5b4bb05d)

----------
components: Build, Cross-Build
files: configure.ac.patch
keywords: patch
messages: 187599
nosy: cavallo71
priority: normal
severity: normal
status: open
title: removes need for CONFIG_SITE external configuration
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29983/configure.ac.patch

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

From report at bugs.python.org  Tue Apr 23 05:09:19 2013
From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=)
Date: Tue, 23 Apr 2013 03:09:19 +0000
Subject: [New-bugs-announce] [issue17820] Nothing about editors in "Key
	Resources"
Message-ID: <1366686559.8.0.839057541832.issue17820@psf.upfronthosting.co.za>


New submission from Guilherme Sim?es:

In devguide/setup#editors-and-tools we have:

"For editors and tools which the core developers have felt some special comment is needed for coding in Python, see Key Resources."

Since emacs and other tools are mentioned in "Additional Resources" instead I think the link to "Key Resources" should be replaced by a link to "Additional Resources".

----------
components: Devguide
messages: 187604
nosy: Guilherme.Sim?es, Todd.Rovito, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Nothing about editors in "Key Resources"
type: behavior

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

From report at bugs.python.org  Tue Apr 23 11:19:59 2013
From: report at bugs.python.org (Philippe Rouquier)
Date: Tue, 23 Apr 2013 09:19:59 +0000
Subject: [New-bugs-announce] [issue17821] Different division results with /
	and // operators with	large numbers
Message-ID: <1366708799.03.0.595068408513.issue17821@psf.upfronthosting.co.za>


New submission from Philippe Rouquier:

Hi,

the following statement yields different results in python2 and python3:
284397269195572115652769428988866694680//17 - int(284397269195572115652769428988866694680/17)

In python3 it yields:
309657313492949847071

In python2 it yields:
OL

Python2's result seems to be correct as (284397269195572115652769428988866694680//17) and (int(284397269195572115652769428988866694680/17)) should return the same result (as far as I understand).

With smaller numbers, this difference in results does not appear with python3.

Note: I noticed this, while working on RSA; 284397269195572115652769428988866694680 is (p-1)(q-1) and 17 is e. I just mention this in case it could help.

I used linux version 3.3.3.0 and 2.7.3 for the tests on a 64 bits processor.

Sorry if I am missing something here.

----------
components: Interpreter Core
messages: 187623
nosy: Philippe.Rouquier
priority: normal
severity: normal
status: open
title: Different division results with / and // operators with large numbers
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 23 15:13:33 2013
From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=)
Date: Tue, 23 Apr 2013 13:13:33 +0000
Subject: [New-bugs-announce] [issue17822] Save on Close windows (IDLE)
Message-ID: <1366722813.3.0.645227250665.issue17822@psf.upfronthosting.co.za>


New submission from Guilherme Sim?es:

After changing the contents of a file in an Editor Window and closing without saving the "Save on Close" window pops up. On both MacOS and Linux the user can't do anything on the Editor Window anymore, but on Windows, not only can the user continue to write it is possible to try to close the window again. Each time the user attempts to close the editor the "Save on Close" window appears one more time.

Also, when you have 2 such windows if you say 'no' then,no matter what the answer to the second window is, IDLE crashes.

I'm not sure but this seems to me to be a Tk problem. Attached is a simple script that works completely different on different systems showing that this is probably a Tkinter or Tk bug.

I tested this on Mac with Python 2.7, 3.3, 3.4 and Tk 8.5.13. On Linux I tested with Python 3.2 and Tk 8.5.11 and on Windows with Python 3.3 and Tk 8.5.11.

----------
components: IDLE, Tkinter, Windows
files: askyesnocancel.py
messages: 187641
nosy: Guilherme.Sim?es, Todd.Rovito, gpolo, roger.serwy, terry.reedy
priority: normal
severity: normal
status: open
title: Save on Close windows (IDLE)
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file29992/askyesnocancel.py

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

From report at bugs.python.org  Tue Apr 23 20:11:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 23 Apr 2013 18:11:54 +0000
Subject: [New-bugs-announce] [issue17823] 2to3 fixers for
Message-ID: <1366740714.43.0.637419404969.issue17823@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Quoting Victor Stinner from msg106669:

"""
It's maybe possible for write some 2to3 fixers for the following examples:

"...".encode("base64") => base64.b64encode("...")
"...".encode("rot13") => do nothing (but display a warning?)
"...".encode("zlib") => zlib.compress("...")
"...".encode("hex") => base64.b16encode("...")
"...".encode("bz2") => bz2.compress("...")

"...".decode("base64") => base64.b64decode("...")
"...".decode("rot13") => do nothing (but display a warning?)
"...".decode("zlib") => zlib.decompress("...")
"...".decode("hex") => base64.b16decode("...")
"...".decode("bz2") => bz2.decompress("...")
"""

Unfortunately I don't know where is the syntax for writing fixers.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 187662
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: 2to3 fixers for
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 24 04:59:30 2013
From: report at bugs.python.org (Gustavo Niemeyer)
Date: Wed, 24 Apr 2013 02:59:30 +0000
Subject: [New-bugs-announce] [issue17824] pty.spawn handles errors improperly
Message-ID: <1366772370.17.0.184801312009.issue17824@psf.upfronthosting.co.za>


New submission from Gustavo Niemeyer:

This simple script will spawn N Python interpreters that aren't properly collected due to the improper error handling:

import pty
for i in range(N):
    try: pty.spawn(["/non-existent"])
    except: pass

----------
components: Library (Lib)
messages: 187681
nosy: niemeyer
priority: normal
severity: normal
status: open
title: pty.spawn handles errors improperly
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Apr 24 09:46:22 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 24 Apr 2013 07:46:22 +0000
Subject: [New-bugs-announce] [issue17825] Indentation.offset and
	SyntaxError.offset mismatch
Message-ID: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

I noticed a difference between computation of column offset for SyntaxError and IndentationError (a subclass of SyntaxError).
It is slightly confusing.


def report(exc):
    print('lineno %s, offset %s' % (exc.lineno, exc.offset))
    raise

try:
    exec('except IOError:')
except Exception as e:
    report(e)

try:
    exec('    open(filepath)')
except Exception as e:
    report(e)


** OUTPUT **
lineno 1, offset 6
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "<stdin>", line 2, in <module>
  File "<string>", line 1
    except IOError:
         ^
SyntaxError: invalid syntax

lineno 1, offset 4
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "<stdin>", line 2, in <module>
  File "<string>", line 1
    open(filepath)
    ^
IndentationError: unexpected indent


** Analysis **

Case (1): offset is 6, and caret is below column 5 for SyntaxError
Case (2): offset is 4, and caret is below column 4 for IndentationError

----------
messages: 187690
nosy: flox
priority: normal
severity: normal
status: open
title: Indentation.offset and SyntaxError.offset mismatch
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Apr 24 12:00:08 2013
From: report at bugs.python.org (Michael Foord)
Date: Wed, 24 Apr 2013 10:00:08 +0000
Subject: [New-bugs-announce] [issue17826] Setting a side_effect on mock from
	create_autospec	doesn't work
Message-ID: <1366797608.02.0.0150366437779.issue17826@psf.upfronthosting.co.za>


New submission from Michael Foord:

>>> from unittest.mock import create_autospec
>>> def f(): pass
... 
>>> m = create_autospec(f)
>>> m.side_effect = [1, 2]
>>> m()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in f
  File "/compile/py3k-cpython/Lib/unittest/mock.py", line 872, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/compile/py3k-cpython/Lib/unittest/mock.py", line 931, in _mock_call
    result = next(effect)
TypeError: 'list' object is not an iterator

----------
assignee: michael.foord
components: Library (Lib)
messages: 187692
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Setting a side_effect on mock from create_autospec doesn't work
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 24 15:45:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 24 Apr 2013 13:45:40 +0000
Subject: [New-bugs-announce] [issue17827] Document codecs.encode and
	codecs.decode
Message-ID: <1366811140.15.0.0983174574305.issue17827@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The codecs module has long offered encode() and decode() convenience functions (since 2004: http://hg.python.org/cpython-fullhistory/rev/8ea2cb1ec598), but they're not documented (except through docstrings). We should fix that.

>From the docstrings:
==========
encode(obj, [encoding[,errors]]) -> object

Encodes obj using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a ValueError. Other possible values are 'ignore', 'replace' and
'xmlcharrefreplace' as well as any other name registered with
codecs.register_error that can handle ValueErrors.
==========
decode(obj, [encoding[,errors]]) -> object

Decodes obj using the codec registered for encoding. encoding defaults
to the default encoding. errors may be given to set a different error
handling scheme. Default is 'strict' meaning that encoding errors raise
a ValueError. Other possible values are 'ignore' and 'replace'
as well as any other name registered with codecs.register_error that is
able to handle ValueErrors.
==========

Note that the difference between the convenience functions in the codecs module and the methods on str, bytes and bytearray is that the latter have additional type checks to limit their usage to text encodings. str.encode expects a str->bytes conversion, while bytes.decode and bytearray.decode both expect the codec to produce a str object. codecs.encode and codecs.decode are both arbitrary object->object conversions, limited only by whatever the chosen codec supports.

----------
assignee: docs at python
components: Documentation
messages: 187700
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Document codecs.encode and codecs.decode
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Apr 24 16:09:58 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 24 Apr 2013 14:09:58 +0000
Subject: [New-bugs-announce] [issue17828] More informative error handling
	when encoding and	decoding
Message-ID: <1366812598.92.0.4116744942.issue17828@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Passing the wrong types to codecs can currently lead to rather confusing exceptions, like:

====================
>>> b"ZXhhbXBsZQ==\n".decode("base64_codec")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/encodings/base64_codec.py", line 20, in base64_decode
    return (base64.decodebytes(input), len(input))
  File "/usr/lib64/python3.2/base64.py", line 359, in decodebytes
    raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not memoryview
====================
>>> codecs.decode("example", "utf8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.2/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
TypeError: 'str' does not support the buffer interface
====================

This situation could be improved by having the affected APIs use the exception chaining system to wrap these errors in a more informative exception that also display information on the codec involved. Note that UnicodeEncodeError and UnicodeDecodeError are not appropriate, as those are specific to text encoding operations, while these new wrappers will apply to arbitrary codecs, regardless of whether or not they use the unicode error handlers. Furthermore, for backwards compatibility with existing exception handling, it is probably necessary to limit ourselves to specific exception types and ensure that the wrapper exceptions are subclasses of those types.

These new wrappers would have __cause__ set to the exception raised by the codec, but emit a message more along the lines of the following:

==============
codecs.DecodeTypeError: encoding='utf8', details="TypeError: 'str' does not support the buffer interface"
==============

Wrapping TypeError and ValueError should cover most cases, which would mean four new exception types in the codecs module:

Raised by codecs.decode, bytes.decode and bytearray.decode:
* codecs.DecodeTypeError
* codecs.DecodeValueError

Raised by codecs.encode, str.encode:
* codecs.EncodeTypeError
* codecs.EncodeValueError

Instances of UnicodeError wouldn't be wrapped, since they already contain codec information.

----------
components: Library (Lib)
messages: 187704
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: More informative error handling when encoding and decoding
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 24 17:06:00 2013
From: report at bugs.python.org (Ghislain Hivon)
Date: Wed, 24 Apr 2013 15:06:00 +0000
Subject: [New-bugs-announce] [issue17829] csv.Sniffer.snif doesn't set up
	the dialect properly for	a csv created with
	dialect=csv.excel_tab and containing quote (") char
Message-ID: <1366815960.68.0.342437673136.issue17829@psf.upfronthosting.co.za>


New submission from Ghislain Hivon:

When sniffing the dialect of a file created with the csv module with dialect=csv.excel_tab and one of the row contain a quote ("), the delimiter is set to ' ' instead of '\t'.

----------
files: csv_sniffing_excel_tab.py
messages: 187709
nosy: GhislainHivon
priority: normal
severity: normal
status: open
title: csv.Sniffer.snif doesn't set up the dialect properly for a csv created with dialect=csv.excel_tab and containing quote (") char
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file30001/csv_sniffing_excel_tab.py

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

From report at bugs.python.org  Wed Apr 24 17:29:10 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 24 Apr 2013 15:29:10 +0000
Subject: [New-bugs-announce] [issue17830] Fix test_keyword on Windows,
	clean up addCleanup
Message-ID: <1366817350.3.0.0113666626192.issue17830@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Copying the nosy list from issue9607)

test_keyword has a couple of failures on Windows, all due to newline issues--see for example http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1845/steps/test/logs/stdio.  

test_keywords_py_without_markers_produces_error looks for a line ending with '\n', but Windows ends it with '\r\n'.  

test_real_grammar_and_keyword_file, on the other hand, doesn't fail on my machine, due to the hg eol extension being enabled, but the cause of failure is filecmp.cmp working only in binary mode and paying no attention to line endings.

The attached patch fixes both failures, with and without the eol extension, by using a private _compare_files function instead of filecmp.cmp.  The private function makes use of universal newlines to avoid issue.  Also, all instances of ``self.addCleanup(lambda ...)`` have had the lambda removed as suggested by ?ric Araujo in msg187567.

----------
components: Tests
files: test_keyword_cleanup.diff
keywords: patch
messages: 187710
nosy: benjamin.peterson, eric.araujo, gregmalcolm, r.david.murray, zach.ware
priority: normal
severity: normal
status: open
title: Fix test_keyword on Windows, clean up addCleanup
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file30002/test_keyword_cleanup.diff

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

From report at bugs.python.org  Wed Apr 24 17:48:12 2013
From: report at bugs.python.org (Nataly Glazyrina)
Date: Wed, 24 Apr 2013 15:48:12 +0000
Subject: [New-bugs-announce] [issue17831] urllib.URLopener.open breaks
	ActiveDirectory user
Message-ID: <1366818492.16.0.0758533626758.issue17831@psf.upfronthosting.co.za>


New submission from Nataly Glazyrina:

When I try to open file from ftp by path like 
'ftp://domain\user:password at my.path'

line 
'fullurl = quote(fullurl, safe="%/:=&?~#+!$,;'@()*[]|")'

changes 'domain\user' to 'domain%5Cuser' and brokes username.
As a result - error 530 on login to ftp.

----------
messages: 187711
nosy: Nataly.Glazyrina
priority: normal
severity: normal
status: open
title: urllib.URLopener.open breaks ActiveDirectory user

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

From report at bugs.python.org  Wed Apr 24 17:51:03 2013
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 24 Apr 2013 15:51:03 +0000
Subject: [New-bugs-announce] [issue17832] pythonrun.c:_print_total_refs
	missing prototype
Message-ID: <1366818663.02.0.0958577482623.issue17832@psf.upfronthosting.co.za>


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


----------
components: Interpreter Core
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: pythonrun.c:_print_total_refs missing prototype
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 24 20:35:30 2013
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 24 Apr 2013 18:35:30 +0000
Subject: [New-bugs-announce] [issue17833] test_gdb broken PPC64 Linux
Message-ID: <1366828530.65.0.489906336326.issue17833@psf.upfronthosting.co.za>


New submission from David Edelsohn:

Verify that "py-bt" indicates threads that are waiting for the GIL ... FAIL

FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_gdb.py", line 717, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 at 0x100ee8b0: file Python/bltinmodule.c, line 967.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n[New Thread 0x3fffb14af200 (LWP 1699)]\n[New Thread 0x3fffb0caf200 (LWP 1703)]\n[New Thread 0x3fffabfff200 (LWP 1711)]\n[New Thread 0x3fffab7ff200 (LWP 1730)]\n\nBreakpoint 1, builtin_id (self=<module at remote 0x3fffb17dc058>, v=42) at Python/bltinmodule.c:967\n967\t    return PyLong_FromVoidPtr(v);\n\nThread 5 (Thread 0x3fffab7ff200 (LWP 1730)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 642, in _bootstrap_inner\n    self.run()\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 619, in _bootstrap\n    self._bootstrap_inner()\n\nThread 4 (Thread 0x3fffabfff200 (LWP 1711)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 642, in _bootstrap_inner\n    self.run()\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 619, in _bootstrap\n    self._bootstrap_inner()\n\nThread 3 (Thread 0x3fffb0caf200 (LWP 1703)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 642, in _bootstrap_inner\n    self.run()\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 619, in _bootstrap\n    self._bootstrap_inner()\n\nThread 2 (Thread 0x3fffb14af200 (LWP 1699)):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 642, in _bootstrap_inner\n    self.run()\n  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 619, in _bootstrap\n    self._bootstrap_inner()\n\nThread 1 (Thread 0x8074e46670 (LWP 1616)):\nTraceback (most recent call first):\n  File "<string>", line 18, in <module>\n'

----------
components: Tests
messages: 187720
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: test_gdb broken PPC64 Linux
versions: Python 3.4

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

From report at bugs.python.org  Wed Apr 24 20:52:33 2013
From: report at bugs.python.org (Daniel Wong)
Date: Wed, 24 Apr 2013 18:52:33 +0000
Subject: [New-bugs-announce] [issue17834] Add Heap (and DynamicHeap) classes
	to heapq module
Message-ID: <1366829553.37.0.470727650744.issue17834@psf.upfronthosting.co.za>


New submission from Daniel Wong:

heapq already provides a bunch of functions for manipulating lists that preserve (or create) a heap invariant. My change adds two classes for representing heaps. These classes ensure that operations that violate the heap invariant are not possible (through the public interface). The also allow customization via subclassing.

----------
components: Library (Lib)
files: heap.patch
hgrepos: 185
keywords: patch
messages: 187723
nosy: allyourcode
priority: normal
severity: normal
status: open
title: Add Heap (and DynamicHeap) classes to heapq module
type: enhancement
Added file: http://bugs.python.org/file30004/heap.patch

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

From report at bugs.python.org  Wed Apr 24 21:02:53 2013
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 24 Apr 2013 19:02:53 +0000
Subject: [New-bugs-announce] [issue17835] test_io broken on PPC64 Linux
Message-ID: <1366830173.09.0.170493348126.issue17835@psf.upfronthosting.co.za>


New submission from David Edelsohn:

Unoptimized debug build (configured using --with-pydebug).
gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes -m64

test_interrupted_write_retry_buffered (test.test_io.CSignalsTest) ... ERROR
test_interrupted_write_retry_text (test.test_io.CSignalsTest) ... ERROR
test_interrupted_write_retry_buffered (test.test_io.PySignalsTest) ... ERROR
test_interrupted_write_retry_text (test.test_io.PySignalsTest) ... ERROR

======================================================================
ERROR: test_interrupted_write_retry_buffered (test.test_io.CSignalsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3219, in test_interrupted_write_retry_buffered
    self.check_interrupted_write_retry(b"x", mode="wb")
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3203, in check_interrupted_write_retry
    t.join()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 738, in join
    raise RuntimeError("cannot join thread before it is started")
RuntimeError: cannot join thread before it is started

======================================================================
ERROR: test_interrupted_write_retry_text (test.test_io.CSignalsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3222, in test_interrupted_write_retry_text
    self.check_interrupted_write_retry("x", mode="w", encoding="latin1")
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3203, in check_interrupted_write_retry
    t.join()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 738, in join
    raise RuntimeError("cannot join thread before it is started")
RuntimeError: cannot join thread before it is started

======================================================================
ERROR: test_interrupted_write_retry_buffered (test.test_io.PySignalsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3219, in test_interrupted_write_retry_buffered
    self.check_interrupted_write_retry(b"x", mode="wb")
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3203, in check_interrupted_write_retry
    t.join()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 738, in join
    raise RuntimeError("cannot join thread before it is started")
RuntimeError: cannot join thread before it is started

======================================================================
ERROR: test_interrupted_write_retry_text (test.test_io.PySignalsTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3222, in test_interrupted_write_retry_text
    self.check_interrupted_write_retry("x", mode="w", encoding="latin1")
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_io.py", line 3203, in check_interrupted_write_retry
    t.join()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/threading.py", line 738, in join
    raise RuntimeError("cannot join thread before it is started")
RuntimeError: cannot join thread before it is started

----------
components: Tests
messages: 187725
nosy: David.Edelsohn
priority: normal
severity: normal
status: open
title: test_io broken on PPC64 Linux
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 25 01:32:01 2013
From: report at bugs.python.org (Andres Riancho)
Date: Wed, 24 Apr 2013 23:32:01 +0000
Subject: [New-bugs-announce] [issue17836] multiprocessing exceptions with
	useful traceback
Message-ID: <1366846321.84.0.456984505709.issue17836@psf.upfronthosting.co.za>


New submission from Andres Riancho:

In pool.py, the worker function reads as follows:

http://svn.python.org/view/python/trunk/Lib/multiprocessing/pool.py?view=markup
"""
68	        job, i, func, args, kwds = task
69	        try:
70	            result = (True, func(*args, **kwds))
71	        except Exception, e:
72	            result = (False, e)
...
488	        if self._success:
489	            return self._value
490	        else:
491	            raise self._value
"""

If an exception is raised in the function you sent to the pool, the exception you get has "raise self._value" as the last line; which is correct but useless for debugging.

mp_exception_bug.py reproduces this error. This is the output:

"""
Traceback (most recent call last):
  File "mp_exception_bug.py", line 8, in <module>
    print p.map(f, [1,2,3])
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 227, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 528, in get
    raise self._value
NameError: global name 'y' is not defined
"""

As you can imagine, "NameError: global name 'y' is not defined" is not enough in complex projects.

If we apply some changes to the pool.py we could get something similar to this:

"""
Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 98, in worker
    result = (True, func(*args, **kwds))
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 67, in mapstar
    return map(*args)
  File "mp_exception_bug.py", line 4, in f
    return x*y
NameError: global name 'y' is not defined

Traceback (most recent call last):
  File "mp_exception_bug.py", line 8, in <module>
    print p.map(f, [1,2,3])
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 231, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/usr/lib/python2.7/multiprocessing/pool.py", line 535, in get
    raise self._value[0]
NameError: global name 'y' is not defined
"""

The patch is simple but ugly:

"""
> import sys
> import traceback
72c100,102
<             result = (False, e)
---
>             exc_info = sys.exc_info()
>             tb_string = traceback.format_exc(exc_info[2])
>             result = (False, (e, tb_string))
491c532,535
<             raise self._value
---
>             # Do something with the exception here, the simplest (but ugliest)
>             # thing to do is to simply print it to the console
>             print self._value[1]
>             raise self._value[0]
"""

Note that I tried to replace the "raise self._value[0]" with a raise with three parameters, being the last one the traceback we get using "exc_info = sys.exc_info()" but sadly it is not possible to pickle tracebacks.

I understand that printing is not the best thing to do here, but I wanted to get this discussion started and come to a real solution.

Thanks

----------
components: Library (Lib)
files: mp_exception_bug.py
messages: 187751
nosy: Andres.Riancho
priority: normal
severity: normal
status: open
title: multiprocessing exceptions with useful traceback
versions: Python 3.5
Added file: http://bugs.python.org/file30009/mp_exception_bug.py

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

From report at bugs.python.org  Thu Apr 25 08:53:24 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 25 Apr 2013 06:53:24 +0000
Subject: [New-bugs-announce] [issue17837] Support for building on ppc64p7
Message-ID: <1366872804.53.0.68863925041.issue17837@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

Hi, would it be possible to add ppc64p7 (Power7 optimized) to supported arches in config.sub? It should be as easy as the attached one-liner patch.
Thanks.

----------
components: Build
files: python-add-support-for-ppc64p7.patch
keywords: patch
messages: 187758
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Support for building on ppc64p7
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30011/python-add-support-for-ppc64p7.patch

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

From report at bugs.python.org  Thu Apr 25 08:56:24 2013
From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=)
Date: Thu, 25 Apr 2013 06:56:24 +0000
Subject: [New-bugs-announce] [issue17838] Can't assign a different value for
	sys.stdin in IDLE
Message-ID: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za>


New submission from Guilherme Sim?es:

Something like:

sys.stdin = open('file')

works in Python but doesn't in the IDLE shell. After trying to do that, a dialog is open asking if the user wants to kill the program. This happens because the method "close" of the class "PseudoInputFile" (which was created in #17585) is called.

----------
components: IDLE
messages: 187759
nosy: Guilherme.Sim?es
priority: normal
severity: normal
status: open
title: Can't assign a different value for sys.stdin in IDLE
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 25 09:32:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 25 Apr 2013 07:32:34 +0000
Subject: [New-bugs-announce] [issue17839] base64 module should use memoryview
Message-ID: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The base64 module is currently restricted specifically to bytes and bytearray objects. By using memoryview, it could effectively decode any input type that provides an 8-bit C contiguous view of the underlying data.

----------
components: Library (Lib)
messages: 187760
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: base64 module should use memoryview
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 25 09:40:50 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 25 Apr 2013 07:40:50 +0000
Subject: [New-bugs-announce] [issue17840] base64_codec uses assert for
	runtime validity checks
Message-ID: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

encodings.base64_codec currently uses "assert errors=='strict'" in a few places, since it doesn't actually support any of the Unicode specific error handling modes.

This should either be discarded entirely (and document that the error handling mode is irrelevant for this codec), or else turned into a real check that raises ValueError if an unsupported error mode is passed in.

I have a slight preference for just ignoring the error mode as irrelevant (since this isn't a text encoding in the normal Unicode serialisation-as-bytes sense).

----------
components: Library (Lib)
messages: 187762
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: base64_codec uses assert for runtime validity checks
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 25 10:30:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 25 Apr 2013 08:30:29 +0000
Subject: [New-bugs-announce] [issue17841] Remove missing aliases from codecs
	documentation
Message-ID: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The aliases for the bytes-bytes and str-str codecs are not present in 3.3, so the aliases should be removed from the corresponding standard encoding tables in the documentation.

http://docs.python.org/3/library/codecs#standard-encodings

----------
messages: 187769
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Remove missing aliases from codecs documentation
versions: Python 3.3

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

From report at bugs.python.org  Thu Apr 25 12:50:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Apr 2013 10:50:14 +0000
Subject: [New-bugs-announce] [issue17842] Add base64 module tests for a
	bytearray argument
Message-ID: <1366887014.03.0.146233163462.issue17842@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Most base64 functions accepts str, bytes or bytearray. Lib/tests/test_base64.py tests only bytes (and sometimes str) arguments. At least one test case with bytearray argument needed for every function.

----------
components: Tests
keywords: easy
messages: 187771
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add base64 module tests for a bytearray argument
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Apr 25 13:06:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 25 Apr 2013 11:06:08 +0000
Subject: [New-bugs-announce] [issue17843] Lib/test/testbz2_bigmem.bz2
	trigger virus warnings
Message-ID: <1366887968.16.0.8223632695.issue17843@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In ebb8c7d79f52 the file Lib/test/testbz2_bigmem.bz2 was added as test case for bug #14398.

The PSRT and webmaster teams have received half a dozen mails which complains about potential harmful content in the Python installers and Python source distribution. Apparently the file triggers a warning in several anti virus programs because it looks like a zip bomb.

I suggest that we remove the file from hg and create it on the fly during tests runs.

----------
messages: 187773
nosy: benjamin.peterson, christian.heimes, georg.brandl, larry, michael.foord, nadeem.vawda
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Lib/test/testbz2_bigmem.bz2 trigger virus warnings
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Apr 25 13:37:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 25 Apr 2013 11:37:22 +0000
Subject: [New-bugs-announce] [issue17844] Add link to alternatives for
	bytes-to-bytes codecs
Message-ID: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds link to alternative interfaces for bytes-to-bytes codecs. I.e. base64.b64encode and base64.b64decode for base64_codec.

Patch for 2.7 should mention other functions/modules (due to lack of some of them).

----------
assignee: docs at python
components: Documentation
files: doc_codecs_impl.patch
keywords: patch
messages: 187777
nosy: docs at python, doerwalter, lemburg, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add link to alternatives for bytes-to-bytes codecs
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30013/doc_codecs_impl.patch

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

From report at bugs.python.org  Thu Apr 25 19:44:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 25 Apr 2013 17:44:34 +0000
Subject: [New-bugs-announce] [issue17845] Clarify successful build message
Message-ID: <1366911874.8.0.692153365711.issue17845@psf.upfronthosting.co.za>


New submission from Brett Cannon:

From:

  Python build finished, but the necessary bits to build these modules were not found:
  ossaudiodev           spwd                                    
  To find the necessary bits, look in setup.py in detect_modules() for the module's name.

To:

  Python build successfully finished, but the necessary bits to build these optional modules were not found:

Notice the addition of "successfully" and "optional". Hopefully this will cause fewer new contributors to get thrown by this message.

----------
components: Build
messages: 187794
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Clarify successful build message
versions: Python 3.4

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

From report at bugs.python.org  Thu Apr 25 21:54:24 2013
From: report at bugs.python.org (michael kearney)
Date: Thu, 25 Apr 2013 19:54:24 +0000
Subject: [New-bugs-announce] [issue17846] Building Python on Windows -
	Supplementary info
Message-ID: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za>


New submission from michael kearney:

This is not a bug per se, though perhaps documentation rewrite might be appropriate.

I've been building python for windows for several years now. I have found that it is unnecessarily problematic. Perhaps my expectations are too high. When I started building python, I expected to build a whole stable version of python thing without error. In my experience, 
it is not true that one can build python on windows by simply loading the .sln file into Visual studio, selecting Debug or Release, and then clicking build.

Over time I have worked out steps that allow me to build all bits of python and minimize the aggravation and failures. These steps follow. Hopefully they will help folks to avoid some of the problems I encountered. Perhaps this will attract commentary that will document the way things actually should be done. I would be happy to stand corrected and know that there is a simple single point and click or single line command that would build python on windows.

Regardless, here you go. 

The online directions for downloading the development version source are fine and can be found at http://docs.python.org/devguide/. Mercurial must be installed on your machine. Stable released version source is available on the download page. 

Python building/rebuilding assumes the existence of subversion, perl, and a version of Visual Studio on your system. If you have all three, skip to step three. Otherwise download and install any of those
that are missing. If it is  necessary to have on hand multiple versions of python built from scratch, you should isolate them from each other by putting them in a container directory perhaps of the same name.

e.g. I use a style like python331/python331, python32/python32

where the subdirectory is the source root directory. I use the upper directory to isolate the external subprojects created by the buildbots described later. If you don't do this, the buildbots of one version can wipe out required subprojects of another version of python. I can assure you this will cause you a lot of confusion until you realize the source of the problem.

0. Download and install at least a subversion client and add the executable to your path.
   I got mine from Collabnet and here is how it appears in my path
   "C:\Program Files\CollabNet\Subversion Client"

1. Download and install  perl and add the executable to your path  
   I vaguely recall I downloaded ActivePerl
   Your Perl path will look something like this.
       C:\Perl\site\bin;C:\Perl\bin

2. Download and install VC++ express and add the bin area to your path
   Your VC++ bin path will look something like this:
   C:\Program Files\Microsoft Visual Studio 10.0\VC\bin

   I use the free version of VC++, which may be the source of all my 
   python build issues.
   When I load the solution file which you will see later, VC++    
   complains that the version
   I have doesn't support various features. It is free though and I am 
   able to work with it. 

2  Download and install nasm:
   There are several downloading sites. This seems to be the latest and    
   greatest. 
   http://www.windows7download.com/win7-nasm/ldyuniel.html

4. Download and build the external subprojects with the buildbots using 
   either: 
    Tools\buildbot\external.bat         # for 32 bit processors
    Tools\buildbot\external-amd64.bat   # for 64 bit processors
    from the root directory or your python distribution.
    This step will download the correct versions of the external 
    projects for this version of python. There are several projects

4. openssl is used for python on windows
   ssl rarely succeeds if you proceed to build using "pcbuild.sln: 

   The following steps will resolve many problems if you executing them 
   before building with the .sln file

   cd into the openssl directory created by the buildbots
     perl util\mkdef.pl crypto ssl update
     perl Configure VC-WIN32 --prefix=C:\opt\openssl-1.0.1d
     ms\do_nasm  

   You may get compilation errors anyway when you attempt to build the 
   .sln file with Visual Studio. The errors I have seen have always been 
   the same type, namely a forced error contained within a block of   
   conditional code. In all cases so far I have been able to comment out 
   the forced error. Most recently I had to comment out code blocks in 
   mdc2.h and idea.h.
   
   Historically, the openssl build has not had a "clean" function. This 
   used to cause me a lot of problems if rebuilding was required for  
   whatever reason. I cleaned the project by deleting and letting the 
   buildbot download again what was required. 

5. Finally Build python and its internal subprojects  
     open the solution "pcbuild.sln" in Visual Studio (VC++ in my case)
       - If you have an express version, then ignore the warning 
     select the  configuration  Release or Debug
        "Release" builds python.exe
        "Debug" builds python_d.exe 
     select the platform   Win32 or x64
     build the solution.   
       Right click "Solution 'pccuild'"  and select
         build - for fresh build
         clean - to delete all files created for build , i.e. objects, 
                 libraries, executable, etc.
         rebuild - clean and build everything
     Note that you can clean and build individual subprojects by just 
     right clicking on the subproject and selecting build, clean, or 
     rebuild for that project

----------
messages: 187810
nosy: michael.kearney
priority: normal
severity: normal
status: open
title: Building Python on Windows - Supplementary info
versions: Python 3.4

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

From report at bugs.python.org  Fri Apr 26 00:49:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Apr 2013 22:49:39 +0000
Subject: [New-bugs-announce] [issue17847] Glossary lacks permalinks
Message-ID: <1366930179.97.0.982792120174.issue17847@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you look at http://docs.python.org/dev/glossary.html, the glossary entries don't have a permalink next to them (even though the "Glossary" heading has one).

----------
assignee: georg.brandl
components: Documentation
messages: 187821
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Glossary lacks permalinks
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Apr 26 09:32:26 2013
From: report at bugs.python.org (leon zheng)
Date: Fri, 26 Apr 2013 07:32:26 +0000
Subject: [New-bugs-announce] [issue17848] issue about compile with clang and
	build a shared lib
Message-ID: <1366961546.37.0.678140272964.issue17848@psf.upfronthosting.co.za>


New submission from leon zheng:

build with prefix point to a arbitrary path, can't find the dynamic lib,
and libffi upstream bug:
./configure --prefix=xxx --enable-shared --enable-ipv6 --with-threads CC=clang

----------
components: Build
files: mywork.pitch
messages: 187838
nosy: matrixsystem
priority: normal
severity: normal
status: open
title: issue about compile with clang and build a shared lib
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file30023/mywork.pitch

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

From report at bugs.python.org  Fri Apr 26 14:27:04 2013
From: report at bugs.python.org (Miroslav Stampar)
Date: Fri, 26 Apr 2013 12:27:04 +0000
Subject: [New-bugs-announce] [issue17849] Missing size argument in
	readline() method for httplib's	class LineAndFileWrapper
Message-ID: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za>


New submission from Miroslav Stampar:

httplib module's auxiliary class LineAndFileWrapper contains a readline() method having no arguments (than self). It's being used in code where commented with "assume it's a Simple-Response from an 0.9 server" as a wrapper for response stream ("self.fp = LineAndFileWrapper(line, self.fp)").

In some cases readline() method requires a size argument (e.g. used with size argument inside HTTPMessage/readheaders(), HTTPResponse/begin(), HTTPResponse/_read_chunked, HTTPConnection/_tunnel, at least in "Python 2.7.1+ (r271:86832, Sep 27 2012, 21:12:17)").

This bug is hard to be reproduced as it requires a little help of "divine intervention".

One such exception looks like (reproduced on one user machine):
...
conn = urllib2.urlopen(req)
File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.7/urllib2.py", line 401, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 419, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 379, in _call_chain
result = func(*args)
File "/usr/share/sqlmap/lib/request/httpshandler.py", line 64, in https_open
return self.do_open(HTTPSConnection if ssl else httplib.HTTPSConnection, req)
File "/usr/lib/python2.7/urllib2.py", line 1178, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File "/usr/lib/python2.7/httplib.py", line 962, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python2.7/httplib.py", line 996, in _send_request
self.endheaders(body)
File "/usr/lib/python2.7/httplib.py", line 958, in endheaders
self._send_output(message_body)
File "/usr/lib/python2.7/httplib.py", line 818, in _send_output
self.send(msg)
File "/usr/lib/python2.7/httplib.py", line 780, in send
self.connect()
File "/usr/share/sqlmap/lib/request/httpshandler.py", line 46, in connect
sock = create_sock()
File "/usr/share/sqlmap/lib/request/httpshandler.py", line 39, in create_sock
self._tunnel()
File "/usr/lib/python2.7/httplib.py", line 748, in _tunnel
line = response.fp.readline(_MAXLINE + 1)
TypeError: readline() takes exactly 1 argument (2 given)

----------
components: Library (Lib)
messages: 187841
nosy: stamparm
priority: normal
severity: normal
status: open
title: Missing size argument in readline() method for httplib's class LineAndFileWrapper
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/issue17849>
_______________________________________

From report at bugs.python.org  Fri Apr 26 15:44:53 2013
From: report at bugs.python.org (Edward K. Ream)
Date: Fri, 26 Apr 2013 13:44:53 +0000
Subject: [New-bugs-announce] [issue17850] unicode_escape encoding fails for
	'\\Upsilon'
Message-ID: <1366983893.46.0.655183073262.issue17850@psf.upfronthosting.co.za>


New submission from Edward K. Ream:

On both windows and Linux the following fails on Python 2.7:

   s = '\\Upsilon'
   unicode(s,"unicode_escape")

UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-7: end of string in escape sequence

BTW, the six.py package uses this call.  If this call doesn't work, six is broken.

----------
components: Library (Lib)
messages: 187852
nosy: Edward.K..Ream
priority: normal
severity: normal
status: open
title: unicode_escape encoding fails for '\\Upsilon'
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sat Apr 27 06:55:56 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 04:55:56 +0000
Subject: [New-bugs-announce] [issue17851] Grammar errors in threading.Lock
	documentation
Message-ID: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

No need for comma in "which one of the waiting threads proceeds is not defined, and may vary across implementations."

"Once a thread has acquired a lock, subsequent attempts to acquire it block, until it is released; any thread may release it" should read "are blocked" instead of "block."


/Documents/python/cpython/Doc/build/html/library/threading.html

----------
messages: 187887
nosy: amysyk
priority: normal
severity: normal
status: open
title: Grammar errors in threading.Lock documentation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 27 09:33:30 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 27 Apr 2013 07:33:30 +0000
Subject: [New-bugs-announce] [issue17852] Built-in module _io can loose data
	from buffered files	at exit
Message-ID: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>


New submission from Armin Rigo:

In Python 2, a buffered file opened for writing is flushed by the C library when the process exit.  In Python 3, the _pyio and _io modules don't do it reliably.  They rely on __del__ being called, which is not neccesarily the case.  The attached example ends with the file 'foo' empty (tested with Python 3.3 and the current trunk).  The same example in Python 2 using the built-in open() cannot end with 'foo' empty.

----------
components: IO
files: y.py
messages: 187890
nosy: arigo
priority: normal
severity: normal
status: open
title: Built-in module _io can loose data from buffered files at exit
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30030/y.py

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

From report at bugs.python.org  Sat Apr 27 10:10:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 27 Apr 2013 08:10:01 +0000
Subject: [New-bugs-announce] [issue17853] class construction name resolution
	broken in functions
Message-ID: <1367050201.95.0.307419620832.issue17853@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In playing with metaclasses for the ongoing Enum saga, I tried having the metaclass insert an object into the custom dict (aka namespace) returned by __prepare__; this object has the same name as the to-be-created class.

An example:

class Season(Enum):
    SPRING = Season()
    SUMMER = Season()
    AUTUMN = Season()
    WINTER = Season()

When this executes as top level code it works beautifully.

However, if you have the exact same definition in a function, Bad Things happen:

---------------------------------------
--> def test():
...   class Season(Enum):
...     SPRING = Season()
... 
--> test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in test
  File "<stdin>", line 3, in Season
NameError: free variable 'Season' referenced before assignment in enclosing scope
---------------------------------------

So I tried creating a dummy variable to see if it would be worked around:

---------------------------------------
--> def test():
...   Season = None
...   class Season(Enum):
...     SPRING = Season()
... 
--> test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in test
  File "<stdin>", line 4, in Season
TypeError: 'NoneType' object is not callable
---------------------------------------

Finally I inserted the object using a different name, and also printed 'locals()' just to see what was going on:

---------------------------------------
--> def test():
...   class Season(Enum):
...     print(locals())
...     SPRING = S()
... 
--> test()
{'S': <class 'aenum.Season'>, 'Season': <class 'aenum.Season'>, '__module__': '__main__', '__qualname__': 'test.<locals>.Season', '__locals__': {...}}
---------------------------------------

and an actual (albeit extremely ugly) work around:

---------------------------------------
>>> def test():
...   class Season(Enum):
...     Season = locals()['Season']
...     SPRING = Season()
...   print(Season)
... 
>>> test()
Season(SPRING=1)
---------------------------------------

It seems that the function namespace is seriously messing with the class namespace.

----------
components: Interpreter Core
messages: 187892
nosy: stoneleaf
priority: normal
severity: normal
status: open
title: class construction name resolution broken in functions
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Apr 27 13:47:20 2013
From: report at bugs.python.org (Amit Saha)
Date: Sat, 27 Apr 2013 11:47:20 +0000
Subject: [New-bugs-announce] [issue17854] symmetric difference operation
	applicable to more than	two sets
Message-ID: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za>


New submission from Amit Saha:

The description of the symmetric difference operation implies that it cannot be applied to more than two sets (http://docs.python.org/3/library/stdtypes.html#set.symmetric_difference).

However, this is certainly possible:

>>> s={1,2}
>>> t={2,3}
>>> u={3,4}
>>> s^t^u
{1, 4}
>>> s.symmetric_difference(t).symmetric_difference(u)
{1, 4}

I am not sure how much of a "semantic" sense that makes, given that symmetric difference is by definition for two sets. (http://en.wikipedia.org/wiki/Symmetric_difference).

So, either the operator should be fixed to allow only two sets or the description be updated.

----------
assignee: docs at python
components: Documentation
messages: 187899
nosy: Amit.Saha, docs at python
priority: normal
severity: normal
status: open
title: symmetric difference operation applicable to more than two sets
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 27 14:48:58 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Apr 2013 12:48:58 +0000
Subject: [New-bugs-announce] [issue17855] Implement introspection of logger
	hierarchy
Message-ID: <1367066938.7.0.169657399656.issue17855@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

Track implementation of logger hierarchy introspection as per

http://plumberjack.blogspot.co.uk/2012/04/introspecting-logger-hierarchy.html

----------
assignee: vinay.sajip
components: Library (Lib)
messages: 187904
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: Implement introspection of logger hierarchy
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Apr 27 18:56:50 2013
From: report at bugs.python.org (ProgVal)
Date: Sat, 27 Apr 2013 16:56:50 +0000
Subject: [New-bugs-announce] [issue17856] multiprocessing.Process.join does
	not block if timeout	is lower than 1
Message-ID: <1367081810.71.0.573037357141.issue17856@psf.upfronthosting.co.za>


New submission from ProgVal:

In Python 3.3, multiprocessing.Process.join() is not blocking with floats lower than 1.0 (not included). It works as expected (ie. blocking for the specified timeout) in Python 2.6->3.2

As you can see in this example, calling join() with 0.99 returns immediately.

$ python3.3
Python 3.3.1 (default, Apr  6 2013, 13:58:40) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> import multiprocessing
>>> def foo():
...  time.sleep(1000)
... 
>>> p = multiprocessing.Process(target=foo)
>>> p.start()
>>> bar = time.time(); p.join(0.99); print(time.time()-bar)
0.015963315963745117
>>> p.is_alive()
True
>>> bar = time.time(); p.join(1.0); print(time.time()-bar)
1.0011239051818848
>>> p.is_alive()
True

----------
components: Library (Lib)
messages: 187916
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: multiprocessing.Process.join does not block if timeout is lower than 1
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Apr 27 20:46:05 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 27 Apr 2013 18:46:05 +0000
Subject: [New-bugs-announce] [issue17857] sqlite modules doesn't build on
	2.7.4 with Mac OS X 10.4
Message-ID: <1367088365.18.0.161187485212.issue17857@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

This is essentially the same issue as http://bugs.python.org/issue14572.

The following addition in Python 2.7.4 (compared to 2.7.3) reintroduced the same problem in a different place:

--- Python-2.7.3/Modules/_sqlite/util.h 2012-04-10 01:07:33.000000000 +0200
+++ Python-2.7.4/Modules/_sqlite//util.h        2013-04-06 16:02:36.000000000 +0200
@@ -33,6 +33,10 @@ int pysqlite_step(sqlite3_stmt* statemen
 /**
  * Checks the SQLite error code and sets the appropriate DB-API exception.
  * Returns the error code (0 means no error occurred).
  */
 int _pysqlite_seterror(sqlite3* db, sqlite3_stmt* st);
+
+PyObject * _pysqlite_long_from_int64(sqlite3_int64 value);
+sqlite3_int64 _pysqlite_long_as_int64(PyObject * value);
+
 #endif

The fix is the same as for the 2.7.3 issue: replace sqlite3_int64 with sqlite_int64

----------
components: Extension Modules, Library (Lib)
messages: 187921
nosy: lemburg
priority: normal
severity: normal
status: open
title: sqlite modules doesn't build on 2.7.4 with Mac OS X 10.4
versions: Python 2.7

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

From report at bugs.python.org  Sun Apr 28 00:58:05 2013
From: report at bugs.python.org (Andriy Mysyk)
Date: Sat, 27 Apr 2013 22:58:05 +0000
Subject: [New-bugs-announce] [issue17858] Different documentation for
	identical methods
Message-ID: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za>


New submission from Andriy Mysyk:

Use _thread.Lock.acquire() documentation for threading.Lock.acquire().

threading.Lock inherits acquire() method from _thread.Lock.  The two acquire() methods are identical in their functionality yet have different documentation. Documentation for threading.Lock.acquire() creates the impression that the function is more complex or harder to use than it actually is. See http://docs.python.org/devguide/documenting.html#economy-of-expression for guidelines.

----------
assignee: docs at python
components: Documentation
messages: 187945
nosy: amysyk, docs at python
priority: normal
severity: normal
status: open
title: Different documentation for identical methods
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 28 09:37:56 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 28 Apr 2013 07:37:56 +0000
Subject: [New-bugs-announce] [issue17859] improve error message for saving
	ints to file
Message-ID: <1367134676.21.0.161863892006.issue17859@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I needed to write some bytes to file and got this message.

>>> hex = open('hex', 'wb')
>>> for x in range(0, 0xff, 0x11):
...   hex.write(x)
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: 'int' does not support the buffer interface

The cause of the error is not that 'int' doesn't support some interface (which is strange already, because the function analyzes and writes int, not the int writes itself), but because it is impossible to know how many binary bytes the int type should take when written.

In Python 2 the solution is:
  ...
  hex.write(chr(x))

But in Python 3 this is again:
  TypeError: 'str' does not support the buffer interface

In Python 3 the solution is:
  ...
  hex.write(x.to_bytes(1, 'little'))

----------
messages: 187968
nosy: techtonik
priority: normal
severity: normal
status: open
title: improve error message for saving ints to file
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 28 16:36:39 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 28 Apr 2013 14:36:39 +0000
Subject: [New-bugs-announce] [issue17860] subprocess docs lack info how to
	use output result
Message-ID: <1367159799.26.0.456231833917.issue17860@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/3/library/subprocess.html

A common confusion is that result from subprocess calls in Python 3 is bytes, not string, and needs to be converted.

The problem is complicated because you need to know the encoding of input/output streams. This should be documented at least.

http://stackoverflow.com/questions/606191/convert-byte-array-to-python-string

----------
assignee: docs at python
components: Documentation
messages: 187982
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: subprocess docs lack info how to use output result
versions: Python 3.3

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

From report at bugs.python.org  Sun Apr 28 17:14:49 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Apr 2013 15:14:49 +0000
Subject: [New-bugs-announce] [issue17861] put opcode information in one place
Message-ID: <1367162089.6.0.986391601417.issue17861@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Right now, opcode information is duplicated in Include/opcode.h and Lib/opcode.py. I should only have to update one manually and have the other one generated automatically. opcode.h should probably be generated by a script from opcode.py.

----------
components: Interpreter Core
keywords: easy
messages: 187986
nosy: benjamin.peterson
priority: normal
severity: normal
stage: needs patch
status: open
title: put opcode information in one place
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Apr 28 18:13:10 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 28 Apr 2013 16:13:10 +0000
Subject: [New-bugs-announce] [issue17862] itertools.chunks(iterable, size,
	fill=None)
Message-ID: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

The history:
2007 - http://bugs.python.org/issue1502
2009 - http://bugs.python.org/issue6021

I'd like to resurrect this proposal again, but name it:
  itertools.chunks(iterable, size, fill=None)

Two reasons.
1. practicality  - top itertools request on StackOverflow
http://stackoverflow.com/search?tab=votes&q=%5bpython%5d%20%2bitertools

2. performance
the time should be a constant for a fixed-length iterable regardless of a size of chunk, but in fact the time is proportional to the size of chunk

{{{
import timeit

print timeit.timeit(
  'grouper(30000, "x"*400000)', setup='from __main__ import grouper', number=1000
)
print timeit.timeit(
  'grouper(300000, "x"*400000)', setup='from __main__ import grouper', number=1000
)
}}}

1.52581005407
14.6219704599


Addressing odd length user stories from msg87745:
1. no exceptions - odd end is an easy check if you need it
2. fill-in value - provided
3. truncation - just don't set fill-in value
3.1. if you really need fill-in as None, then an itertools.TRUNCATE value can be used as a truncation parameter
4. partially filled-in tuple - not sure what that means

Raymond, your opinion is critical here. =)

----------
components: Library (Lib)
messages: 187995
nosy: rhettinger, techtonik
priority: normal
severity: normal
status: open
title: itertools.chunks(iterable, size, fill=None)
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Apr 28 19:12:52 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Apr 2013 17:12:52 +0000
Subject: [New-bugs-announce] [issue17863] Bad sys.stdin assignment hands
	interpreter.
Message-ID: <1367169172.83.0.786523829005.issue17863@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This appears to be Python 3 specific. On 2.7.4 (Win7):
>>> import sys
>>> sys.stdin='abd'
>>>

With fresh 3.4 repository debug build, prompt never appears, ^C, ^D are ignored. Must close with window's [X] button. With fresh 3.3, get repeated [62312 refs] lines. One could guess that they are generated but suppressed in 3.4.

There is a possibility that this is specific to debug builds; I cannot currently build or run one for 2.7. However, there is no problem with Idle running (on Windows) with 3.3/3.4 pythonw-d. (In other words, see same behavior as 2.7 above.)

----------
messages: 188006
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Bad sys.stdin assignment hands interpreter.
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Apr 28 20:22:17 2013
From: report at bugs.python.org (Ben Read)
Date: Sun, 28 Apr 2013 18:22:17 +0000
Subject: [New-bugs-announce] [issue17864] IDLE won't run
Message-ID: <1367173337.57.0.3678200637.issue17864@psf.upfronthosting.co.za>


New submission from Ben Read:

I am installing Python 3.31 on a Mac running OS 10.8.2 and have already installed ActiveTCL 8.5.13. When I try and launch IDLE, the icon appears on the dock for a second and then disappears and the application doesn't run. I have already installed both Python and Active TCL in the same way on two other Macs and it has run just fine, so I don't know why it's not running on this one. Is there anything specific that would cause this to happen?

Thanks,
Ben

----------
components: IDLE
messages: 188011
nosy: Bozdog
priority: normal
severity: normal
status: open
title: IDLE won't run
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 29 05:29:26 2013
From: report at bugs.python.org (Ellen Wang)
Date: Mon, 29 Apr 2013 03:29:26 +0000
Subject: [New-bugs-announce] [issue17865] PowerPC exponentiation and round()
	interaction
Message-ID: <1367206166.88.0.195054463405.issue17865@psf.upfronthosting.co.za>


New submission from Ellen Wang:

This is only on a PowerPC, specifically a p2020, running Debian 7.0 wheezy, python 2.7.3.

Calling round() seems to corrupt something (in the floating point state?) that causes subsequent exponentiation (the ** operator) to be wrong:

Python 2.7.3 (default, Jan  2 2013, 16:38:11)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2 ** -2
0.25
>>> round(1)
1.0
>>> 2 ** -2
0.1253019036571362

Cool.  Huh?

----------
components: Library (Lib)
files: math.py
messages: 188033
nosy: squeakbat
priority: normal
severity: normal
status: open
title: PowerPC exponentiation and round() interaction
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30054/math.py

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

From report at bugs.python.org  Mon Apr 29 10:01:29 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 29 Apr 2013 08:01:29 +0000
Subject: [New-bugs-announce] [issue17866] TestCase.assertItemsEqual exists
	in 2.7, not in 3.3
Message-ID: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

assertItemsEqual was added to unittest.TestCase in Python 2.7 (according to the documentation), but is not present in Python 3.3.

I'd expect it to be present in 3.3 as well, or for it to be mentioned in documentation as not being present (either in the 2.7 documentation or the Misc/NEWS file for py3k)

----------
components: Library (Lib)
messages: 188045
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: TestCase.assertItemsEqual exists in 2.7, not in 3.3
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Apr 29 12:15:23 2013
From: report at bugs.python.org (Dmi Baranov)
Date: Mon, 29 Apr 2013 10:15:23 +0000
Subject: [New-bugs-announce] [issue17867] Deleting __import__ from builtins
	can crash Python3
Message-ID: <1367230523.7.0.186873626934.issue17867@psf.upfronthosting.co.za>


New submission from Dmi Baranov:

Simple case - let's delete __import__ and try to import anything

$ python3.3
Python 3.3.0 (default, Oct  7 2012, 11:03:52) 
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> del __builtins__.__dict__['__import__']
>>> import os
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Fatal Python error: __import__ missing

Current thread 0x00007f07c9ebc700:
Aborted

But in python2.x

$ python2.7
Python 2.7.3 (default, Sep 22 2012, 02:37:18) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> del __builtins__.__dict__['__import__']
>>> import os
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: __import__ not found
>>>

----------
components: Interpreter Core
messages: 188059
nosy: Dmi.Baranov
priority: normal
severity: normal
status: open
title: Deleting __import__ from builtins can crash Python3
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Mon Apr 29 20:19:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Apr 2013 18:19:29 +0000
Subject: [New-bugs-announce] [issue17868] pprint long non-printable bytes as
	hexdump
Message-ID: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch with which pprint formats long bytes objects which contain non-ascii or non-printable bytes as a hexdump.

Inspired by Antoine's wish (http://permalink.gmane.org/gmane.comp.python.ideas/20329).

----------
components: Library (Lib)
files: pprint_bytes_hex.patch
keywords: patch
messages: 188081
nosy: fdrake, pitrou, serhiy.storchaka, techtonik
priority: normal
severity: normal
stage: patch review
status: open
title: pprint long non-printable bytes as hexdump
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file30067/pprint_bytes_hex.patch

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

From report at bugs.python.org  Mon Apr 29 22:10:21 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 29 Apr 2013 20:10:21 +0000
Subject: [New-bugs-announce] [issue17869] distutils - TypeError in
	command/build_ext.py
Message-ID: <1367266221.15.0.812330331634.issue17869@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

Traceback (most recent call last):
  File "setup.py", line 221, in <module>
    ...  and much more ;)"""
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/build.py", line 126, in run
    self.run_command(cmd_name)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/build_ext.py", line 349, in run
    self.build_extensions()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/build_ext.py", line 458, in build_extensions
    self.build_extension(ext)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/build_ext.py", line 474, in build_extension
    ext_path = self.get_ext_fullpath(ext.name)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/build_ext.py", line 633, in get_ext_fullpath
    filename = self.get_ext_filename(modpath[-1])
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/build_ext.py", line 672, in get_ext_filename
    return os.path.join(*ext_path) + ext_suffix
TypeError: Can't convert 'NoneType' object to str implicitly


I'm getting this while building PyOpenSSL on Linux with laterst cset of Python 3.4.
Everything's fine on Python 3.3.
Possibly related with issue #16754?

----------
assignee: eric.araujo
components: Distutils
messages: 188092
nosy: doko, eric.araujo, giampaolo.rodola, tarek
priority: normal
severity: normal
status: open
title: distutils - TypeError in command/build_ext.py
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 29 22:57:05 2013
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 29 Apr 2013 20:57:05 +0000
Subject: [New-bugs-announce] [issue17870] Hard to create python longs from
	arbitrary C integers
Message-ID: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

As far as I can tell, the only safe and correct way to convert a (for example) intptr_t to a python long is something akin to the following:

    size_t repsize = sizeof(intmax_t)*8 + 2;
    char i_buf[repsize]; // enough to fit base 2 with sign, let alone base 1
    snprintf(i_buf, repsize, "%ij", (intmax_t) myinteger);
    return PyLong_FromString(i_buf, NULL, 10);

Does this not seem absurd?

PyLong_FromIntMax_t(myinteger) would be great. Or maybe even better would be PyLong_FromBytes(&myinteger, sizeof(myinteger)) ?

This is problematic because many things that can interact with the Python C-API do not use the C types like "long long" or "int". Instead they might use the equivalents of intptr_t and int32_t, which are more reliably sized.

----------
messages: 188103
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: Hard to create python longs from arbitrary C integers
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 29 23:06:32 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 29 Apr 2013 21:06:32 +0000
Subject: [New-bugs-announce] [issue17871] Wrong signature of
	TextTestRunner's init function
Message-ID: <1367269592.44.0.115946830805.issue17871@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

TextTestRunner's init as of 3.3.1 has (http://hg.python.org/cpython/file/d9893d13c628/Lib/unittest/runner.py#l128) the following parameters:
stream, descriptions, verbosity, failfast, buffer, resultclass, warnings whereas docs (http://docs.python.org/3.3/library/unittest.html?highlight=unittest#loading-and-running-tests) show only the following parameters:
stream, descriptions, verbosity, runnerclass, warnings

'Failfast' and 'buffer' parameters are missing in the docs and there's 'runnerclass' parameter instead of 'resultclass' parameter.

----------
assignee: docs at python
components: Documentation
messages: 188104
nosy: docs at python, ezio.melotti, michael.foord, piotr.dobrogost
priority: normal
severity: normal
status: open
title: Wrong signature of TextTestRunner's init function
versions: Python 3.4

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

From report at bugs.python.org  Mon Apr 29 23:29:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 29 Apr 2013 21:29:12 +0000
Subject: [New-bugs-announce] [issue17872] Crash in marshal.load() with bad
	reader
Message-ID: <1367270952.48.0.351702678796.issue17872@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a buffer overflow in marshal.load() when len(read(n)) > n.

Here is a sample.

----------
components: Interpreter Core
files: marshal_bad_reader.py
messages: 188107
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Crash in marshal.load() with bad reader
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30070/marshal_bad_reader.py

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

From report at bugs.python.org  Tue Apr 30 01:05:23 2013
From: report at bugs.python.org (Andreas Schwab)
Date: Mon, 29 Apr 2013 23:05:23 +0000
Subject: [New-bugs-announce] [issue17873] _ctypes/libffi missing bits for
	aarch64 support
Message-ID: <1367276723.56.0.050997158172.issue17873@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

ctype modules doesn't build for aarch64 due to missing bits in the fficonfig.py script.

----------
components: ctypes
files: ctypes-libffi-aarch64.patch
keywords: patch
messages: 188116
nosy: schwab
priority: normal
severity: normal
status: open
title: _ctypes/libffi missing bits for aarch64 support
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file30073/ctypes-libffi-aarch64.patch

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

From report at bugs.python.org  Tue Apr 30 05:16:37 2013
From: report at bugs.python.org (Theodore Randolph)
Date: Tue, 30 Apr 2013 03:16:37 +0000
Subject: [New-bugs-announce] [issue17874] ProcessPoolExecutor in interactive
	shell doesn't work in	Windows
Message-ID: <1367291797.68.0.0512798150346.issue17874@psf.upfronthosting.co.za>


New submission from Theodore Randolph:

ProcessPoolExecutor doesn't work in an interactive shell in Windows, such as IDLE or the command prompt. It does work in Unix, and it works if I use the ThreadPoolExecutor instead.

For example, let's use the tutorial at http://eli.thegreenplace.net/2013/01/16/python-paralellizing-cpu-bound-tasks-with-concurrent-futures/

I get:
>>> pool_factorizer_chunked([1,2,3,456,7,8],8)
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python33\lib\threading.py", line 639, in _bootstrap_inner
    self.run()
  File "C:\Python33\lib\threading.py", line 596, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Python33\lib\concurrent\futures\process.py", line 248, in _queue_management_worker
    shutdown_worker()
  File "C:\Python33\lib\concurrent\futures\process.py", line 208, in shutdown_worker
    call_queue.put_nowait(None)
  File "C:\Python33\lib\multiprocessing\queues.py", line 132, in put_nowait
    return self.put(obj, False)
  File "C:\Python33\lib\multiprocessing\queues.py", line 79, in put
    raise Full
queue.Full

Traceback (most recent call last):
  File "<pyshell#10>", line 1, in <module>
    pool_factorizer_chunked([1,2,3,456,7,8],8)
  File "<pyshell#5>", line 14, in pool_factorizer_chunked
    resultdict.update(f.result())
  File "C:\Python33\lib\concurrent\futures\_base.py", line 392, in result
    return self.__get_result()
  File "C:\Python33\lib\concurrent\futures\_base.py", line 351, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
>>> pool_factorizer_map([1,2,3,456,7,8],8)
Exception in thread Thread-2:
Traceback (most recent call last):
  File "C:\Python33\lib\threading.py", line 639, in _bootstrap_inner
    self.run()
  File "C:\Python33\lib\threading.py", line 596, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Python33\lib\concurrent\futures\process.py", line 248, in _queue_management_worker
    shutdown_worker()
  File "C:\Python33\lib\concurrent\futures\process.py", line 208, in shutdown_worker
    call_queue.put_nowait(None)
  File "C:\Python33\lib\multiprocessing\queues.py", line 132, in put_nowait
    return self.put(obj, False)
  File "C:\Python33\lib\multiprocessing\queues.py", line 79, in put
    raise Full
queue.Full

Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    pool_factorizer_map([1,2,3,456,7,8],8)
  File "<pyshell#12>", line 6, in pool_factorizer_map
    executor.map(factorize_naive, nums))}
  File "<pyshell#12>", line 4, in <dictcomp>
    return {num:factors for num, factors in
  File "C:\Python33\lib\concurrent\futures\_base.py", line 546, in result_iterator
    yield future.result()
  File "C:\Python33\lib\concurrent\futures\_base.py", line 399, in result
    return self.__get_result()
  File "C:\Python33\lib\concurrent\futures\_base.py", line 351, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
>>>

----------
components: Windows
messages: 188122
nosy: Decade
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor in interactive shell doesn't work in Windows
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Apr 30 07:04:30 2013
From: report at bugs.python.org (Afif Elghraoui)
Date: Tue, 30 Apr 2013 05:04:30 +0000
Subject: [New-bugs-announce] [issue17875] Set Intersection returns
	unexpected results
Message-ID: <1367298270.65.0.0671753217297.issue17875@psf.upfronthosting.co.za>


New submission from Afif Elghraoui:

I have two lists of strings (gene identifiers) that I know have something in common. I convert them to lists and do an intersection and I get the empty set. As an example test case, I know they both have the string 'Rv0500'

>>> list1.index('Rv0500')
278
>>> list2.index('Rv0500')
245
>>> set(list1).intersection(set(list2))
set([])

I was expecting to get a few hundred matches. My two lists are attached to this report. This is how I created the data file:

>>> x = shelve.open('lists.dat')
>>> x['list1'] = list1
>>> x['list2'] = list2
>>> x.close()

I did my best to make this report complete-- thanks for all your help.

----------
components: Interpreter Core
files: lists.dat
messages: 188125
nosy: Afif.Elghraoui
priority: normal
severity: normal
status: open
title: Set Intersection returns unexpected results
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30075/lists.dat

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

From report at bugs.python.org  Tue Apr 30 08:06:25 2013
From: report at bugs.python.org (Xavier Ordoquy)
Date: Tue, 30 Apr 2013 06:06:25 +0000
Subject: [New-bugs-announce] [issue17876] Doc issue with threading.Event
Message-ID: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za>


New submission from Xavier Ordoquy:

The documentation isn't correct for the threading.Event class under python 3.2.

In the threading doc page (http://docs.python.org/3.2/library/threading.html), Event is said to be at the same time a function and a class.

This is misleading and lead to a regression for celery under python 3.2 (https://github.com/celery/celery/pull/1333).

Could the doc be updated under python 3.2 so that threading.Event leads to the function and threading._Event leads to the class ?

Regards,
Xavier.

----------
assignee: docs at python
components: Documentation
messages: 188127
nosy: docs at python, xordoquy
priority: normal
severity: normal
status: open
title: Doc issue with threading.Event
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 30 11:07:33 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 30 Apr 2013 09:07:33 +0000
Subject: [New-bugs-announce] [issue17877] Skip test_variable_tzname when the
	zoneinfo database is	missing
Message-ID: <1367312853.26.0.203809750785.issue17877@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

If the Olson/zoneinfo/tz database is missing, test_variable_tzname fails:

[1/1] test_email
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
  File "/usr/local/lib/python3.3/test/support.py", line 1311, in inner
    return func(*args, **kwds)
  File "/usr/local/lib/python3.3/test/test_email/test_utils.py", line 133, in test_variable_tzname
    self.assertEqual(t1.tzname(), 'MSK')
AssertionError: 'Europe' != 'MSK'
- Europe
+ MSK

The attached patch checks if /usr/share/zoneinfo or /usr/lib/zoneinfo exist, and skip the test if they don't.  This test is already skipped on Windows.

----------
components: Tests
files: olson.diff
keywords: patch
messages: 188145
nosy: belopolsky, ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Skip test_variable_tzname when the zoneinfo database is missing
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file30077/olson.diff

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

From report at bugs.python.org  Tue Apr 30 11:51:57 2013
From: report at bugs.python.org (Paul Moore)
Date: Tue, 30 Apr 2013 09:51:57 +0000
Subject: [New-bugs-announce] [issue17878] There is no way to get a list of
	available codecs
Message-ID: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za>


New submission from Paul Moore:

The codecs module allows the user to register additional codecs, but does not offer a means of getting a list of registered codecs.

This is important, for example, in a tool to re-encode files. It is reasonable to expect that such a tool would offer a list of supported encodings, to assist the user. For example, the -l option of the iconv command.

----------
components: Unicode
messages: 188147
nosy: ezio.melotti, pmoore
priority: normal
severity: normal
status: open
title: There is no way to get a list of available codecs
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Apr 30 12:52:41 2013
From: report at bugs.python.org (Steffen Flemming)
Date: Tue, 30 Apr 2013 10:52:41 +0000
Subject: [New-bugs-announce] [issue17879] corrupt download
Message-ID: <1367319161.21.0.277486874869.issue17879@psf.upfronthosting.co.za>


New submission from Steffen Flemming:

http://www.python.org/ftp/python/2.7.4/Python-2.7.4.tgz
http://www.python.org/ftp/python/2.7.4/Python-2.7.4.tar.bz2
at 30.04.2013 12:45
bzip2: Compressed file ends unexpectedly;

----------
components: Build
messages: 188151
nosy: u14183
priority: normal
severity: normal
status: open
title: corrupt download
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 30 12:54:00 2013
From: report at bugs.python.org (Steffen Flemming)
Date: Tue, 30 Apr 2013 10:54:00 +0000
Subject: [New-bugs-announce] [issue17880] `tmpnam_r' is dangerous,
	better use `mkstemp'
Message-ID: <1367319240.88.0.90171528174.issue17880@psf.upfronthosting.co.za>


New submission from Steffen Flemming:

/tmp/Python-2.7.3/./Modules/posixmodule.c:7432: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'

----------
components: Build
messages: 188152
nosy: u14183
priority: normal
severity: normal
status: open
title: `tmpnam_r' is dangerous, better use `mkstemp'
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Tue Apr 30 15:22:22 2013
From: report at bugs.python.org (Lance Helsten)
Date: Tue, 30 Apr 2013 13:22:22 +0000
Subject: [New-bugs-announce] [issue17881] plistlib.writePlist documentation
	clarification for file	object
Message-ID: <1367328142.85.0.378048877663.issue17881@psf.upfronthosting.co.za>


New submission from Lance Helsten:

plistlib.writePlist documentation states """Write 'rootObject' to a .plist file. 'pathOrFile' may either be a file name or a (writable) file object.""", but if a text IO object is given for the pathOrFile object (e.g. ``io.TextIOBase`` or ``sys.stdout``) a ``TypeError`` with message "must be str, not bytes" is raised.

To clarify the documentation should be changed to be """...or a (writable, binary) file object.""".

----------
messages: 188160
nosy: lanhel
priority: normal
severity: normal
status: open
title: plistlib.writePlist documentation clarification for file object
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 30 18:55:43 2013
From: report at bugs.python.org (bharper)
Date: Tue, 30 Apr 2013 16:55:43 +0000
Subject: [New-bugs-announce] [issue17882] test_objecttypes fails for 3.2.4
	on CentOS 6
Message-ID: <1367340943.59.0.839415774822.issue17882@psf.upfronthosting.co.za>


New submission from bharper:

Hello,

I have been running into some issues with test_objecttypes with 3.2.4 on CentOS 6:

======================================================================         
FAIL: test_objecttypes (test.test_sys.SizeofTest)                              
----------------------------------------------------------------------         
Traceback (most recent call last):                                             
  File "/builddir/build/BUILD/Python-3.2.4/Lib/test/test_sys.py", line 789, in test_objecttypes
    check(int, s)                                                              
  File "/builddir/build/BUILD/Python-3.2.4/Lib/test/support.py", line 1155, in check_sizeof
    test.assertEqual(result, size, msg)                                        
AssertionError: 856 != 816 : wrong size for <class 'type'>: got 856, expected 816
----------------------------------------------------------------------

Looking over the bugs, I do not see anyone else having issues with this test.  It does appear that this test got updated in issue 15467.  

Any insight would be greatly appreciate.

-Ben

----------
components: Build
messages: 188169
nosy: bharper
priority: normal
severity: normal
status: open
title: test_objecttypes fails for 3.2.4 on CentOS 6
versions: Python 3.2

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

From report at bugs.python.org  Tue Apr 30 23:05:15 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 30 Apr 2013 21:05:15 +0000
Subject: [New-bugs-announce] [issue17883] Fix buildbot testing of Tkinter
Message-ID: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Ezio, you brought up the fact that the 2.7 Windows buildbots were skipping the Tkinter tests in Terry's core-mentorship thread about tkinter on Windows last month, and I've finally learned what is causing that failure.  It appears that when 689a813f4afc and df39b0bc4106 were committed, they were not backported to 2.7.  Attached is a patch to backport those two changesets, which should make things (more) right.  

This only affects running tests via PCbuild/rt.bat (or Tools/buildbot/test.bat, which calls PCbuild/rt.bat), and doesn't do anything for finding the tcl/tk .dlls any other time.

----------
components: Tests, Tkinter, Windows
files: 2.7_rt.bat_tcltk_fix.diff
keywords: patch
messages: 188184
nosy: ezio.melotti, terry.reedy, zach.ware
priority: normal
severity: normal
status: open
title: Fix buildbot testing of Tkinter
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file30080/2.7_rt.bat_tcltk_fix.diff

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