From report at bugs.python.org  Sun Jun  1 05:28:22 2014
From: report at bugs.python.org (Jeremy Huntwork)
Date: Sun, 01 Jun 2014 03:28:22 +0000
Subject: [New-bugs-announce] [issue21622] ctypes.util incorrectly fails for
	libraries without	DT_SONAME
Message-ID: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za>


New submission from Jeremy Huntwork:

On my system, the C library (musl) intentionally does not include a SONAME entry.

This method in particular fails: http://hg.python.org/cpython/file/076705776bbe/Lib/ctypes/util.py#l133

The function seems to jump through some hoops which may not be necessary. Is there a reason for wanting particularly to use the SONAME entry for the lib?

In my system the following works as a replacement for _get_soname:

return os.path.basename(os.path.realpath(f))

----------
components: ctypes
messages: 219481
nosy: Jeremy.Huntwork
priority: normal
severity: normal
status: open
title: ctypes.util incorrectly fails for libraries without DT_SONAME
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  1 06:03:45 2014
From: report at bugs.python.org (Mo Jia)
Date: Sun, 01 Jun 2014 04:03:45 +0000
Subject: [New-bugs-announce] [issue21623] build ssl failed use vs2010 express
Message-ID: <1401595425.37.0.323501689421.issue21623@psf.upfronthosting.co.za>


New submission from Mo Jia:

Here is the failed message . 


Project "D:\Hg\Python\Python\PCbuild\_ssl.vcxproj" (17) is building "D:\Hg\Python\Python\PCbuild\ssl.vcxproj" (18) on node 1 (default targets).                                     
Build:                                                                                                                                                                              
  cd "D:\Hg\Python\Python\PCbuild\"                                                                                                                                                 
  "D:\Hg\Python\Python\PCbuild\python_d.exe" build_ssl.py Release Win32 -a                                                                                                          
                                                                                                                                                                                    
  Found a working perl at 'C:\Perl\bin\perl.exe'                                                                                                                                    
  Executing ssl makefiles: nmake /nologo -f "ms\nt.mak"                                                                                                                             
  Building OpenSSL                                                                                                                                                                  
        copy ".\crypto\buildinf.h" "tmp32\buildinf.h"                                                                                                                               
          1 file(s) copied.                                                                                                                                                         
        copy ".\crypto\opensslconf.h" "inc32\openssl\opensslconf.h"                                                                                                                 
          1 file(s) copied.                                                                                                                                                         
          cl /Fotmp32\shatest.obj -Iinc32 -Itmp32 /MT /Ox /O2 /Ob2 -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN 
   -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_A 
  SM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNA 
  MIC_ENGINE /Zi /Fdtmp32/app -c .\crypto\sha\shatest.c                                                                                                                             
  shatest.c                                                                                                                                                                         
        link /nologo /subsystem:console /opt:ref /debug /out:out32\shatest.exe @C:\Users\YANXIN~1\AppData\Local\Temp\nm306E.tmp                                                     
libeay32.lib(b_print.obj) : error LNK2019: unresolved external symbol ___report_rangecheckfailure referenced in function _fmtfp [D:\Hg\Python\Python\PCbuild\ssl.vcxproj]           
libeay32.lib(obj_dat.obj) : error LNK2001: unresolved external symbol ___report_rangecheckfailure [D:\Hg\Python\Python\PCbuild\ssl.vcxproj]                                         
libeay32.lib(b_dump.obj) : error LNK2001: unresolved external symbol ___report_rangecheckfailure [D:\Hg\Python\Python\PCbuild\ssl.vcxproj]                                          
libeay32.lib(pem_lib.obj) : error LNK2001: unresolved external symbol ___report_rangecheckfailure [D:\Hg\Python\Python\PCbuild\ssl.vcxproj]                                         
out32\shatest.exe : fatal error LNK1120: 1 unresolved externals [D:\Hg\Python\Python\PCbuild\ssl.vcxproj]                                                                           
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.EXE"' : return code '0x460' [D:\Hg\Python\Python\PCbuild\ssl.vcxproj]                  
  Stop.                                                                                                                                                                             
  Executing ms\nt.mak failed                                                                                                                                                        
  2

----------
components: Windows
messages: 219482
nosy: Mo.Jia
priority: normal
severity: normal
status: open
title: build ssl failed use vs2010 express
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  1 06:41:10 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jun 2014 04:41:10 +0000
Subject: [New-bugs-announce] [issue21624] Idle: polish htests
Message-ID: <1401597670.32.0.0453403071197.issue21624@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

#21477 was about finishing the htest framework and creating at least a first draft of each human test. This issue is about refining individual tests. One remaining issue is placement of the master window and placement of test windows in relation to the master. The test message for some might use editing. Tests that only test behavior might be replaced by a unittest module. Some general tests, such as for Editor Window, might be split into separate tests with more specific instructions. These changes might or might not be done as part of the GSOC project.

----------
assignee: terry.reedy
messages: 219486
nosy: jesstess, sahutd, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: polish htests
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun  1 14:04:38 2014
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 01 Jun 2014 12:04:38 +0000
Subject: [New-bugs-announce] [issue21625] help()'s more-mode is frustrating
Message-ID: <1401624278.41.0.968851571107.issue21625@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

>From the #python IRC channel:

```
[07:55:29] tonysar	 hello.new to programming and python, i use mac terminal but problem i have is , when i use help function of python to look up something , i lose my prompt and i have no idea how to go back , what i do is close the terminal and restart , is there any way to go back to prompt again ?
[07:57:12] nedbat	 tonysar: type a "q"
[07:57:26] nedbat	 tonysar: it works like the unix-standard "more" program.
[07:58:10] nedbat	 tonysar: looking at it through your eyes, it's crazy-unhelpful that it only accepts a q....
[07:58:42] tonysar	 nedbat: thanks but i can not type anything , after using help(object) i get the info on object i look and there is END at the bottom of python terminal and i can not type anything after or before
[07:59:03] nedbat	 tonysar: what happens if you type q ?
[07:59:24] nedbat	 tonysar: just the single letter q
[07:59:41] tonysar	 nedbat . thanks
[07:59:47] tonysar	 the q worked
[08:01:08] tonysar	 nedbat:Thanks. typing q got me back to prompt again . thanks again
```

Why does help() enter a more-mode for even short help?  Why doesn't ENTER get you out of it?  Why doesn't the prompt have a suggestion of how to get out of it?  Why does it clear the screen when you are done with it, removing all the help from the screen?

It seems very geeky, and not that help-ful.  I'm sure there's something we can do to make this a little easier for newbs.

----------
messages: 219497
nosy: nedbat
priority: normal
severity: normal
status: open
title: help()'s more-mode is frustrating
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun Jun  1 16:10:35 2014
From: report at bugs.python.org (B. Clausius)
Date: Sun, 01 Jun 2014 14:10:35 +0000
Subject: [New-bugs-announce] [issue21626] Add options width and compact to
	pickle cli
Message-ID: <1401631835.62.0.606792689422.issue21626@psf.upfronthosting.co.za>


New submission from B. Clausius:

The attached patch add this options to "python3 -m pickle" cli:
  -w WIDTH, --width WIDTH
                        maximum number of characters per line
  -c, --compact         display as many items as will fit on each output line
The options are forwarded as kwargs to pprint.pprint

----------
components: Library (Lib)
files: pickle_cli-options_width_and_compact.patch
keywords: patch
messages: 219501
nosy: barcc
priority: normal
severity: normal
status: open
title: Add options width and compact to pickle cli
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35434/pickle_cli-options_width_and_compact.patch

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

From report at bugs.python.org  Sun Jun  1 19:22:33 2014
From: report at bugs.python.org (Steven Stewart-Gallus)
Date: Sun, 01 Jun 2014 17:22:33 +0000
Subject: [New-bugs-announce] [issue21627] Concurrently closing files and
	iterating over the open	files directory is not well specified
Message-ID: <1401643353.39.0.53304722389.issue21627@psf.upfronthosting.co.za>


New submission from Steven Stewart-Gallus:

Hello,

I noticed some possible bad behaviour while working on Python issue
21618 (see http://bugs.python.org/issue21618). Python has the
following code in _posixsubmodules.c for closing extra files before
spawning a process:

static void
_close_open_fd_range_safe(int start_fd, int end_fd, PyObject* py_fds_to_keep)
{
    int fd_dir_fd;
    if (start_fd >= end_fd)
        return;

    fd_dir_fd = _Py_open(FD_DIR, O_RDONLY);
    if (fd_dir_fd == -1) {
        /* No way to get a list of open fds. */
        _close_fds_by_brute_force(start_fd, end_fd, py_fds_to_keep);
        return;
    } else {
        char buffer[sizeof(struct linux_dirent64)];
        int bytes;
        while ((bytes = syscall(SYS_getdents64, fd_dir_fd,
                                (struct linux_dirent64 *)buffer,
                                sizeof(buffer))) > 0) {
            struct linux_dirent64 *entry;
            int offset;
            for (offset = 0; offset < bytes; offset += entry->d_reclen) {
                int fd;
                entry = (struct linux_dirent64 *)(buffer + offset);
                if ((fd = _pos_int_from_ascii(entry->d_name)) < 0)
                    continue;  /* Not a number. */
                if (fd != fd_dir_fd && fd >= start_fd && fd < end_fd &&
                    !_is_fd_in_sorted_fd_sequence(fd, py_fds_to_keep)) {
                    while (close(fd) < 0 && errno == EINTR);
                }
            }
        }
        close(fd_dir_fd);
    }
}

In the code FD_DIR is "/proc/self/fd" on Linux. I'm not sure this code
is correct. This seems as if it would have the same problems as
iterating over a list and modifying it at the same time.

I can think of a few solutions but they all have problems.

One could allocate a list of open files once and then iterate through
that list and close the files but this is not signal safe so this
solution is incorrect. One possible workaround is to use mmap to
allocate the memory. This is a direct system call and I don't see a
reason for it not to be signal safe but I'm not sure. One neat hack
would be too mmap the memory ahead of time and then rely on lazy
paging to allocate the memory lazily. Another solution is to search
for the largest open file and then iterate over and close all the
possible file descriptors in between. So far most possible solutions
just seem really hacky to me though.

I feel the best solution is to let the OS close the files and to set
the O_CLOEXEC flag on the files that need to be closed.

----------
messages: 219510
nosy: sstewartgallus
priority: normal
severity: normal
status: open
title: Concurrently closing files and iterating over the open files directory is not well specified

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

From report at bugs.python.org  Sun Jun  1 19:27:53 2014
From: report at bugs.python.org (RobertG)
Date: Sun, 01 Jun 2014 17:27:53 +0000
Subject: [New-bugs-announce] [issue21628] 2to3 does not fix zip in some cases
Message-ID: <1401643673.43.0.6506799869.issue21628@psf.upfronthosting.co.za>


New submission from RobertG:

Consider this program

def foo(a,b):
	return min(zip(a,b)[2])

print foo(range(5), (0,9,-9))

With the default options, 2to3 rewrites this as

def foo(a,b):
	return min(zip(a,b)[2])

print(foo(list(range(5)), (0,9,-9)))

For some reason, 2to3 fails to wrap the call to zip in a list, even though the 2to3 documentation says that there is a fixer which does this. Obviously, the generated code will not work in Python 3 since you can't subscript an iterator.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 219511
nosy: RobertG
priority: normal
severity: normal
status: open
title: 2to3 does not fix zip in some cases
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  1 19:50:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jun 2014 17:50:52 +0000
Subject: [New-bugs-announce] [issue21629] clinic.py --converters fails
Message-ID: <1401645052.61.0.988183577519.issue21629@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python Tools/clinic/clinic.py --converters

Legacy converters:
Traceback (most recent call last):
  File "Tools/clinic/clinic.py", line 4199, in <module>
    sys.exit(main(sys.argv[1:]))
  File "Tools/clinic/clinic.py", line 4131, in main
    print('    ' + ' '.join(c for c in legacy if c[0].isupper()))
  File "Tools/clinic/clinic.py", line 4131, in <genexpr>
    print('    ' + ' '.join(c for c in legacy if c[0].isupper()))
IndexError: string index out of range

As I see, the problem is in the self converter which has empty format_unit.

----------
components: Demos and Tools
messages: 219512
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: clinic.py --converters fails
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun  1 19:51:21 2014
From: report at bugs.python.org (Robert w)
Date: Sun, 01 Jun 2014 17:51:21 +0000
Subject: [New-bugs-announce] [issue21630] List Dict bug?
Message-ID: <1401645081.14.0.213234541385.issue21630@psf.upfronthosting.co.za>


New submission from Robert w:

outer for loop loops n > 1 times, when it should loop one time.

Variations are possible tht the bug doesn't occur.

----------
components: Interpreter Core
files: bug.py
messages: 219513
nosy: Robert.w
priority: normal
severity: normal
status: open
title: List Dict bug?
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file35439/bug.py

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

From report at bugs.python.org  Sun Jun  1 19:56:46 2014
From: report at bugs.python.org (Robert w)
Date: Sun, 01 Jun 2014 17:56:46 +0000
Subject: [New-bugs-announce] [issue21631] List/Dict Combination Bug
Message-ID: <1401645406.57.0.0613962818315.issue21631@psf.upfronthosting.co.za>


New submission from Robert w:

outer for loop loops more than one time, which should be impossible.

----------
components: Interpreter Core
files: bug.py
messages: 219514
nosy: Robert.w
priority: normal
severity: normal
status: open
title: List/Dict Combination Bug
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file35440/bug.py

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

From report at bugs.python.org  Sun Jun  1 22:04:08 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Jun 2014 20:04:08 +0000
Subject: [New-bugs-announce] [issue21632] Idle: sychronize text files across
	versions as	appropriate.
Message-ID: <1401653048.67.0.410075240999.issue21632@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Spinoff of #7136: In pushing the patch for that issue, I discovered that formatting changes for help.txt (and maybe /Doc/library/idle.rst) had been applied unevenly. See msg192141, which suggests this issue. 3.3 versus 3.4 differences are moot, so this now means 2.7 versus 3.4+.

----------
assignee: terry.reedy
messages: 219521
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: sychronize text files across versions as appropriate.
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun  2 01:32:36 2014
From: report at bugs.python.org (Michael Cohen)
Date: Sun, 01 Jun 2014 23:32:36 +0000
Subject: [New-bugs-announce] [issue21633] Argparse does not propagate
	HelpFormatter class to	subparsers
Message-ID: <1401665556.26.0.881749322578.issue21633@psf.upfronthosting.co.za>


New submission from Michael Cohen:

Argparse has an option to set the custom help formatter class as a kwarg. For example one can define:


class MyHelpFormatter(argparse.RawDescriptionHelpFormatter):
    def add_argument(self, action):
        if action.dest != "SUPPRESS":
            super(RekallHelpFormatter, self).add_argument(action)


parser = ArguementParser(
   formatter_class=MyHelpFormatter)


But when one creates a subparser there is no way to define the formatter class for it - i.e. parser.add_subparsers() does not accept a formatter_class parameter. Instead we see this code:

    def add_subparsers(self, **kwargs):
        ...
        # add the parser class to the arguments if it's not present
        kwargs.setdefault('parser_class', type(self))

The only way to make this work is to extend ArguementParser to force it to use the formatter_class through inheritance:

class MyArgParser(argparse.ArgumentParser):

    def __init__(self, **kwargs):
        kwargs["formatter_class"] = MyHelpFormatter
	super(MyArgParser, self).__init__(**kwargs)

this is counter intuitive since formatter_class can be passed to the constructor but then it is not propagated to subparsers.

IMHO the expect action here is to have the formatter_class automatically propagates to subparsers as well. Short of that we need to be able to specific it in add_subparser() call.

----------
components: Extension Modules
messages: 219534
nosy: Michael.Cohen
priority: normal
severity: normal
status: open
title: Argparse does not propagate HelpFormatter class to subparsers
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  2 11:27:08 2014
From: report at bugs.python.org (Lennart Regebro)
Date: Mon, 02 Jun 2014 09:27:08 +0000
Subject: [New-bugs-announce] [issue21634] Pystone uses floats
Message-ID: <1401701228.7.0.484236957852.issue21634@psf.upfronthosting.co.za>


New submission from Lennart Regebro:

Pystone uses some floats in Python 3, while in Python 2 it's all integers. And since it is, as far as I can tell, based on Dhrystone, it should be all ints.

After fixing the division in the loop to be a floor division it runs the same as in Python 2. I've verified that after the attached fix the only floats created are time stamps, so this seems to be all that's needed.

This also makes the benchmark run c:a 5% faster, lessening the speed difference in pystone between Python 2 and Python 3, which contributes to the misconception that Python 3 is horribly slow.

----------
components: Benchmarks
files: pystone.diff
keywords: patch
messages: 219559
nosy: lregebro
priority: normal
severity: normal
status: open
title: Pystone uses floats
type: performance
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35442/pystone.diff

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

From report at bugs.python.org  Mon Jun  2 12:03:56 2014
From: report at bugs.python.org (drevicko)
Date: Mon, 02 Jun 2014 10:03:56 +0000
Subject: [New-bugs-announce] [issue21635] difflib.SequenceMatcher stores
	matching blocks as tuples, not Match named tuples
Message-ID: <1401703436.14.0.164374106757.issue21635@psf.upfronthosting.co.za>


New submission from drevicko:

difflib.SequenceMatcher.get_matching_blocks() last lines:


        non_adjacent.append( (la, lb, 0) )
        self.matching_blocks = non_adjacent
        return map(Match._make, self.matching_blocks)

should be something like:

        non_adjacent.append( (la, lb, 0) )
        self.matching_blocks = map(Match._make, non_adjacent)
        return self.matching_blocks

----------
components: Library (Lib)
messages: 219565
nosy: drevicko
priority: normal
severity: normal
status: open
title: difflib.SequenceMatcher stores matching blocks as tuples, not Match named tuples
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  2 14:08:06 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 02 Jun 2014 12:08:06 +0000
Subject: [New-bugs-announce] [issue21636] test_logging fails on Windows for
	Unix tests
Message-ID: <1401710886.02.0.477196049958.issue21636@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello! The attached patch fixes a crash for the logging tests on Windows. That's because the tests assume that socket.AF_UNIX exists. The actual traceback is:

[1/1] test_logging
test test_logging crashed -- Traceback (most recent call last):
  File "D:\Projects\cpython\lib\test\regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "D:\Projects\cpython\lib\importlib\__init__.py", line 109, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2203, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2186, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2175, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1149, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1420, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "D:\Projects\cpython\lib\test\test_logging.py", line 863, in <module>
    class TestUnixStreamServer(TestTCPServer):
  File "D:\Projects\cpython\lib\test\test_logging.py", line 864, in TestUnixStreamServer
    address_family = socket.AF_UNIX
AttributeError: module 'socket' has no attribute 'AF_UNIX'

1 test failed:
    test_logging

----------
components: Tests
files: logging_windows.patch
keywords: patch
messages: 219572
nosy: Claudiu.Popa, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging fails on Windows for Unix tests
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35449/logging_windows.patch

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

From report at bugs.python.org  Mon Jun  2 15:35:34 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Mon, 02 Jun 2014 13:35:34 +0000
Subject: [New-bugs-announce] [issue21637] Add a warning section exaplaining
	that tempfiles are	opened in binary mode
Message-ID: <1401716134.93.0.330807213561.issue21637@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

Although it is already explained that the default mode of the opened tempfiles is 'w+b' a warning/notice section should be included to make it clearer.

I think this is important as the default for the open function is to return strings and not bytes.

I just had to debug an error with traceback, as traceback.print_exc expects a file capable of handling unicode.

----------
assignee: docs at python
components: Documentation
messages: 219585
nosy: Sebastian.Kreft.Deezer, docs at python
priority: normal
severity: normal
status: open
title: Add a warning section exaplaining that tempfiles are opened in binary mode
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  2 15:39:16 2014
From: report at bugs.python.org (Linlin Yan)
Date: Mon, 02 Jun 2014 13:39:16 +0000
Subject: [New-bugs-announce] [issue21638] Seeking to EOF is too inefficient!
Message-ID: <1401716356.76.0.730972097827.issue21638@psf.upfronthosting.co.za>


New submission from Linlin Yan:

I noticed this problem when I run a Python2 program (MACS: http://liulab.dfci.harvard.edu/MACS/) very inefficiently on a large storage on a high performace server (64-bit Linux). It was much slower (more than two days) than running it on a normal PC (less than two hours).

After ruling out many optimizing conditions, I finally located the problem on the seek() function of Python2. Now I can reproduce the problem in a very simple example:

#!/usr/bin/python2
f = open("Input.sort.bam", "rb")
f.seek(0, 2)
f.close()

Here, the size of file 'Input.sort.bam' is 4,110,535,920 bytes. When I run the program with 'strace' to see the system calls on Linux:

$ strace python2 foo.py
...
open("Input.sort.bam", O_RDONLY)        = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4110535920, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=4110535920, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f23d4492000
fstat(3, {st_mode=S_IFREG|0644, st_size=4110535920, ...}) = 0
lseek(3, 4110532608, SEEK_SET)          = 4110532608
read(3, "f\203\337<\334\350\313\315\345&T\227\211\fC\212a\260\204P\235\366\326\353\230\327>\373\361\221\357\373"..., 3312) = 3312
close(3)                                = 0
...

It seems that python2 just move file cursor to a specific position (4110532608 in this case) and read ahead the rest bytes, rather than seek to the file end directly. I tried to run the exact the same program on the large storage, the position changed to 1073741824, left 889310448 bytes to read to reach the file end, which reduced the performance a lot!

----------
components: IO
messages: 219586
nosy: yanlinlin82
priority: normal
severity: normal
status: open
title: Seeking to EOF is too inefficient!
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  2 15:52:03 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 02 Jun 2014 13:52:03 +0000
Subject: [New-bugs-announce] [issue21639] tracemalloc crashes with floating
	point exception when	using StringIO
Message-ID: <1401717123.97.0.114910217041.issue21639@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Given the following code, tracemalloc crashes with:
"Floating point exception: 8 (core dumped)"

import tracemalloc
tracemalloc.start(10)
import io
io.StringIO()

The culprit is this line "assert(nelem <= PY_SIZE_MAX / elsize);" from tracemalloc_alloc. elsize is 0 from stringio.c, "self->buf = (Py_UCS4 *)PyMem_Malloc(0);".
The attached patch skips the assert if elsize is 0, but I don't know if this is the right approach.
Thanks!

----------
components: Library (Lib)
files: tracemalloc.patch
keywords: patch
messages: 219587
nosy: Claudiu.Popa, haypo
priority: normal
severity: normal
status: open
title: tracemalloc crashes with floating point exception when using StringIO
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file35450/tracemalloc.patch

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

From report at bugs.python.org  Mon Jun  2 15:53:02 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:53:02 +0000
Subject: [New-bugs-announce] [issue21640] References to other Python version
	in sidebar of	documentation index is not up to date
Message-ID: <1401717182.28.0.393851427001.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: python_2.7.patch
keywords: patch
nosy: OrangeTux, docs at python
priority: normal
severity: normal
status: open
title: References to other Python version in sidebar of documentation index is not up to date
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/file35451/python_2.7.patch

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

From report at bugs.python.org  Mon Jun  2 16:55:42 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 02 Jun 2014 14:55:42 +0000
Subject: [New-bugs-announce] [issue21641] smtplib leaves open sockets around
	if	SMTPResponseException is raised in __init__
Message-ID: <1401720942.39.0.48870811951.issue21641@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello!

I noticed that test_smtplib raises a ResourceWarning, tracking this to this piece of code:

   self.assertRaises(smtplib.SMTPResponseException, smtplib.SMTP,
                     HOST, self.port, 'localhost', 3)

What happens is that `SMTP.getreply` is called in `SMTP.__init__` after the socket was opened, but if getreply raises SMTPResponseException, the socket remains opened. The attached patch fixes this.

----------
components: Library (Lib)
files: smtplib_resource_warning.patch
keywords: patch
messages: 219592
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: smtplib leaves open sockets around if SMTPResponseException is raised in __init__
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35459/smtplib_resource_warning.patch

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

From report at bugs.python.org  Mon Jun  2 20:24:00 2014
From: report at bugs.python.org (Joshua Landau)
Date: Mon, 02 Jun 2014 18:24:00 +0000
Subject: [New-bugs-announce] [issue21642] "_ if 1else _" does not compile
Message-ID: <1401733440.77.0.120432390188.issue21642@psf.upfronthosting.co.za>


New submission from Joshua Landau:

By the docs,

    Except at the beginning of a logical line or in
    string literals, the whitespace characters space,
    tab and formfeed can be used interchangeably to
    separate tokens. Whitespace is needed between two
    tokens only if their concatenation could otherwise
    be interpreted as a different token
    (e.g., ab is one token, but a b is two tokens).

"_ if 1else _" should compile equivalently to "_ if 1 else _".

The tokenize module does this correctly:

    import io
    import tokenize

    def print_tokens(string):
        tokens = tokenize.tokenize(io.BytesIO(string.encode("utf8")).readline)    

        for token in tokens:
            print("{:12}{}".format(tokenize.tok_name[token.type], token.string))

    print_tokens("_ if 1else _")
    #>>> ENCODING    utf-8
    #>>> NAME        _
    #>>> NAME        if
    #>>> NUMBER      1
    #>>> NAME        else
    #>>> NAME        _
    #>>> ENDMARKER   

but it fails when compiled with, say, "compile", "eval" or "ast.parse".

    import ast

    compile("_ if 1else _", "", "eval")
    #>>> Traceback (most recent call last):
    #>>>   File "", line 32, in <module>
    #>>>   File "<string>", line 1
    #>>>     _ if 1else _
    #>>>           ^
    #>>> SyntaxError: invalid token

    eval("_ if 1else _")
    #>>> Traceback (most recent call last):
    #>>>   File "", line 40, in <module>
    #>>>   File "<string>", line 1
    #>>>     _ if 1else _
    #>>>           ^
    #>>> SyntaxError: invalid token

    ast.parse("_ if 1else _")
    #>>> Traceback (most recent call last):
    #>>>   File "", line 48, in <module>
    #>>>   File "/usr/lib/python3.4/ast.py", line 35, in parse
    #>>>     return compile(source, filename, mode, PyCF_ONLY_AST)
    #>>>   File "<unknown>", line 1
    #>>>     _ if 1else _
    #>>>           ^
    #>>> SyntaxError: invalid token

Further, some other forms work:

    1 if 0b1else 0
    #>>> 1

    1 if 1jelse 0
    #>>> 1

See

    http://stackoverflow.com/questions/23998026/why-isnt-this-a-syntax-error-in-python

particularly,

    http://stackoverflow.com/a/23998128/1763356

for details.

----------
messages: 219614
nosy: Joshua.Landau
priority: normal
severity: normal
status: open
title: "_ if 1else _" does not compile
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  2 20:47:26 2014
From: report at bugs.python.org (Virgil Dupras)
Date: Mon, 02 Jun 2014 18:47:26 +0000
Subject: [New-bugs-announce] [issue21643] "File exists" error during venv
	--upgrade
Message-ID: <1401734846.63.0.441941571426.issue21643@psf.upfronthosting.co.za>


New submission from Virgil Dupras:

There seems to have been a regression in Python 3.4.1 with "pyvenv --upgrade", and this regression seems to be caused by #21197.

It now seems impossible to use the "--upgrade" flag without getting a "File exists" error. Steps to reproduce:

$ pyvenv env
$ pyvenv --upgrade env
Error: [Errno 17] File exists: '/<pwd>/env/lib' -> '/<pwd>/env/lib64'

----------
components: Library (Lib)
keywords: 3.4regression
messages: 219617
nosy: vdupras, vinay.sajip
priority: normal
severity: normal
status: open
title: "File exists" error during venv --upgrade
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  2 22:25:58 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Jun 2014 20:25:58 +0000
Subject: [New-bugs-announce] [issue21644] Optimize bytearray(int)
	constructor to use calloc()
Message-ID: <1401740758.16.0.943124117891.issue21644@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 3.5 has a new PyObject_Calloc() function which can be used for fast memory allocation of memory block initialized with zeros.

I already implemented an optimization, but Stefan Krah found issues in my change:
http://bugs.python.org/issue21233#msg217826

I reverted the optimization in the changeset dff6b4b61cac.

----------
messages: 219632
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: Optimize bytearray(int) constructor to use calloc()
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun  3 00:35:54 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Jun 2014 22:35:54 +0000
Subject: [New-bugs-announce] [issue21645] test_read_all_from_pipe_reader()
	of test_asyncio hangs	on FreeBSD 9
Message-ID: <1401748554.93.0.147613682728.issue21645@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.4/builds/191/steps/test/logs/stdio

[  8/389] test_asyncio
Timeout (1:00:00)!
Thread 0x0000000801407400 (most recent call first):
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/selectors.py", line 494 in select
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/asyncio/base_events.py", line 795 in _run_once
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/asyncio/base_events.py", line 184 in run_forever
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/asyncio/base_events.py", line 203 in run_until_complete
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/test_asyncio/test_streams.py", line 617 in test_read_all_from_pipe_reader
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/case.py", line 577 in run
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/case.py", line 625 in __call__
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/suite.py", line 125 in run
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/suite.py", line 87 in __call__
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/suite.py", line 125 in run
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/suite.py", line 87 in __call__
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/suite.py", line 125 in run
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/suite.py", line 87 in __call__
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/support/__init__.py", line 1724 in _run_suite
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/support/__init__.py", line 1758 in run_unittest
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/test_asyncio/__init__.py", line 29 in test_main
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/regrtest.py", line 967 in runtest
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/regrtest.py", line 763 in main
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/buildarea/3.4.krah-freebsd/build/Lib/runpy.py", line 170 in _run_module_as_main

----------
components: Tests
keywords: buildbot
messages: 219647
nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: test_read_all_from_pipe_reader() of test_asyncio hangs on FreeBSD 9
versions: Python 3.4

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

From report at bugs.python.org  Tue Jun  3 07:46:26 2014
From: report at bugs.python.org (ingrid)
Date: Tue, 03 Jun 2014 05:46:26 +0000
Subject: [New-bugs-announce] [issue21646] Add tests for turtle.ScrolledCanvas
Message-ID: <1401774386.8.0.333325223476.issue21646@psf.upfronthosting.co.za>


Changes by ingrid <hi at ingridcheung.com>:


----------
components: Tests
nosy: ingrid, jesstess
priority: normal
severity: normal
status: open
title: Add tests for turtle.ScrolledCanvas
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun  3 07:58:40 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Jun 2014 05:58:40 +0000
Subject: [New-bugs-announce] [issue21647] Idle unittests: make gui,
	mock switching easier.
Message-ID: <1401775120.92.0.367070549797.issue21647@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Idle unittests that use tkinter.Text are developed using the gui widget and then switched, to the current extent possible, to mock_tk.Text. I have done this previously by commenting out gui lines and adding new lines, so it would be possible to switch back if needed. test_searchengine is an example. However, switching back would require commenting and uncommenting several lines.

When reviewing test_autoexpand #18292, I realized that everything after the imports

from tkinter import Text
from idlelib.idle_text.mock_tk import Text

can be made conditional on 'tkinter in str(Text)'. The only comment switching needed is for the import lines. This issue is about retrofitting test_searchengine and any other files that need it.

----------
messages: 219663
nosy: sahutd, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle unittests: make gui, mock switching easier.
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun  3 11:03:17 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 03 Jun 2014 09:03:17 +0000
Subject: [New-bugs-announce] [issue21648] urllib urlopener leaves open
	sockets for FTP connection
Message-ID: <1401786197.78.0.84554698423.issue21648@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

To be precise, when running test_urllib on a machine with a local FTP server, but with a set of credentials different than the ones used by test_urllib.urlopen_HttpTests.test_ftp_nonexisting. In this case, ftpwrapper from urllib.request will succesfully connect to the FTP server, but it will fail when sending the credentials, leaving the connection opened. The attached patch tries to fix this.

----------
components: Library (Lib)
files: urllib_ftp_resource_warning.patch
keywords: patch
messages: 219671
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: urllib urlopener leaves open sockets for FTP connection
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file35467/urllib_ftp_resource_warning.patch

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

From report at bugs.python.org  Tue Jun  3 11:09:57 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jun 2014 09:09:57 +0000
Subject: [New-bugs-announce] [issue21649] Mention "Recommendations for
	Secure Use of TLS and DTLS"
Message-ID: <1401786597.2.0.166065083457.issue21649@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The IETF has a draft for TLS protocol recommendations, perhaps we can mention it in the ssl module docs:

http://tools.ietf.org/html/draft-ietf-uta-tls-bcp

----------
assignee: docs at python
components: Documentation
messages: 219673
nosy: christian.heimes, docs at python, dstufft, giampaolo.rodola, janssen, pitrou
priority: low
severity: normal
status: open
title: Mention "Recommendations for Secure Use of TLS and DTLS"
type: enhancement

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

From report at bugs.python.org  Tue Jun  3 12:11:31 2014
From: report at bugs.python.org (Pavel Kazlou)
Date: Tue, 03 Jun 2014 10:11:31 +0000
Subject: [New-bugs-announce] [issue21650] add json.tool option to avoid
	alphabetic sort of fields
Message-ID: <1401790291.36.0.355130758438.issue21650@psf.upfronthosting.co.za>


New submission from Pavel Kazlou:

Currently when you use json.tool, fields are reordered alphabetically.
In source code the value of sort_keys is hardcoded to be true.
It should be easy to expose this option as command line parameter.

----------
components: Library (Lib)
messages: 219675
nosy: Pavel.Kazlou
priority: normal
severity: normal
status: open
title: add json.tool option to avoid alphabetic sort of fields
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun  3 13:12:34 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 03 Jun 2014 11:12:34 +0000
Subject: [New-bugs-announce] [issue21651] asyncio tests ResourceWarning
Message-ID: <1401793954.84.0.965903209571.issue21651@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Running asyncio tests on Windows will give a ResourceWarning. The attached patch fixes this problem.

[1/1] test_asyncio
D:\Projects\cpython\lib\test\test_asyncio\test_events.py:233: ResourceWarning: unclosed <socket.socket fd=668, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, pro
o=0, laddr=('127.0.0.1', 53044), raddr=('127.0.0.1', 53043)>
  gc.collect()
D:\Projects\cpython\lib\test\test_asyncio\test_events.py:233: ResourceWarning: unclosed <socket.socket fd=724, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, pro
o=0, laddr=('127.0.0.1', 53043), raddr=('127.0.0.1', 53044)>
  gc.collect()
1 test OK.

----------
components: Library (Lib)
files: asyncio_resource_warning.patch
keywords: patch
messages: 219681
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: asyncio tests ResourceWarning
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file35469/asyncio_resource_warning.patch

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

From report at bugs.python.org  Tue Jun  3 16:42:12 2014
From: report at bugs.python.org (James Y Knight)
Date: Tue, 03 Jun 2014 14:42:12 +0000
Subject: [New-bugs-announce] [issue21652] Python 2.7.7 regression in
	mimetypes module on Windows
Message-ID: <1401806532.19.0.598955090686.issue21652@psf.upfronthosting.co.za>


New submission from James Y Knight:

The change done for issue9291 in Python 2.7.7 caused the mimetypes.types_map dict to change to contain a mixture of str and unicode objects, rather than just str, as it always had before.

This causes twisted.web to crash when serving static files on Windows. See https://twistedmatrix.com/trac/ticket/7461 for the bug report against Twisted.

----------
components: Library (Lib)
messages: 219693
nosy: Daniel.Szoska, Dmitry.Jemerov, Hugo.Lol, Micha?.Pasternak, Roman.Evstifeev, Suzumizaki, Vladimir Iofik, aclover, adamhj, brian.curtin, eric.araujo, foom, frankoid, haypo, jason.coombs, kaizhu, loewis, me21, python-dev, quick.es, r.david.murray, shimizukawa, tim.golden, vldmit
priority: normal
severity: normal
status: open
title: Python 2.7.7 regression in mimetypes module on Windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  4 00:12:21 2014
From: report at bugs.python.org (Andrew McKinlay)
Date: Tue, 03 Jun 2014 22:12:21 +0000
Subject: [New-bugs-announce] [issue21653] Row.keys() in sqlite3 returns a
	list, not a tuple
Message-ID: <1401833541.21.0.885626221521.issue21653@psf.upfronthosting.co.za>


New submission from Andrew McKinlay:

The documentation here (https://docs.python.org/2/library/sqlite3.html#sqlite3.Row.keys) says that the method returns a tuple. It returns a list.

----------
assignee: docs at python
components: Documentation
messages: 219724
nosy: amckinlay, docs at python
priority: normal
severity: normal
status: open
title: Row.keys() in sqlite3 returns a list, not a tuple
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  4 03:31:00 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Jun 2014 01:31:00 +0000
Subject: [New-bugs-announce] [issue21654] IDLE call tips emitting future
	warnings about	ElementTree objects
Message-ID: <1401845460.42.0.600793284066.issue21654@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

While editing code that uses ElementTree, the call tips code is working in the background and emits warnings to the console:

Warning (from warnings module):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/CallTips.py", line 170
    if ob.im_self:
FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.

This appears to be an unfortunate interaction between the call tips code and the objects being call-tipped.  The behavior appears to be new (I had not encountered it prior to 2.7.7).

If possible the call-tip code should test for len(ob.im_self) or somesuch.

----------
components: IDLE
messages: 219739
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE call tips emitting future warnings about ElementTree objects
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  4 09:05:20 2014
From: report at bugs.python.org (Lita Cho)
Date: Wed, 04 Jun 2014 07:05:20 +0000
Subject: [New-bugs-announce] [issue21655] Write Unit Test for Vec2 class in
	the Turtle Module
Message-ID: <1401865520.46.0.61494157732.issue21655@psf.upfronthosting.co.za>


New submission from Lita Cho:

Ingrid and I are trying to add test coverage to the Turtle module as there isn't one currently. Going to work on testing the Vec2 module.

----------
components: Tests, Tkinter
messages: 219747
nosy: Lita.Cho, jesstess
priority: normal
severity: normal
status: open
title: Write Unit Test for Vec2 class in the Turtle Module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun  4 09:08:42 2014
From: report at bugs.python.org (Lita Cho)
Date: Wed, 04 Jun 2014 07:08:42 +0000
Subject: [New-bugs-announce] [issue21656] Create test coverage for
	TurtleScreenBase in Turtle
Message-ID: <1401865722.48.0.508275851704.issue21656@psf.upfronthosting.co.za>


New submission from Lita Cho:

Turtle module currently doesn't have any tests. This ticket is tracking the tests created for TurtleScreenBase.

----------
components: Tests
messages: 219748
nosy: Lita.Cho, jesstess
priority: normal
severity: normal
status: open
title: Create test coverage for TurtleScreenBase in Turtle
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun  4 09:43:55 2014
From: report at bugs.python.org (Adam Matan)
Date: Wed, 04 Jun 2014 07:43:55 +0000
Subject: [New-bugs-announce] [issue21657] pip.get_installed_distributions()
	Does not
Message-ID: <1401867835.25.0.432205285247.issue21657@psf.upfronthosting.co.za>


New submission from Adam Matan:

Abstract:
Calling pip.get_installed_distributions() from a directory with a setup.py file returns a list which does not include the package(s) listed in the setup.py file.

Steps to reproduce:

1. Create a virtual environment and activate it.
2. Download any python git project with a setup.py file to a directory (e.g. git clone https://github.com/behave/behave.git /tmp/behave)
3. Install the project using python setup.py install.
4. Call pip.get_installed_distributions() from the directory which contains the setup.py file.
5. Call pip.get_installed_distributions() from outside the directory which contains the setup.py file.
6. The results from 4 and 5 differs.

See also:

http://stackoverflow.com/questions/739993/how-can-i-get-a-list-of-locally-installed-python-modules/23885252?noredirect=1#comment37045322_23885252

----------
components: Distutils, Library (Lib)
messages: 219751
nosy: Adam.Matan, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: pip.get_installed_distributions() Does not
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  4 11:30:55 2014
From: report at bugs.python.org (Alain Miniussi)
Date: Wed, 04 Jun 2014 09:30:55 +0000
Subject: [New-bugs-announce] [issue21658] __m128,
	can't build 3.4.1 with intel 14.0.0
Message-ID: <1401874255.53.0.168864202018.issue21658@psf.upfronthosting.co.za>


New submission from Alain Miniussi:

In ffi64.c, intel 14.0.0 has an issue with:
{{{
#if defined(__INTEL_COMPILER)
#define UINT128 __m128
#else
...
}}}

At leat on Linux CentOS 6.5, an include directive is required for __m128:
{{{
#if defined(__INTEL_COMPILER)
#include <xmmintrin.h>
#define UINT128 __m128
#else
...
}}}
otherwise, compilation of _ctypes fails.

Regards.

----------
components: ctypes
messages: 219753
nosy: aom
priority: normal
severity: normal
status: open
title: __m128, can't build 3.4.1 with intel 14.0.0
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun  4 14:50:23 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Jun 2014 12:50:23 +0000
Subject: [New-bugs-announce] [issue21659] IDLE: One corner calltip case
Message-ID: <1401886223.28.0.621700071443.issue21659@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

def f(args, kwds, *args1, **kwargs): pass

Then calltip for "f(" shows invalid signature "(args, kwds, *args, **kwds)".

----------
components: IDLE
messages: 219755
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: One corner calltip case
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  4 14:51:32 2014
From: report at bugs.python.org (Michael Haubenwallner)
Date: Wed, 04 Jun 2014 12:51:32 +0000
Subject: [New-bugs-announce] [issue21660] Substitute @TOKENS@ from sysconfig
	variables, for python-config and python.pc
Message-ID: <1401886292.62.0.0451019562691.issue21660@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner:

On the way to fix issue#15590 especially for AIX, I've discovered that the values provided by config.status used to substitute @TOKEN@ in python-config, python.pc as well as python-config.py may contain references to Makefile variables not known within config.status.

So I thought to use the sysconfig.get_config_vars() here as an additional source for replaceable tokens.

This also allows to remove the hackisch @EXENAME@ sedding for python-config.py, as well as to replace the @SO@ seen in python-config.sh.

----------
components: Build
messages: 219756
nosy: haubi
priority: normal
severity: normal
status: open
title: Substitute @TOKENS@ from sysconfig variables, for python-config and python.pc
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun  4 17:49:35 2014
From: report at bugs.python.org (Steve Dougherty)
Date: Wed, 04 Jun 2014 15:49:35 +0000
Subject: [New-bugs-announce] [issue21661] setuptools documentation: typo
Message-ID: <1401896975.69.0.474580151289.issue21661@psf.upfronthosting.co.za>


New submission from Steve Dougherty:

Typo - "it's" is a contraction for "it is" or "it has." "Its" is the posessive form.

----------
assignee: docs at python
components: Documentation
files: typo1.diff
keywords: patch
messages: 219762
nosy: docs at python, sdougherty
priority: normal
severity: normal
status: open
title: setuptools documentation: typo
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35483/typo1.diff

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

From report at bugs.python.org  Wed Jun  4 18:13:53 2014
From: report at bugs.python.org (Steve Dougherty)
Date: Wed, 04 Jun 2014 16:13:53 +0000
Subject: [New-bugs-announce] [issue21662] datamodel documentation: fix typo
	and phrasing
Message-ID: <1401898433.15.0.977060998542.issue21662@psf.upfronthosting.co.za>


New submission from Steve Dougherty:

"Should" was missing an o, and putting the reason first makes the sentence flow better.

----------
assignee: docs at python
components: Documentation
files: typo2.diff
keywords: patch
messages: 219763
nosy: docs at python, sdougherty
priority: normal
severity: normal
status: open
title: datamodel documentation: fix typo and phrasing
versions: Python 3.5
Added file: http://bugs.python.org/file35484/typo2.diff

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

From report at bugs.python.org  Wed Jun  4 20:21:29 2014
From: report at bugs.python.org (BC)
Date: Wed, 04 Jun 2014 18:21:29 +0000
Subject: [New-bugs-announce] [issue21663] venv upgrade fails on Windows when
	copying TCL files
Message-ID: <1401906089.06.0.772491813651.issue21663@psf.upfronthosting.co.za>


New submission from BC:

When upgrading a virtual environment on Windows with venv, the following error is encountered:

Error: [WinError 183] Cannot create a file when that file already exists: 'C:\\Users\\user\\Documents\\sandbox\\Lib\\tcl8.6'

Affects both Python 3.3.5 and 3.4.1. Tested on Windows 7 SP1.

Steps to reproduce:

1. Create a virtual environment with venv:

   C:\Users\user\Documents>c:\Python34\python.exe -m venv sandbox

2. Upgrade the virtual environment:

   C:\Users\user\Documents>c:\Python34\python.exe -m venv --upgrade sandbox
   Error: [WinError 183] Cannot create a file when that file already exists: 'C:\\Users\\user\\Documents\\sandbox\\Lib\\tcl8.6'

----------
components: Library (Lib), Tkinter, Windows
files: venv-upgrade.patch
keywords: patch
messages: 219766
nosy: hashstat
priority: normal
severity: normal
status: open
title: venv upgrade fails on Windows when copying TCL files
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file35486/venv-upgrade.patch

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

From report at bugs.python.org  Wed Jun  4 20:39:04 2014
From: report at bugs.python.org (Yu-Ju Hong)
Date: Wed, 04 Jun 2014 18:39:04 +0000
Subject: [New-bugs-announce] [issue21664] multiprocessing leaks temporary
	directories pymp-xxx
Message-ID: <1401907144.02.0.926823813171.issue21664@psf.upfronthosting.co.za>


New submission from Yu-Ju Hong:

When running many managers (e.g. > 10) in parallel on a decent machine, there is often a number of pymp-xxx directories left in /tmp after the run.

After some digging and debugging, I think the cause is that multiprocessing.managers.SyncManager waits for the manager process to shutdown and join with a timeout of 0.2s, and this timeout is way too low. This leads to processes being forced to terminate before cleaning up the temporary directories properly.

Could the timeout being raised a bit, or at least allowing the timeout to be set when creating the SyncManager through Manager()?

----------
components: Library (Lib)
messages: 219767
nosy: yjhong
priority: normal
severity: normal
status: open
title: multiprocessing leaks temporary directories pymp-xxx
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun  5 01:18:32 2014
From: report at bugs.python.org (Les Bothwell)
Date: Wed, 04 Jun 2014 23:18:32 +0000
Subject: [New-bugs-announce] [issue21665] 2.7.7 ttk widgets not themed
Message-ID: <1401923912.15.0.591794107997.issue21665@psf.upfronthosting.co.za>


New submission from Les Bothwell:

I developed a number of small apps using ttk in 2.7.6.  After installing 2.7.7 all the ttk widgets look like standard Tkinter ones.  I reverted to 2.7.6 and everything looks Ok again. (I tried reinstalling 2.7.7 again with the same result)
Windows 7 X64 using 32 bit python.

----------
components: Tkinter, Windows
messages: 219775
nosy: les.bothwell
priority: normal
severity: normal
status: open
title: 2.7.7 ttk widgets not themed
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun  5 06:25:08 2014
From: report at bugs.python.org (Glenn Linderman)
Date: Thu, 05 Jun 2014 04:25:08 +0000
Subject: [New-bugs-announce] [issue21666] Argparse exceptions should include
	which argument has a	problem
Message-ID: <1401942308.15.0.761903567148.issue21666@psf.upfronthosting.co.za>


New submission from Glenn Linderman:

I coded up a new program, with a bunch of options, and got the following traceback when I tried to run it:

Traceback (most recent call last):
  File "D:\my\py\renmany.py", line 273, in <module>
    args = cmdl.parse_intermixed_args()
  File "D:\my\py\glu\glu.py", line 1695, in parse_intermixed_args
    args, argv = self.parse_known_intermixed_args(args, namespace)
  File "D:\my\py\glu\glu.py", line 1740, in parse_known_intermixed_args
    namespace, remaining_args = self.parse_known_args(args, namespace)
  File "C:\Python33\lib\argparse.py", line 1737, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "C:\Python33\lib\argparse.py", line 1943, in _parse_known_args
    start_index = consume_optional(start_index)
  File "C:\Python33\lib\argparse.py", line 1883, in consume_optional
    take_action(action, args, option_string)
  File "C:\Python33\lib\argparse.py", line 1811, in take_action
    action(self, namespace, argument_values, option_string)
  File "C:\Python33\lib\argparse.py", line 1015, in __call__
    parser.print_help()
  File "C:\Python33\lib\argparse.py", line 2339, in print_help
    self._print_message(self.format_help(), file)
  File "C:\Python33\lib\argparse.py", line 2323, in format_help
    return formatter.format_help()
  File "C:\Python33\lib\argparse.py", line 276, in format_help
    help = self._root_section.format_help()
  File "C:\Python33\lib\argparse.py", line 206, in format_help
    func(*args)
  File "C:\Python33\lib\argparse.py", line 206, in format_help
    func(*args)
  File "C:\Python33\lib\argparse.py", line 513, in _format_action
    help_text = self._expand_help(action)
  File "C:\Python33\lib\argparse.py", line 600, in _expand_help
    return self._get_help_string(action) % params
ValueError: unsupported format character ')' (0x29) at index 673

The only thing I can tell is that something went wrong in ArgParse. I had called a bunch of add_argument, and then a parse_known_args. I had passed parameters to the program to get a help message, so that is what I expect parse_known_args is trying to produce... and the call stack seems to confirm that. I didn't intentionally pass a format character ')' anywhere, but there are ')' characters in some of my help messages, so that is probably the source of the problem. 

No doubt I can reduce the problem space by judiciously commenting out things until I can isolate the particular help message that is causing the failure (it may be more than one as several are similar). But it seems like the exception should include the name of the argument for which the failure occurred.

[OK, I isolated, and found a "%)" sequence in one of my messages that should have been "%%)". So this is not terribly urgent, just poor reporting.]

----------
messages: 219778
nosy: v+python
priority: normal
severity: normal
status: open
title: Argparse exceptions should include which argument has a problem

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

From report at bugs.python.org  Thu Jun  5 13:02:22 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:02:22 +0000
Subject: [New-bugs-announce] [issue21667] Clarify status of O(1) indexing
	semantics of str objects
Message-ID: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Based on the recent python-dev thread, I propose the following "CPython implementation detail" note in the "Strings" entry of https://docs.python.org/3/reference/datamodel.html#objects-values-and-types

"CPython currently guarantees O(1) access to arbitrary code points when indexing and slicing a string. Python implementations are required to index and slice strings as arrays of code points, but are not required to guarantee O(1) access to arbitrary locations within the string. This allows implementations to use variable width encodings for their internal string representation."

----------
assignee: docs at python
components: Documentation
messages: 219793
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Clarify status of O(1) indexing semantics of str objects
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun  5 14:56:33 2014
From: report at bugs.python.org (Fredrik Fornwall)
Date: Thu, 05 Jun 2014 12:56:33 +0000
Subject: [New-bugs-announce] [issue21668] The select and time modules uses
	libm functions without	linking against it
Message-ID: <1401972993.52.0.304727515537.issue21668@psf.upfronthosting.co.za>


New submission from Fredrik Fornwall:

The select and time modules use functions from libm, but do not link against it.

* selectmodule.c calls ceil(3) in pyepoll_poll()
* timemodule.c calls fmod(3) and floor(3) in floatsleep()

----------
components: Build, Cross-Build
files: time_and_select_module_link_with_libm.patch
keywords: patch
messages: 219813
nosy: Fredrik.Fornwall
priority: normal
severity: normal
status: open
title: The select and time modules uses libm functions without linking against it
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35490/time_and_select_module_link_with_libm.patch

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

From report at bugs.python.org  Thu Jun  5 17:07:19 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 15:07:19 +0000
Subject: [New-bugs-announce] [issue21669] Custom error messages when print &
	exec are used as	statements
Message-ID: <1401980839.06.0.736211179057.issue21669@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I realised my experiment with supporting implicit calls could potentially be used as the basis for a patch that reported more specific error details when "print" and "exec" were used as statements, so I went ahead and updated it to do so.

The initial patch has a failure in test_source_encoding - this appears to be a general issue with moving syntax errors from the parser (which reliably sets the "text" attribute on the raised SyntaxError) to the AST compiler (which sets that to None when running from a string compiled directly from memory rather than from a file on disk).

I've also only flagged this as a patch for 3.5 - I can't think of a way to do it without changing the language grammar to allow the error to be generated in a later stage of the compilation process, and that's not the kind of thing we want to be doing in a maintenance release.

----------
files: custom_builtin_syntax_errors.diff
keywords: patch
messages: 219816
nosy: alex, glyph, gvanrossum, ncoghlan
priority: normal
severity: normal
status: open
title: Custom error messages when print & exec are used as statements
versions: Python 3.5
Added file: http://bugs.python.org/file35491/custom_builtin_syntax_errors.diff

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

From report at bugs.python.org  Thu Jun  5 19:26:57 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 05 Jun 2014 17:26:57 +0000
Subject: [New-bugs-announce] [issue21670] Add repr to shelve.Shelf
Message-ID: <1401989217.73.0.191894123322.issue21670@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello!

Working with Shelf instances in the interactive console is cumbersome because you can't have an instant feedback when running the following:

>>> from shelve import Shelf
>>> s = Shelf({})
>>> s['a'] = 1
>>> s
<shelve.Shelf object at 0x033D0AF0>

This patch adds an useful repr to Shelf objects.

>>> s
Shelf({'a': 1})

Thanks!

----------
components: Library (Lib)
files: shelve.patch
keywords: patch
messages: 219827
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Add repr to shelve.Shelf
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35492/shelve.patch

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

From report at bugs.python.org  Thu Jun  5 19:29:22 2014
From: report at bugs.python.org (Chris Lambacher)
Date: Thu, 05 Jun 2014 17:29:22 +0000
Subject: [New-bugs-announce] [issue21671] CVE-2014-0224: OpenSSL upgrade to
	1.0.1h on Windows	required
Message-ID: <1401989362.0.0.600738846539.issue21671@psf.upfronthosting.co.za>


New submission from Chris Lambacher:

http://www.openssl.org/news/secadv_20140605.txt

All client versions of OpenSSL are vulnerable so all Windows builds of Python are vulnerable to MITM attacks when connecting to vulnerable servers.

----------
components: Build, Windows
messages: 219828
nosy: lambacck
priority: normal
severity: normal
status: open
title: CVE-2014-0224: OpenSSL upgrade to 1.0.1h on Windows required
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun  5 20:54:39 2014
From: report at bugs.python.org (Jacob Blair)
Date: Thu, 05 Jun 2014 18:54:39 +0000
Subject: [New-bugs-announce] [issue21672] Python for Windows 2.7.7: Path
	Configuration File No	Longer Works With UNC Paths
Message-ID: <1401994479.3.0.49246899079.issue21672@psf.upfronthosting.co.za>


New submission from Jacob Blair:

I just upgraded from 2.7.6 to 2.7.7, on Windows, and have encountered different behavior in my path configuration (.pth) files. One of my files had lines similar to these:

\\host\sharefolder

These paths (UNC-style), are not being loaded into sys.path. It is successfully loading path lines from this and other files, so long as they have a drive letter.

----------
messages: 219833
nosy: Jacob.Blair
priority: normal
severity: normal
status: open
title: Python for Windows 2.7.7: Path Configuration File No Longer Works With UNC Paths
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun  5 22:09:58 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Jun 2014 20:09:58 +0000
Subject: [New-bugs-announce] [issue21673] Idle: hilite search terms in hits
	in Find in Files	output window
Message-ID: <1401998998.56.0.521906820097.issue21673@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Example that prompted this idea due to difficulty of scanning results. The code lines are relatively long and the hit range from first to (almost) last word in the line.

Searching 'future' in F:\Python\dev\2\py27\*.c...
...
F:\Python\dev\2\py27\Mac\Modules\cg\CFMLateImport.c: 53: //   future expansion of the APIs for things like CFMLateImportSymbol
F:\Python\dev\2\py27\Modules\_ctypes\libffi\src\dlmalloc.c: 3715:     /* On failure, disable autotrim to avoid repeated failed future calls */
F:\Python\dev\2\py27\Modules\fcntlmodule.c: 235: behavior will change in future releases of Python.\n\
...
Hits found: 130

I presume that is should be easy to tag hits both in first line (instead of marking with '') and the remainder and lightly color all tagged items.

When a test is a added to test_grep, the file should be examines to see what else is still missing in light of the recent addition of an htest.

----------
assignee: terry.reedy
messages: 219842
nosy: sahutd, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: hilite search terms in hits in Find in Files output window
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun  5 22:40:32 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Jun 2014 20:40:32 +0000
Subject: [New-bugs-announce] [issue21674] Idle: Add 'find all' in current
	file
Message-ID: <1402000832.05.0.464293408794.issue21674@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I miss this from Notepad++. This is essentially Find in Files limited to one file, without the file name repeated on each line.
Notepad++ puts multiple findall results in one window, with +- marker to expand or contract a group. It also has findall in all open files, which would use same mechanism. It also highlights hits, as suggested in #21673.

----------
messages: 219844
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: Add 'find all' in current file
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun  6 05:30:32 2014
From: report at bugs.python.org (Anthony Bartoli)
Date: Fri, 06 Jun 2014 03:30:32 +0000
Subject: [New-bugs-announce] [issue21675] Library - Introduction - paragraph
	5 - wrong ordering
Message-ID: <1402025432.44.0.956815380297.issue21675@psf.upfronthosting.co.za>


New submission from Anthony Bartoli:

>From the library's introduction page:

"This manual is organized ?from the inside out:? it first describes the built-in data types..."

The library manual first describes built-in functions, not data types. 

After built-in functions, it describes built-in constants, built-in types, and built-in exceptions. Lastly, it describes modules grouped by related functionality. 

A suggested re-write *for the entire paragraph*:

"The library manual first documents built-in functions, built-in constants, built-in types, and built-in exceptions. Then it documents modules grouped by related functionality. 

I suggest eliminating the last sentence:

"The ordering of the chapters as well as the ordering of the modules within each chapter is roughly from most relevant to least important."

Importance is subjective and parts of the manual are organized alphabetically, not by relevance / importance.

----------
assignee: docs at python
components: Documentation
messages: 219860
nosy: AnthonyBartoli, docs at python
priority: normal
severity: normal
status: open
title: Library - Introduction - paragraph 5 - wrong ordering
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun  6 08:36:35 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Fri, 06 Jun 2014 06:36:35 +0000
Subject: [New-bugs-announce] [issue21676] IDLE - Test Replace Dialog
Message-ID: <1402036595.31.0.93623743551.issue21676@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Add unittest for idlelib's replace dialog.
7 lines related to replacedialog logic could not be tested. Any input on how to test those lines?

Running the test suite for idlelib emits:
"ttk::ThemeChanged"
invalid command name "3069198412callit"
    while executing
"3069198412callit"
    ("after" script)
invalid command name "3051229868callit"
    while executing
"3051229868callit"
    ("after" script), 

though the tests pass. 


If this is fine, will post a 2.7 backport.

----------
components: IDLE
files: test-replace-34.diff
keywords: patch
messages: 219863
nosy: jesstess, sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - Test Replace Dialog
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35493/test-replace-34.diff

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

From report at bugs.python.org  Fri Jun  6 08:49:21 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 06 Jun 2014 06:49:21 +0000
Subject: [New-bugs-announce] [issue21677] Exception context set to string by
	BufferedWriter.close()
Message-ID: <1402037361.81.0.0432601669782.issue21677@psf.upfronthosting.co.za>


New submission from Martin Panter:

I made a writer class whose write() and flush() methods (unintentionally) triggered exceptions. I wrapped this in a BufferedWriter. When close() is called, the resulting exception has a string object in its __context__ attribute. Although the original error was my fault, it created a confusing chain reaction of exception reports.

>>> from io import BufferedWriter, RawIOBase
>>> import sys
>>> 
>>> class BuggyWriter(RawIOBase):
...     def writable(self): return True
...     def write(self, b): in_write  # Initial exception
...     def flush(self): raise Exception("In flush()")
... 
>>> output = BufferedWriter(BuggyWriter())
>>> output.write(b"data")
4
>>> output.close()  # Note the TypeError printed at the top
TypeError: print_exception(): Exception expected for value, str found

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in flush
Exception: In flush()
>>> 
>>> sys.last_value
Exception('In flush()',)
>>> sys.last_value.__context__  # Should be exception, not string object
"name 'in_write' is not defined"
>>> 
>>> import traceback
>>> traceback.print_exception(sys.last_type, sys.last_value, sys.last_traceback)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/traceback.py", line 169, in print_exception
    for line in _format_exception_iter(etype, value, tb, limit, chain):
  File "/usr/lib/python3.4/traceback.py", line 146, in _format_exception_iter
    for value, tb in values:
  File "/usr/lib/python3.4/traceback.py", line 138, in _iter_chain
    yield from it
  File "/usr/lib/python3.4/traceback.py", line 125, in _iter_chain
    context = exc.__context__
AttributeError: 'str' object has no attribute '__context__'

----------
components: IO
messages: 219864
nosy: vadmium
priority: normal
severity: normal
status: open
title: Exception context set to string by BufferedWriter.close()
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun  6 12:17:45 2014
From: report at bugs.python.org (=?utf-8?b?0JzQuNGF0LDQuNC7INCc0LjRiNCw0LrQuNC9?=)
Date: Fri, 06 Jun 2014 10:17:45 +0000
Subject: [New-bugs-announce] [issue21678] Add operation "plus" for
	dictionaries
Message-ID: <1402049865.6.0.54047766444.issue21678@psf.upfronthosting.co.za>


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

First of all, i'm sorry for my English :)

I would like to union dictionaries with operator + (and +=) like this:

>>> dict(a=1, b=2) + {'a': 10, 'c': 30}
{'a': 10, 'b': 2, 'c': 30}

>>> d = dict(a=1, b=2, c={'c1': 3, 'c2': 4})
>>> d += dict(a=10, c={'c1':30})
>>> d
{'a': 10, 'b': 2, c: {'c1':30}}


Also, it gives an easy way to modify and extend the class attributes:

class Super:
   params = {
       'name': 'John',
       'surname': 'Doe',
   }

class Sub(Super):
   params = Super.params + {
       'surname': 'Show',
       'age': 32,
   }

----------
components: Interpreter Core
messages: 219867
nosy: Pix
priority: normal
severity: normal
status: open
title: Add operation "plus" for dictionaries
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun  6 13:48:05 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Fri, 06 Jun 2014 11:48:05 +0000
Subject: [New-bugs-announce] [issue21679] Prevent extraneous fstat during
	open()
Message-ID: <1402055285.47.0.764387439948.issue21679@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

Hi,
with Python 3.3/3.4, I noticed that there are lots of syscalls on open() - I noticed 2x fstat, 2x ioctl and 2x lseek. This is not noticable when working with small amounts of files on local filesystem, but if working with files via NSF or if working with huge amounts of files, lots of syscalls cost a lot of time. Therefore I'd like to create patches that would reduce the number of syscalls on open().
I've already managed to create first one (attached), that gets rid of one of the fstat calls (all the information are obtained from one fstat call).
I hope this makes sense and that the patch is acceptable. If not, I'll be happy to work on it to make it better. (This is my first real patch for C part of Python, so I hope I did everything right...)

----------
components: IO
files: python3-remove-extraneous-fstat-on-file-open.patch
keywords: patch
messages: 219874
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Prevent extraneous fstat during open()
type: resource usage
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35494/python3-remove-extraneous-fstat-on-file-open.patch

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

From report at bugs.python.org  Fri Jun  6 14:41:35 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 12:41:35 +0000
Subject: [New-bugs-announce] [issue21680] asyncio: document event loops
Message-ID: <1402058495.48.0.977334805226.issue21680@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, the different implementations of asyncio event loop are not listed in the documentation. But they are mentionned in some places, like in the subprocess section to mention that Proactor doesn't support subprocess or that they are issues with Kqueue on old Mac OS X versions.

It would be useful to mention at least the name of each event loop.

Each event loop has specific features or different limitations. See for example the issue #21437 which asks to mention that the proactor event loop doesn't support SSL.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 219878
nosy: docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: document event loops
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun  6 22:25:14 2014
From: report at bugs.python.org (larkost)
Date: Fri, 06 Jun 2014 20:25:14 +0000
Subject: [New-bugs-announce] [issue21681] version string printed on STDERR
Message-ID: <1402086314.99.0.941367169279.issue21681@psf.upfronthosting.co.za>


New submission from larkost:

When getting the version of the Python interpreter with `python --version` the output is going to STDERR rather than STDOUT. This is non-standard behavior, and is surprising.

For example I was writing a dependency into a makefile, and this behavior caused me a good 5 minutes of debugging my script before I realized it was bad behavior on the command line.

----------
messages: 219896
nosy: larkost
priority: normal
severity: normal
status: open
title: version string printed on STDERR
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun  7 06:55:18 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 07 Jun 2014 04:55:18 +0000
Subject: [New-bugs-announce] [issue21682] Refleak in idle_test
	test_autocomplete
Message-ID: <1402116918.55.0.530406821605.issue21682@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The recently added test_autocomplete seems to be hanging onto a reference somewhere that it shouldn't be, see below.  This output was obtained by running `python -m test -R :: -uall test_idle`.  I tracked it down to test_autocomplete with hg bisect, and proved it by running the same test with test_autocomplete deleted. This refleak also causes extra scary-looking output when running other GUI tests, see http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8412/steps/test/logs/stdio (look for test_tk).

[1/1] test_idle
beginning 9 repetitions
123456789
warning: callback failed in WindowList <class '_tkinter.TclError'> : invalid command name ".140195409867984.windows"
...
<repeat ad nauseum>
...
warning: callback failed in WindowList <class '_tkinter.TclError'> : invalid command name ".140195377829800.windows"
.
test_idle leaked [6411, 6411, 6411, 6411] references, sum=25644
test_idle leaked [5150, 5153, 5152, 5152] memory blocks, sum=20607
1 test failed:
    test_idle

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 219914
nosy: sahutd, terry.reedy, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Refleak in idle_test test_autocomplete
type: resource usage
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun  7 07:05:12 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 07 Jun 2014 05:05:12 +0000
Subject: [New-bugs-announce] [issue21683] Add Tix to the Windows buildbot
	scripts
Message-ID: <1402117512.69.0.59005429213.issue21683@psf.upfronthosting.co.za>


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


----------
assignee: zach.ware
components: Build, Tkinter, Windows
nosy: steve.dower, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Add Tix to the Windows buildbot scripts
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Sat Jun  7 07:10:48 2014
From: report at bugs.python.org (Ryan McCampbell)
Date: Sat, 07 Jun 2014 05:10:48 +0000
Subject: [New-bugs-announce] [issue21684] inspect.signature bind doesn't
	include defaults or empty	tuple/dicts
Message-ID: <1402117848.15.0.331618951416.issue21684@psf.upfronthosting.co.za>


New submission from Ryan McCampbell:

I'm not sure if this is really a bug, but it is unexpected behavior. When you call "bind" on a Python 3.3 signature object, if you omit an optional argument, the default is not provided in the arguments dict. Similarly, if there is a "var positional" or "var keyword" parameter but there are no extra arguments, it will not be included. To emulate the effect on the namespace of an actual function, I would expect these to be included, as an empty tuple/dict in the case of variable arguments. I realize the current behavior may be useful in some cases, but if so, then another method could be added: bind_full, which would include all parameters of the signature.

----------
messages: 219916
nosy: rmccampbell7
priority: normal
severity: normal
status: open
title: inspect.signature bind doesn't include defaults or empty tuple/dicts
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Jun  7 15:02:05 2014
From: report at bugs.python.org (Raimondo Giammanco)
Date: Sat, 07 Jun 2014 13:02:05 +0000
Subject: [New-bugs-announce] [issue21685] zipfile module doesn't properly
	compress odt documents
Message-ID: <1402146125.06.0.0023086764998.issue21685@psf.upfronthosting.co.za>


New submission from Raimondo Giammanco:

Steps to reproduce
??????????????????
-1- Create a document.odt containing an input (text) field and a conditional text field; the latter will show a different text based upon the content of the input text field. [use attached example.odt]
-2- Edit the file by means of following code

from zipfile import ZipFile, ZIP_DEFLATED
document = '/tmp/example.odt'                     # SET ME PLEASE
S2b, R2b = 'SUBST'.encode(), 'REPLACEMENT'.encode()
with ZipFile(document,'a', ZIP_DEFLATED) as z:
	xmlString = z.read('content.xml')
	xmlString = xmlString.replace(S2b, R2b)
	z.writestr('content.xml', xmlString)

-3- Open example.odt with *office

As `REPLACEMENT' is the requested string, one expect to see the relevant conditional text
What happens: the LO function doesn't recognize the string, unless one do not retype it manually

Omitting ZIP_DEFLATED parameter prevents this behaviour from happen (so letting zipfile use the default no-compression method) 


tested on
Python 2.7.3 and Python 3.2.3
Ubuntu 12.04 amd64
LibreOffice Version 4.0.4.2

----------
components: Library (Lib)
files: example.odt
messages: 219933
nosy: rai
priority: normal
severity: normal
status: open
title: zipfile module doesn't properly compress odt documents
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file35511/example.odt

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

From report at bugs.python.org  Sat Jun  7 17:01:54 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sat, 07 Jun 2014 15:01:54 +0000
Subject: [New-bugs-announce] [issue21686] IDLE - Test hyperparser
Message-ID: <1402153314.44.0.426576210732.issue21686@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Test for idlelib.HyperParser
5 lines not tested. Any suggestion on how to hit those lines welcome.
Will submit backport 2.7 once the patch for 3.4 is OK.

----------
components: IDLE
files: test-hyperparser.diff
keywords: patch
messages: 219942
nosy: jesstess, sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - Test hyperparser
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35512/test-hyperparser.diff

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

From report at bugs.python.org  Sat Jun  7 17:18:12 2014
From: report at bugs.python.org (Florian Walch)
Date: Sat, 07 Jun 2014 15:18:12 +0000
Subject: [New-bugs-announce] [issue21687] Py_SetPath: Path components
	separated by colons
Message-ID: <1402154292.52.0.48898043171.issue21687@psf.upfronthosting.co.za>


New submission from Florian Walch:

The documentation for Py_SetPath [1] states:

> The path components should be separated by semicolons.

I believe this should not say "semicolons", but "colons"; the default path as output by Py_GetPath is separated by colons.

[1] https://docs.python.org/3/c-api/init.html#c.Py_SetPath

----------
assignee: docs at python
components: Documentation
messages: 219944
nosy: docs at python, fwalch
priority: normal
severity: normal
status: open
title: Py_SetPath: Path components separated by colons
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun  7 21:15:03 2014
From: report at bugs.python.org (Olive Kilburn)
Date: Sat, 07 Jun 2014 19:15:03 +0000
Subject: [New-bugs-announce] [issue21688] Improved error msg for make.bat
	htmlhelp
Message-ID: <1402168503.61.0.753508376392.issue21688@psf.upfronthosting.co.za>


New submission from Olive Kilburn:

Currently if someone runs make.bat htmlhelp without first installing Htmlhelp Workshop, it outputs: 
c:\program not a valid . . . .

This isn't very informative if you don't know you need Htmlhelp Workshop. The included patch has make.bat give a more helpful message. If this isn't a good fix(?), I could try clarifying the readme instead.

----------
components: Windows
files: mywork.patch
keywords: patch
messages: 219961
nosy: Olive.Kilburn
priority: normal
severity: normal
status: open
title: Improved error msg for make.bat htmlhelp
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35518/mywork.patch

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

From report at bugs.python.org  Sat Jun  7 21:48:22 2014
From: report at bugs.python.org (Yuly Tenorio)
Date: Sat, 07 Jun 2014 19:48:22 +0000
Subject: [New-bugs-announce] [issue21689] Docs for "Using Python on a
	Macintosh" needs to be	updated.
Message-ID: <1402170502.2.0.981560752161.issue21689@psf.upfronthosting.co.za>


New submission from Yuly Tenorio:

"Using Python on a Mac" needs updating since it is pointing to old tools and documentation.

This is related to http://bugs.python.org/issue12594

----------
assignee: docs at python
components: Documentation
messages: 219968
nosy: docs at python, ned.deily, yuly
priority: normal
severity: normal
status: open
title: Docs for "Using Python on a Macintosh" needs to be updated.
versions: Python 3.5

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

From report at bugs.python.org  Sun Jun  8 01:25:03 2014
From: report at bugs.python.org (Julian Gilbey)
Date: Sat, 07 Jun 2014 23:25:03 +0000
Subject: [New-bugs-announce] [issue21690] re documentation: re.compile links
	to re.search /	re.match instead of regex.search / regex.match
Message-ID: <1402183503.23.0.87974807547.issue21690@psf.upfronthosting.co.za>


New submission from Julian Gilbey:

In re.rst, the re.compile documentation says:

   Compile a regular expression pattern into a regular expression object, which
   can be used for matching using its :func:`match` and :func:`search` methods,
   described below.

This results in linking to the re.match and re.search module functions instead of the regex.match and regex.search object methods.  I'm not sure what the correct replacement syntax is, presumably something like :meth:`~regex.match` and :meth:`~regex.search`.

----------
assignee: docs at python
components: Documentation
messages: 219997
nosy: docs at python, jdg
priority: normal
severity: normal
status: open
title: re documentation: re.compile links to re.search / re.match instead of regex.search / regex.match
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  8 08:42:09 2014
From: report at bugs.python.org (Jackson Cooper)
Date: Sun, 08 Jun 2014 06:42:09 +0000
Subject: [New-bugs-announce] [issue21691] set() returns random output with
	Python 3.4.1, in non-interactive mode
Message-ID: <1402209729.83.0.684576336289.issue21691@psf.upfronthosting.co.za>


New submission from Jackson Cooper:

The set() built-in returns random output, only when Python 3 is being used, and in non-interactive mode (executing a file).

Steps to reproduce:

1. Create file with only print(set(['A', 'B'])) inside it.

2. Execute file with Python 3.4.1 numerous times (10+) over 10+ seconds. The output will vary (randomly?) between {'B', 'A'} and {'A', 'B'}.


I can only reproduce this with Python 3.4.1 (have not tried 3.5). It cannot be reproduced in Python 2 (2.7.6) interactive or non-interactive mode, or Python 3.4.1 in interactive mode. Only in Python 3 when executing a file.


Tested on OS X 10.9.3, Python installed via Homebrew.

----------
components: Interpreter Core
messages: 220021
nosy: Jackson.Cooper
priority: normal
severity: normal
status: open
title: set() returns random output with Python 3.4.1, in non-interactive mode
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  8 09:37:07 2014
From: report at bugs.python.org (Fei Long Wang)
Date: Sun, 08 Jun 2014 07:37:07 +0000
Subject: [New-bugs-announce] [issue21692] Wrong order of expected/actual
	for	assert_called_once_with
Message-ID: <1402213027.91.0.0664386594631.issue21692@psf.upfronthosting.co.za>


New submission from Fei Long Wang:

>>> m=mock.Mock()
>>> m.some_method('foo', 'bar')
<Mock name='mock.some_method()' id='140353787504656'>
>>> m.some_method.assert_called_once_with('foo', 'bar')
>>> m.some_method.assert_called_once_with('foo', 'baz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/mock.py", line 846, in assert_called_once_with
    return self.assert_called_with(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/mock.py", line 835, in assert_called_with
    raise AssertionError(msg)
AssertionError: Expected call: some_method('foo', 'baz')   #####
Actual call: some_method('foo', 'bar')                     #####
>>>

----------
components: Tests
messages: 220025
nosy: flwang
priority: normal
severity: normal
status: open
title: Wrong order of expected/actual for assert_called_once_with
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  8 10:17:44 2014
From: report at bugs.python.org (Yann Lebel)
Date: Sun, 08 Jun 2014 08:17:44 +0000
Subject: [New-bugs-announce] [issue21693] Broken link to Pylons in the HOWTO
	TurboGears	documentation
Message-ID: <1402215464.69.0.795640420868.issue21693@psf.upfronthosting.co.za>


New submission from Yann Lebel:

The link to the Pylons framework present at the end of theHOWTO -> HOWTO Use Python in the web -> TurboGears documentation section redirect to a domain that does not exists anymore.

I believe it should be replaced by http://www.pylonsproject.org/

Here is the link to the documentation section
https://docs.python.org/3/howto/webservers.html#turbogears

----------
assignee: docs at python
components: Documentation
messages: 220027
nosy: Yann.Lebel, docs at python
priority: normal
severity: normal
status: open
title: Broken link to Pylons in the HOWTO TurboGears documentation
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Jun  8 15:31:25 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sun, 08 Jun 2014 13:31:25 +0000
Subject: [New-bugs-announce] [issue21694] IDLE - Test ParenMatch
Message-ID: <1402234285.47.0.734954063867.issue21694@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Adding test for idlelib.ParenMatch for 3.4
Will backport to 2.7 when this patch is OK.
3 lines could not be tested in this patch.

----------
components: IDLE
files: test-parenmatch.diff
keywords: patch
messages: 220034
nosy: jesstess, sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - Test ParenMatch
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35536/test-parenmatch.diff

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

From report at bugs.python.org  Sun Jun  8 21:57:39 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 Jun 2014 19:57:39 +0000
Subject: [New-bugs-announce] [issue21695] Idle 3.4.1-: closing Find in Files
	while in progress	closes Idle
Message-ID: <1402257459.19.0.652295391424.issue21695@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Reproducer: On Windows, Open Idle and editor. In editor grep (alt-f3), for instance, 'print' in /Lib/*.py. While hits are flashing by, close the output window with [x]

2.7.6 or .7: Output window closes, Idle continues as desired.
3.3.5 or 3.4.1: All Idle windows - shell, editor, output
3.4.1+, 3.5.0a, debug builds run from console interpreter:
Output window closes, Idle continues, as desired.
console window displays exception ending with 

  File "F:\Python\dev\5\py35\lib\idlelib\GrepDialog.py", line 90, in grep_it
    (fn, lineno, line))
  File "F:\Python\dev\5\py35\lib\idlelib\OutputWindow.py", line 40, in write
    self.text.insert(mark, s, tags)
AttributeError: 'NoneType' object has no attribute 'insert'

The specific fix is to wrap the text insert with try: except: break. The immediate mystery  is why 2.7 did not shutdown with nowhere to print the traceback.

----------
assignee: terry.reedy
messages: 220052
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle 3.4.1-: closing Find in Files while in progress closes Idle
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  8 22:11:35 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 Jun 2014 20:11:35 +0000
Subject: [New-bugs-announce] [issue21696] Idle: test syntax of configuration
	files
Message-ID: <1402258295.62.0.994323894939.issue21696@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Spinoff of #12274 and a dependency thereof: new test_configurations.py should statically test that configparser, called from idlelib.configHandler, can process all the configuration.def files without error.

----------
assignee: terry.reedy
messages: 220053
nosy: sahutd, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: test syntax of configuration files
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun  9 15:19:19 2014
From: report at bugs.python.org (Shajunxing)
Date: Mon, 09 Jun 2014 13:19:19 +0000
Subject: [New-bugs-announce] [issue21697] shutil.copytree() handles symbolic
	directory incorrectly
Message-ID: <1402319959.34.0.00412025295877.issue21697@psf.upfronthosting.co.za>


New submission from Shajunxing:

While using shutil.copytree() and the source containing symbolic directory (not symbolic file), an error will be raised. I checked the source code and found an obvlous mistake: shutil.copytree() using os.path.islink() to checker whether the source is a symbolic link, it's okay, but after doing this, os.path.isdir() should be called because a symbolic link may either be a file or a directry, shutil.copytree() just treated all of them as file, and invoke copy_function to copy it, so error happens.

I don't know whether newer versions have fixed this bug, but I googled it and found nothing.

----------
components: Library (Lib)
files: ?? - 2014?06?09? - 21?14?13?.png
messages: 220088
nosy: shajunxing
priority: normal
severity: normal
status: open
title: shutil.copytree() handles symbolic directory incorrectly
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file35541/?? - 2014?06?09? - 21?14?13?.png

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

From report at bugs.python.org  Mon Jun  9 15:41:34 2014
From: report at bugs.python.org (Aviv Avital)
Date: Mon, 09 Jun 2014 13:41:34 +0000
Subject: [New-bugs-announce] [issue21698] Platform.win32_ver() shows
	different values than	expected on Windows 8.1
Message-ID: <1402321294.86.0.565487157603.issue21698@psf.upfronthosting.co.za>


New submission from Aviv Avital:

On Windows 8.1, win32_ver() returns a Windows 8 version number:

C:\>\Python27\python.exe
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.win32_ver()
('8', '6.2.9200', '', 'Multiprocessor Free')
>>> quit()

C:\>ver

Microsoft Windows [Version 6.3.9600]

C:\>

----------
components: Windows
messages: 220089
nosy: AvivAvital
priority: normal
severity: normal
status: open
title: Platform.win32_ver() shows different values than expected on Windows 8.1
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun  9 16:54:27 2014
From: report at bugs.python.org (Justin Engel)
Date: Mon, 09 Jun 2014 14:54:27 +0000
Subject: [New-bugs-announce] [issue21699] Windows Python 3.4.1 pyvenv
	doesn't work in directories	with spaces.
Message-ID: <1402325667.24.0.414585735491.issue21699@psf.upfronthosting.co.za>


New submission from Justin Engel:

Venv virtual environments don't work with spaces in the path.

(env) C:\My Directory\path > pip -V
Fatal error in launcher: Unable to create process using '""C:\My Directory\path\env\Scripts\python.exe"" "C:\My Directory\path\env\Scripts\pip.exe" -V'

----------
components: Windows
messages: 220098
nosy: Justin.Engel
priority: normal
severity: normal
status: open
title: Windows Python 3.4.1 pyvenv doesn't work in directories with spaces.
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Tue Jun 10 02:19:34 2014
From: report at bugs.python.org (Allen Riddell)
Date: Tue, 10 Jun 2014 00:19:34 +0000
Subject: [New-bugs-announce] [issue21700] Missing mention of
	DatagramProtocol having	connection_made and connection_lost methods
Message-ID: <1402359574.1.0.968660255801.issue21700@psf.upfronthosting.co.za>


New submission from Allen Riddell:

The following important information from PEP 3156 does not appear in the asyncio library documentation:

"""Datagram protocols have connection_made() and connection_lost() methods with the same signatures as stream protocols."""

Indeed, reading the docs it looks like only ``Protocol`` and ``SubprocessProtocol`` have these methods. (See https://docs.python.org/3.4/library/asyncio-protocol.html#connection-callbacks)

The quick fix is to change the lines 275-276 in ``Doc/library/asyncio-protocol.rst`` from:

    These callbacks may be called on Protocol and SubprocessProtocol instances:

to

    These callbacks may be called on Protocol, DatagramProtocol, and SubprocessProtocol instances:

----------
assignee: docs at python
components: Documentation, asyncio
messages: 220130
nosy: ariddell, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Missing mention of DatagramProtocol having connection_made and connection_lost methods
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 02:38:56 2014
From: report at bugs.python.org (Allen Riddell)
Date: Tue, 10 Jun 2014 00:38:56 +0000
Subject: [New-bugs-announce] [issue21701] create_datagram_endpoint does not
	receive when both	local_addr and remote_addr provided
Message-ID: <1402360736.4.0.184657566107.issue21701@psf.upfronthosting.co.za>


New submission from Allen Riddell:

Creating a UDP connection through ``create_datagram_endpoint`` when specifying both remote_addr and local_addr does not work; messages are not received. If remote_addr is removed, messages are received.

Easy to reproduce:

works: python3 client_good.py & python3 sender.py 127.0.0.1 8888
blocks?: python3 client_bad.py & python3 sender.py 127.0.0.1 8888

>From the PEP I gather this really is a bug, since create_datagram_endpoint is supposed to be bidirectional::

    create_datagram_endpoint(protocol_factory, local_addr=None, remote_addr=None, <options>). Creates an endpoint for sending and receiving datagrams (typically UDP packets). Because of the nature of datagram traffic, there are no separate calls to set up client and server side, since usually a single endpoint acts as both client and server.

----------
components: asyncio
messages: 220134
nosy: ariddell, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: create_datagram_endpoint does not receive when both local_addr and remote_addr provided
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 09:35:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Jun 2014 07:35:33 +0000
Subject: [New-bugs-announce] [issue21702] asyncio: remote_addr of
	create_datagram_endpoint() is	not documented
Message-ID: <1402385733.37.0.0697912425381.issue21702@psf.upfronthosting.co.za>


New submission from STINNER Victor:

See issue #21701 for a recent issue about this parameter.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 220147
nosy: ariddell, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: remote_addr of create_datagram_endpoint() is not documented
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 12:08:31 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Tue, 10 Jun 2014 10:08:31 +0000
Subject: [New-bugs-announce] [issue21703] IDLE: Test UndoDelegator
Message-ID: <1402394911.48.0.416868265469.issue21703@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

Adds test for UndoDelegator class in idlelib.UndoDelegator.


With the help of Victor Stinner on IRC, I managed to reduce the refleak, but the current status is:
saimadhav at debian:~/dev/34-cpython$ ./python -m test -R 3:3 -uall test_idle
[1/1] test_idle
beginning 6 repetitions
123456
......
test_idle leaked [237, 237, 237] references, sum=711
test_idle leaked [95, 98, 97] memory blocks, sum=290
1 test failed:
    test_idle

Any hint on where the problem is?
---
I also plan to cover other helper classes in the same UndoDelegator file.

----------
components: IDLE
files: test-undodelegator.diff
keywords: patch
messages: 220158
nosy: jesstess, sahutd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Test UndoDelegator
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35550/test-undodelegator.diff

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

From report at bugs.python.org  Tue Jun 10 12:33:24 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Jun 2014 10:33:24 +0000
Subject: [New-bugs-announce] [issue21704] _multiprocessing module builds
	incorrectly when POSIX	semaphores are disabled
Message-ID: <1402396404.2.0.758262532851.issue21704@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

When POSIX semaphores are disabled (e.g. by unmounting /dev/shm on a Linux system), then _multiprocessing module builds with undefined symbol _PyMp_sem_unlink:

$ ./configure ...
...
checking whether POSIX semaphores are enabled... no
...
$ make
...
building '_multiprocessing' extension
creating build/temp.linux-x86_64-3.5/tmp/cpython/Modules/_multiprocessing
x86_64-pc-linux-gnu-gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -march=core2 -O2 -fno-ident -pipe -ggdb3 -Wall -Wpointer-sign -IModules/_multiprocessing -I./Include -I. -IInclude -I/usr/local/include -I/tmp/cpython/Include -I/tmp/cpython -c /tmp/cpython/Modules/_multiprocessing/multiprocessing.c -o build/temp.linux-x86_64-3.5/tmp/cpython/Modules/_multiprocessing/multiprocessing.o
x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--hash-style=gnu -Wl,--sort-common build/temp.linux-x86_64-3.5/tmp/cpython/Modules/_multiprocessing/multiprocessing.o -L. -L/usr/local/lib -lpython3.5m -o build/lib.linux-x86_64-3.5/_multiprocessing.cpython-35m.so
*** WARNING: renaming "_multiprocessing" since importing it failed: build/lib.linux-x86_64-3.5/_multiprocessing.cpython-35m.so: undefined symbol: _PyMp_sem_unlink
...
Following modules built successfully but were removed because they could not be imported:
_multiprocessing


This problem was introduced in Python 3.4. This problem is absent in older versions of Python.
Potential fix:

--- Modules/_multiprocessing/multiprocessing.c
+++ Modules/_multiprocessing/multiprocessing.c
@@ -129,5 +129,7 @@
     {"send", multiprocessing_send, METH_VARARGS, ""},
 #endif
+#ifndef POSIX_SEMAPHORES_NOT_ENABLED
     {"sem_unlink", _PyMp_sem_unlink, METH_VARARGS, ""},
+#endif
     {NULL}
 };

----------
assignee: sbt
components: Extension Modules
keywords: easy
messages: 220162
nosy: Arfrever, jnoller, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: _multiprocessing module builds incorrectly when POSIX semaphores are disabled
type: compile error
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 13:57:04 2014
From: report at bugs.python.org (Matthias Urlichs)
Date: Tue, 10 Jun 2014 11:57:04 +0000
Subject: [New-bugs-announce] [issue21705] cgi.py: Multipart with more than
	one file is misparsed
Message-ID: <1402401424.17.0.414317354507.issue21705@psf.upfronthosting.co.za>


New submission from Matthias Urlichs:

This code in cgi.py makes no sense whatsoever:

842                 if line.endswith(b"--") and last_line_lfend:
843                     strippedline = line.strip()
844                     if strippedline == next_boundary:
845                         break
846                     if strippedline == last_boundary:
847                         self.done = 1
848                         break

(Pdb) p next_boundary
b'--testdata'
(Pdb) p last_boundary
b'--testdata--'
(Pdb) 

The net effect of this is that parsing a multipart with more than one file in it is impossible, as the first file's reader will gobble up the remainder of the input.

Patch attached.

I guess it's a safe bet that no sane person even uses cgi.py any more, otherwise this would have been discovered a bit sooner.

----------
components: Library (Lib)
files: cgi.patch2
messages: 220164
nosy: smurfix
priority: normal
severity: normal
status: open
title: cgi.py: Multipart with more than one file is misparsed
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35552/cgi.patch2

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

From report at bugs.python.org  Tue Jun 10 16:33:48 2014
From: report at bugs.python.org (Dmitry Korchemny)
Date: Tue, 10 Jun 2014 14:33:48 +0000
Subject: [New-bugs-announce] [issue21706] Add base for enumerations
	(Functional API)
Message-ID: <1402410828.65.0.285347945192.issue21706@psf.upfronthosting.co.za>


New submission from Dmitry Korchemny:

In enum module the functional API for enum creation has the following signature:
Enum(value='NewEnumName', names=<...>, *, module='...', qualname='...', type=<mixed-in class>)

so that the numeration always starts with 1. In some cases it is convenient to start numbering from other base, e.g., 0. It would be of great help to add an additional parameter, say start, to make the following call possible:

Animal = Enum('Animal', 'ant bee cat dog', start = 0)

----------
components: Library (Lib)
messages: 220169
nosy: dkorchem
priority: normal
severity: normal
status: open
title: Add base for enumerations (Functional API)
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun 10 18:59:48 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 10 Jun 2014 16:59:48 +0000
Subject: [New-bugs-announce] [issue21707] modulefinder uses wrong CodeType
	signature in	.replace_paths_in_code()
Message-ID: <1402419588.93.0.311747753061.issue21707@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

Here's the code:

    def replace_paths_in_code(self, co):
        ...
        return types.CodeType(co.co_argcount, co.co_nlocals, co.co_stacksize,
                         co.co_flags, co.co_code, tuple(consts), co.co_names,
                         co.co_varnames, new_filename, co.co_name,
                         co.co_firstlineno, co.co_lnotab,
                         co.co_freevars, co.co_cellvars)

Compare this to the code_new() C API doc string (and code):

code(argcount, kwonlyargcount, nlocals, stacksize, flags, codestring,\n\
      constants, names, varnames, filename, name, firstlineno,\n\
      lnotab[, freevars[, cellvars]])

The kwonlyargcount is missing in the call used in .replace_paths_in_code().


The bug surfaces when trying to use the "-r" option of the freeze.py tool:

Traceback (most recent call last):
  File "freeze.py", line 504, in <module>
    main()
  File "freeze.py", line 357, in main
    mf.import_hook(mod)
  File "/home/lemburg/egenix/projects/PyRun/tmp-3.4-ucs2/lib/python3.4/modulefinder.py", line 123, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "/home/lemburg/egenix/projects/PyRun/tmp-3.4-ucs2/lib/python3.4/modulefinder.py", line 179, in find_head_package
    q = self.import_module(head, qname, parent)
  File "/home/lemburg/egenix/projects/PyRun/tmp-3.4-ucs2/lib/python3.4/modulefinder.py", line 272, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "/home/lemburg/egenix/projects/PyRun/tmp-3.4-ucs2/lib/python3.4/modulefinder.py", line 303, in load_module
    co = self.replace_paths_in_code(co)
  File "/home/lemburg/egenix/projects/PyRun/tmp-3.4-ucs2/lib/python3.4/modulefinder.py", line 569, in replace_paths_in_code
    consts[i] = self.replace_paths_in_code(consts[i])
  File "/home/lemburg/egenix/projects/PyRun/tmp-3.4-ucs2/lib/python3.4/modulefinder.py", line 575, in replace_paths_in_code
    co.co_freevars, co.co_cellvars)
TypeError: an integer is required (got type bytes)

----------
components: Library (Lib)
keywords: 3.4regression
messages: 220174
nosy: lemburg
priority: normal
severity: normal
status: open
title: modulefinder uses wrong CodeType signature in .replace_paths_in_code()
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 20:31:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Jun 2014 18:31:22 +0000
Subject: [New-bugs-announce] [issue21708] Deprecate nonstandard behavior of
	a dumbdbm database
Message-ID: <1402425082.25.0.679069092867.issue21708@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Unlike to other dbm implementations, a dumpdbm database is always opened for update, and will be created if it does not exist.  We can fix this discrepancy and implement common behavior for 'r' and 'w' modes, but this will change current behavior and some deprecation period is needed.

Here is a patch (based on patch by Claudiu Popa, submitted in issue18039), which adds deprecation warnings for cases when current behavior differs from desired: invalid values for the flag parameter (will raise ValueError in future), opening non-existing database in 'r' or 'w' mode (will raise dbm.dumb.error), modifying a database opened for reading only (will raise dbm.dumb.error).

This patch needs approving by other core developer.

----------
assignee: serhiy.storchaka
files: dbm_dumb_deprecations.patch
keywords: patch
messages: 220185
nosy: Claudiu.Popa, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate nonstandard behavior of a dumbdbm database
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35558/dbm_dumb_deprecations.patch

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

From report at bugs.python.org  Tue Jun 10 23:15:54 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 10 Jun 2014 21:15:54 +0000
Subject: [New-bugs-announce] [issue21709] logging.__init__ assumes that
	__file__ is always set
Message-ID: <1402434954.06.0.638044906796.issue21709@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

It is not when freezing the logging package, so any use of the logging package fails:

>>> import logging
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "<pyrun>/importlib/_bootstrap.py", line 2237, in _find_and_load
  File "<pyrun>/importlib/_bootstrap.py", line 2226, in _find_and_load_unlocked
  File "<pyrun>/importlib/_bootstrap.py", line 1200, in _load_unlocked
  File "<pyrun>/importlib/_bootstrap.py", line 1129, in _exec
  File "<pyrun>/importlib/_bootstrap.py", line 1359, in exec_module
  File "<pyrun>/logging/__init__.py", line 61, in <module>
NameError: name '__file__' is not defined

This is the code in question:

#
# _srcfile is used when walking the stack to check when we've got the first
# caller stack frame.
#
if hasattr(sys, 'frozen'): #support for py2exe
    _srcfile = "logging%s__init__%s" % (os.sep, __file__[-4:])
else:
    _srcfile = __file__
_srcfile = os.path.normcase(_srcfile)

Note the special case for py2exe. But this doesn't really help, since frozen modules don't have the __file__ attribute set - at least not when generated with Tools/freeze.

PS: This is with Python 3.4.1.

----------
components: Interpreter Core, Library (Lib)
messages: 220196
nosy: lemburg
priority: normal
severity: normal
status: open
title: logging.__init__ assumes that __file__ is always set
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 23:42:43 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Jun 2014 21:42:43 +0000
Subject: [New-bugs-announce] [issue21710] --install-base option ignored?
Message-ID: <1402436563.61.0.260081261103.issue21710@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Looking at the source code in distutils.command.installer, it seems the "--install-base" option is ignored, since it is always overwritten, either in finalize_unix() or finalize_other().

(I haven't tried to check this on the command line, though)

----------
components: Distutils
messages: 220198
nosy: dstufft, eric.araujo, pitrou
priority: normal
severity: normal
status: open
title: --install-base option ignored?
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 11 01:44:40 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Jun 2014 23:44:40 +0000
Subject: [New-bugs-announce] [issue21711] Remove site-python support
Message-ID: <1402443880.3.0.886819561935.issue21711@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Support for "site-python" directories in site.py was deprecated in 3.4 and slated for removal in 3.5. Attached patch does the remove.

----------
components: Library (Lib)
files: sitepython.patch
keywords: patch
messages: 220214
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Remove site-python support
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35561/sitepython.patch

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

From report at bugs.python.org  Wed Jun 11 03:23:56 2014
From: report at bugs.python.org (Pablo Acosta)
Date: Wed, 11 Jun 2014 01:23:56 +0000
Subject: [New-bugs-announce] [issue21712] fractions.gcd failure
Message-ID: <1402449836.52.0.701887741943.issue21712@psf.upfronthosting.co.za>


New submission from Pablo Acosta:

The Greatest Common Divisor (gcd) algorithm sometimes breaks because the modulo operation does not always return a strict integer number, but one very, very close to one. This is enough to drive the algorithm astray from that point on.

Example:

>> import fractions
>> fractions.gcd(48, 18)
>> 6

Which is corret, but:

>> fractions.gcd(2.7, 107.3)
>> 8.881784197001252e-16

when the answer should be 1. The fix seems simple, just cast the mod() operation in the algorithm:

while b:
   a, b = b, int(a%b)
return a

----------
components: Library (Lib)
messages: 220221
nosy: pacosta
priority: normal
severity: normal
status: open
title: fractions.gcd failure
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 11 03:37:15 2014
From: report at bugs.python.org (Joseph Shen)
Date: Wed, 11 Jun 2014 01:37:15 +0000
Subject: [New-bugs-announce] [issue21713] a mistype comment in PC/pyconfig.h
Message-ID: <1402450635.04.0.57326220333.issue21713@psf.upfronthosting.co.za>


New submission from Joseph Shen:

in the source file PC/pyconfig.h at line 393 there is a mistype

this is the origin file
==========================================================================
/* VC 7.1 has them and VC 6.0 does not.  VC 6.0 has a version number of 1200.
   Microsoft eMbedded Visual C++ 4.0 has a version number of 1201 and doesn't
   define these.
   If some compiler does not provide them, modify the #if appropriately. */
#if defined(_MSC_VER)
#if _MSC_VER > 1300
#define HAVE_UINTPTR_T 1
#define HAVE_INTPTR_T 1
#else
/* VC6, VS 2002 and eVC4 don't support the C99 LL suffix for 64-bit integer literals */
#define Py_LL(x) x##I64
#endif  /* _MSC_VER > 1200  */
#endif  /* _MSC_VER */

#endif

==========================================================================
>>> #endif /* _MSC_VER > 1200 */
should be
<<< #endif /* _MSC_VER > 1300 */
or left empty

----------
components: Windows
messages: 220223
nosy: Joseph.Shen
priority: normal
severity: normal
status: open
title: a mistype comment in PC/pyconfig.h
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 11 07:39:26 2014
From: report at bugs.python.org (Antony Lee)
Date: Wed, 11 Jun 2014 05:39:26 +0000
Subject: [New-bugs-announce] [issue21714] Path.with_name can construct
	invalid paths
Message-ID: <1402465166.82.0.496470455769.issue21714@psf.upfronthosting.co.za>


New submission from Antony Lee:

Path.with_name can be used to construct paths containing slashes as name contents (rather than as separators), as demonstrated below.

$ python -c 'from pathlib import Path; print(Path("foo").with_name("bar/baz").name)'
bar/baz

This should be changed to either raise a ValueError, or behave like path.parent / new_name.  Given the amount of checking in the related with_suffix method (and the fact that the second option can be readily implemented by hand), the first option seems preferable.

----------
components: Library (Lib)
messages: 220235
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Path.with_name can construct invalid paths
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 11 08:15:47 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Jun 2014 06:15:47 +0000
Subject: [New-bugs-announce] [issue21715] Chaining exceptions at C level
Message-ID: <1402467347.27.0.18744234848.issue21715@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch introduces new private function which chains previously fetched and current exceptions. This will help in correct implementing at C level an equivalent of following Python idioms:

    try:
        ...
    finally:
        ...

and

    try:
        ...
    except:
        ...
        raise

----------
components: Interpreter Core
messages: 220236
nosy: benjamin.peterson, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Chaining exceptions at C level
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 11 09:32:21 2014
From: report at bugs.python.org (grossdm)
Date: Wed, 11 Jun 2014 07:32:21 +0000
Subject: [New-bugs-announce] [issue21716] 3.4.1 download page link for
	OpenPGP signatures has no	sigs
Message-ID: <1402471941.15.0.562302900324.issue21716@psf.upfronthosting.co.za>


Changes by grossdm <Me at DouglasMGross.com>:


----------
components: Windows
nosy: grossdm
priority: normal
severity: normal
status: open
title: 3.4.1 download page link for OpenPGP signatures has no sigs
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 11 12:26:20 2014
From: report at bugs.python.org (Antony Lee)
Date: Wed, 11 Jun 2014 10:26:20 +0000
Subject: [New-bugs-announce] [issue21717] Exclusive mode for ZipFile and
	TarFile
Message-ID: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za>


New submission from Antony Lee:

I noticed that while lzma and bz2 already support the "x" (create a new file, raise if it already exists) flag, zipfile and tarfile don't know about it yet.  It would be an useful addition, just as it is useful for regular open.

A quick look at both modules show that this likely only requires a little bit more than updating the checks in the corresponding constructors to allow "x" mode, as the modes are passed (nearly) transparently to the open() builtin.

----------
components: Library (Lib)
messages: 220249
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Exclusive mode for ZipFile and TarFile
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 11 15:11:09 2014
From: report at bugs.python.org (mike bayer)
Date: Wed, 11 Jun 2014 13:11:09 +0000
Subject: [New-bugs-announce] [issue21718] sqlite3 cursor.description seems
	to rely on incomplete	statement parsing for detection
Message-ID: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za>


New submission from mike bayer:

Per DBAPI and pysqlite docs, .description must be available for any SELECT statement regardless of whether or not rows are returned.  However, this fails for SELECT statements that aren't simple "SELECT"s, such as those that use CTEs and therefore start out with "WITH:":

import sqlite3
conn = sqlite3.connect(":memory:")

cursor = conn.cursor()
cursor.execute("""
    create table foo (id integer primary key, data varchar(20))
""")

cursor.execute("""
    insert into foo (id, data) values (10, 'ten')
""")

cursor.execute("""
    with bar as (select * from foo)
    select * from bar where id = 10
""")

assert cursor.description is not None


cursor.execute("""
    with bar as (select * from foo)
    select * from bar where id = 11
""")

assert cursor.description is not None


the second statement returns no rows and cursor.description is None.   Libraries like SQLAlchemy which rely on this to determine that the statement supports fetchone() and similar are blocked.

----------
components: Library (Lib)
messages: 220263
nosy: zzzeek
priority: normal
severity: normal
status: open
title: sqlite3 cursor.description seems to rely on incomplete statement parsing for detection
type: behavior

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

From report at bugs.python.org  Wed Jun 11 15:22:41 2014
From: report at bugs.python.org (Ben Hoyt)
Date: Wed, 11 Jun 2014 13:22:41 +0000
Subject: [New-bugs-announce] [issue21719] Returning Windows file attribute
	information via	os.stat()
Message-ID: <1402492961.56.0.590714525359.issue21719@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

I asked recently on python-dev [1] about adding a "st_winattrs" attribute to stat result objects on Windows, to return the full set of Windows file attribute bits, such as "hidden" or "compressed" status. Copying from that thread for a bit more context here:

Python's os.stat() simply discards most of the file attribute
information fetched via the Win32 system calls. On Windows, os.stat()
calls CreateFile to open the file and get the dwFileAttributes value,
but it throws it all away except the FILE_ATTRIBUTE_DIRECTORY and
FILE_ATTRIBUTE_READONLY bits. See CPython source at [2].

Given that os.stat() returns extended, platform-specific file
attributes on Linux and OS X platforms (for example,
st_blocks, st_rsize, etc), it seems that Windows is something of a
second-class citizen here.

There are several questions on StackOverflow about how to get this
information on Windows, and one has to resort to ctypes. For example,
[3].

To solve this problem, I think we should add a "st_winattrs" attribute to the object returned by os.stat() on
Windows. And we should add the relevant Win32 FILE_ATTRIBUTE_* constants to the "stat" module.

Then, similarly to existing code like hasattr(st, 'st_blocks') on
Linux, you could write a cross-platform function to determine if a
file was hidden, something like so:

    def is_hidden(path):
        if startswith(os.path.basename(path), '.'):
            return True
        st = os.stat(path)
        return getattr(st, 'st_winattrs', 0) & FILE_ATTRIBUTE_HIDDEN != 0

There was general support for this idea on python-dev (see [4] [5] [6]), so I'd love to see this in Python 3.5.

Basically we need to add a "st_winattrs" integer attribute to the win32_stat struct in posixmodule.c and add the FILE_ATTRIBUTE_* constants to _stat.c, as well as adding Windows-specific tests and documentation.

I've never compiled CPython on Windows, but I aim to provide a patch for this at some stage soonish. Feedback and other patches welcome in the meantime. :-)

[1] https://mail.python.org/pipermail/python-dev/2014-June/134990.html
[2] https://github.com/python/cpython/blob/master/Modules/posixmodule.c#L1462
[3] http://stackoverflow.com/a/6365265
[4] https://mail.python.org/pipermail/python-dev/2014-June/134993.html
[5] https://mail.python.org/pipermail/python-dev/2014-June/135006.html
[6] https://mail.python.org/pipermail/python-dev/2014-June/135007.html

----------
components: Library (Lib)
messages: 220266
nosy: benhoyt, ethan.furman, zach.ware
priority: normal
severity: normal
status: open
title: Returning Windows file attribute information via os.stat()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 11 15:28:45 2014
From: report at bugs.python.org (David Szotten)
Date: Wed, 11 Jun 2014 13:28:45 +0000
Subject: [New-bugs-announce] [issue21720] "TypeError: Item in ``from list''
	not a string" message
Message-ID: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za>


New submission from David Szotten:

```
>>> __import__('fabric.', fromlist=[u'api'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
```

accidentally ended up with something like this via some module that was using `unicode_literals`. stumped me for a second until i realised that my variable was a string, but not `str`. would be nice with a custom error message if this is a unicode string, explicitly mentioning that these must not be unicode or similar

----------
messages: 220267
nosy: davidszotten
priority: normal
severity: normal
status: open
title: "TypeError: Item in ``from list'' not a string"  message
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 11 15:59:08 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 11 Jun 2014 13:59:08 +0000
Subject: [New-bugs-announce] [issue21721] socket.sendfile() should use
	TransmitFile on Windows
Message-ID: <1402495148.15.0.97374147716.issue21721@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is a follow up of issue 17552 which adds a new socket.sendfile() method taking advantage of high-performance os.sendfile() on UNIX.
The same thing could be done for Windows by using TransmitFile:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).aspx

----------
messages: 220270
nosy: akira, asvetlov, christian.heimes, giampaolo.rodola, gvanrossum, josh.rosenberg, josiah.carlson, neologix, pitrou, python-dev, rosslagerwall, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: socket.sendfile() should use TransmitFile on Windows
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 11 17:13:10 2014
From: report at bugs.python.org (Martin Dengler)
Date: Wed, 11 Jun 2014 15:13:10 +0000
Subject: [New-bugs-announce] [issue21722] teach distutils "upload" to exit
	with code != 0 when	error occurs
Message-ID: <1402499590.45.0.853602089567.issue21722@psf.upfronthosting.co.za>


New submission from Martin Dengler:

This patch teaches distutils/command/upload.py to return a non-zero exit code when uploading fails.  Currently a zero error code is returned (specifically, no Exception is raised by upload.run(...)) regardless of the HTTP response from the server or any socket error during that conversation.

Should be applied against tip.

Thanks.

----------
components: Library (Lib)
files: cpython-patch-Lib-distutils-command-upload.py.patch
keywords: patch
messages: 220276
nosy: mdengler
priority: normal
severity: normal
status: open
title: teach distutils "upload" to exit with code != 0 when error occurs
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file35572/cpython-patch-Lib-distutils-command-upload.py.patch

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

From report at bugs.python.org  Wed Jun 11 17:59:54 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 11 Jun 2014 15:59:54 +0000
Subject: [New-bugs-announce] [issue21723] Float maxsize is treated as
	infinity in asyncio.Queue
Message-ID: <1402502394.97.0.183524227653.issue21723@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

import asyncio

loop = asyncio.get_event_loop()
q = asyncio.Queue(maxsize=1.2, loop=loop)
q.put_nowait(1)
q.put_nowait(1)
q.put_nowait(1)
q.put_nowait(1)
q.put_nowait(1)
.... and so on

It seems counter intuitive for my innocent eyes. As comparison with the traditional queue:

import queue
q = queue.Queue(maxsize=1.2)
q.put(1)
q.put(1)
q.put(1) -> blocking

Here is the patch to make the behaviour consistent with its sibling.

----------
components: asyncio
files: asyncio_queue_accept_handles_maxsize.patch
keywords: patch
messages: 220280
nosy: gvanrossum, haypo, vajrasky, yselivanov
priority: normal
severity: normal
status: open
title: Float maxsize is treated as infinity in asyncio.Queue
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35574/asyncio_queue_accept_handles_maxsize.patch

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

From report at bugs.python.org  Wed Jun 11 18:11:44 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Jun 2014 16:11:44 +0000
Subject: [New-bugs-announce] [issue21724] resetwarnings doesn't reset
	warnings registry
Message-ID: <1402503104.19.0.836333157517.issue21724@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

There seems to be no (official) way to reset the warnings registry; in particular, resetwarnings() doesn't reset it. It makes it difficult to get repeatable warning messages, e.g. at the command prompt, because the shortcut path will silence messages which were already emitted, even if the filter have been changed to "always" in-between.

----------
messages: 220282
nosy: brett.cannon, eric.snow, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: resetwarnings doesn't reset warnings registry
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 11 18:42:30 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Jun 2014 16:42:30 +0000
Subject: [New-bugs-announce] [issue21725] RFC 6531 (SMTPUTF8) support in
	smtpd
Message-ID: <1402504950.99.0.486766973248.issue21725@psf.upfronthosting.co.za>


New submission from R. David Murray:

I thought there was already an issue for this, but I can't find it.  This is part of this summer's GSOC work, and involves adding support for the SMTPUTF8 extension to smtpd.

----------
components: email
messages: 220285
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
stage: patch review
status: open
title: RFC 6531 (SMTPUTF8) support in smtpd
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 11 20:30:15 2014
From: report at bugs.python.org (Reid Price)
Date: Wed, 11 Jun 2014 18:30:15 +0000
Subject: [New-bugs-announce] [issue21726] Unnecessary line in documentation
Message-ID: <1402511415.47.0.115494695808.issue21726@psf.upfronthosting.co.za>


New submission from Reid Price:

https://docs.python.org/2/distutils/examples.html#pure-python-distribution-by-package

Chrome on Linux

The last (parenthetical) sentence is not needed.

  "(Again, the empty string in package_dir stands for the current directory.)"

because there is no package_dir option in the example.

<------------ Preceding Text ------------>
  ...

If you have sub-packages, they must be explicitly listed in packages, but any entries in package_dir automatically extend to sub-packages. (In other words, the Distutils does not scan your source tree, trying to figure out which directories correspond to Python packages by looking for __init__.py files.) Thus, if the default layout grows a sub-package:

<root>/
        setup.py
        foobar/
                 __init__.py
                 foo.py
                 bar.py
                 subfoo/
                           __init__.py
                           blah.py
then the corresponding setup script would be

from distutils.core import setup
setup(name='foobar',
      version='1.0',
      packages=['foobar', 'foobar.subfoo'],
      )

(Again, the empty string in package_dir stands for the current directory.)

----------
assignee: docs at python
components: Documentation
messages: 220295
nosy: Reid.Price, docs at python
priority: normal
severity: normal
status: open
title: Unnecessary line in documentation
type: enhancement

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

From report at bugs.python.org  Wed Jun 11 20:46:30 2014
From: report at bugs.python.org (Matt Deacalion Stevens)
Date: Wed, 11 Jun 2014 18:46:30 +0000
Subject: [New-bugs-announce] [issue21727] Ambiguous sentence explaining
	`cycle` in itertools	documentation
Message-ID: <1402512390.39.0.862134165796.issue21727@psf.upfronthosting.co.za>


New submission from Matt Deacalion Stevens:

https://docs.python.org/3.5/library/itertools.html#itertools.cycle

The first sentence sounds a bit ambiguous:
"Make an iterator returning elements from the iterable and saving a copy of each."

Suggestion:
"Make an iterator that returns elements from the iterable and saves a copy of each."

----------
assignee: docs at python
components: Documentation
messages: 220298
nosy: Matt.Deacalion.Stevens, docs at python
priority: normal
severity: normal
status: open
title: Ambiguous sentence explaining `cycle` in itertools documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 00:06:57 2014
From: report at bugs.python.org (Gerrit Holl)
Date: Wed, 11 Jun 2014 22:06:57 +0000
Subject: [New-bugs-announce] [issue21728] Confusing error message when
	initialising type	inheriting object.__init__
Message-ID: <1402524417.59.0.0212668512702.issue21728@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

When I initialise a class that doesn't define its own __init__, but I still pass arguments, the error message is confusing:

>>> class A: pass
... 
>>> A(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object() takes no parameters

Although it is correct that object() takes no parameters, it would be more correct to state that A() does not take any parameters.

----------
components: Interpreter Core
messages: 220313
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: Confusing error message when initialising type inheriting object.__init__
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jun 12 09:24:41 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 12 Jun 2014 07:24:41 +0000
Subject: [New-bugs-announce] [issue21729] Use `with` statement in dbm.dumb
Message-ID: <1402557881.88.0.738004727052.issue21729@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello.

Here's a short patch for dbm.dumb, which uses in various places the `with` statement for opening and closing files. Thanks.

----------
components: Library (Lib)
files: dbm_with_open.patch
keywords: patch
messages: 220335
nosy: Claudiu.Popa, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use `with` statement in dbm.dumb
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35588/dbm_with_open.patch

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

From report at bugs.python.org  Thu Jun 12 13:01:34 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Jun 2014 11:01:34 +0000
Subject: [New-bugs-announce] [issue21730] test_socket fails --without-threads
Message-ID: <1402570894.28.0.35798335982.issue21730@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Here's the traceback (tested on Ubuntu 12.04):

======================================================================
ERROR: testBCM (test.test_socket.CANTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython-default/Lib/test/test_socket.py", line 231, in _setUp
    self.server_ready = threading.Event()
AttributeError: 'NoneType' object has no attribute 'Event'

======================================================================
ERROR: testSendFrame (test.test_socket.CANTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython-default/Lib/test/test_socket.py", line 231, in _setUp
    self.server_ready = threading.Event()
AttributeError: 'NoneType' object has no attribute 'Event'

======================================================================
ERROR: testSendMaxFrame (test.test_socket.CANTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython-default/Lib/test/test_socket.py", line 231, in _setUp
    self.server_ready = threading.Event()
AttributeError: 'NoneType' object has no attribute 'Event'

======================================================================
ERROR: testSendMultiFrames (test.test_socket.CANTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython-default/Lib/test/test_socket.py", line 231, in _setUp
    self.server_ready = threading.Event()
AttributeError: 'NoneType' object has no attribute 'Event'

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

Patch attached.

----------
components: Tests
files: test_socket_thread.diff
keywords: patch
messages: 220339
nosy: berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: test_socket fails --without-threads
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35593/test_socket_thread.diff

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

From report at bugs.python.org  Thu Jun 12 13:38:21 2014
From: report at bugs.python.org (=?utf-8?b?SsO8cmdlbiBC?=)
Date: Thu, 12 Jun 2014 11:38:21 +0000
Subject: [New-bugs-announce] [issue21731] Calendar Problem with Windows (XP)
Message-ID: <1402573101.18.0.674315484569.issue21731@psf.upfronthosting.co.za>


New submission from J?rgen B:

I had a problem with calendar.formatmonth()
Error message was 'Unsupported Locale'

Well, it seems that Windows (XP) does nothing accept to setlocale than ''

I changed /lib/calendar.py line 488 ff to
class different_locale:
    def __init__(self, locale):
        self.locale = locale

    def __enter__(self):
        _locale.setlocale(_locale.LC_TIME, '') # juebo
        self.oldlocale = _locale.getlocale(_locale.LC_TIME)
        # _locale.setlocale(_locale.LC_TIME, self.locale) # juebo

    def __exit__(self, *args):
        # _locale.setlocale(_locale.LC_TIME, self.oldlocale) #juebo
        _locale.setlocale(_locale.LC_TIME, '')

Well, I am absolute new to Python. So could anybody look over it

----------
components: Library (Lib)
messages: 220341
nosy: Juebo
priority: normal
severity: normal
status: open
title: Calendar Problem with Windows (XP)
type: compile error
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Jun 12 16:55:59 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Jun 2014 14:55:59 +0000
Subject: [New-bugs-announce] [issue21732]
	SubprocessTestsMixin.test_subprocess_terminate() hangs	on
	"AMD64 Snow Leop 3.x" buildbot
Message-ID: <1402584959.34.0.367211302665.issue21732@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1742/steps/test/logs/stdio

Timeout (1:00:00)!
Thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/selectors.py", line 311 in select
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 822 in _run_once
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 195 in run_forever
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 215 in run_until_complete
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/test_events.py", line 1492 in test_subprocess_terminate
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 577 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 625 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 125 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 87 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 125 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 87 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 125 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 87 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/runner.py", line 168 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1724 in _run_suite
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1758 in run_unittest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/__init__.py", line 29 in test_main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 967 in runtest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 532 in main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1587 in <module>
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 85 in _run_code
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1562, in main_in_temp_cwd
    main()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_asyncio: Exit code 1
[390/390] test_asyncio
make: *** [buildbottest] Error 1

----------
components: Tests, asyncio
messages: 220354
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: SubprocessTestsMixin.test_subprocess_terminate() hangs on "AMD64 Snow Leop 3.x" buildbot
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 17:01:09 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Jun 2014 15:01:09 +0000
Subject: [New-bugs-announce] [issue21733] "mmap(size=9223372036854779904)
	failed" message when	running test_io on "AMD64 Snow Leop 3.x"
	buildbot
Message-ID: <1402585269.84.0.645646182002.issue21733@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1734/steps/test/logs/stdio

python.exe(59021,0x7fff71296cc0) malloc: *** mmap(size=9223372036854779904) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(59021,0x7fff71296cc0) malloc: *** mmap(size=9223372036854779904) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(59021,0x7fff71296cc0) malloc: *** mmap(size=9223372036854779904) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
[212/390] test_io

----------
assignee: ronaldoussoren
components: Macintosh, Tests
keywords: buildbot
messages: 220356
nosy: haypo, ronaldoussoren
priority: normal
severity: normal
status: open
title: "mmap(size=9223372036854779904) failed" message when running test_io on "AMD64 Snow Leop 3.x" buildbot

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

From report at bugs.python.org  Thu Jun 12 17:05:46 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Jun 2014 15:05:46 +0000
Subject: [New-bugs-announce] [issue21734] compilation of the _ctypes module
	fails on OpenIndiana:	ffi_prep_closure_loc symbol is missing
Message-ID: <1402585546.51.0.39402588592.issue21734@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

gcc -shared (...)Modules/_ctypes/_ctypes.o (...) -o build/lib.solaris-2.11-i86pc.64bit-3.5-pydebug/_ctypes.so (...)
*** WARNING: renaming "_ctypes" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.11-i86pc.64bit-3.5-pydebug/_ctypes.so: symbol ffi_prep_closure_loc: referenced symbol not found
(...)
Failed to build these modules: _ctypes   _curses   _curses_panel   _lzma

----------
messages: 220357
nosy: haypo
priority: normal
severity: normal
status: open
title: compilation of the _ctypes module fails on OpenIndiana: ffi_prep_closure_loc symbol is missing
type: compile error
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 17:09:27 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Jun 2014 15:09:27 +0000
Subject: [New-bugs-announce]
	[issue21735]	test_threading.test_main_thread_after_fork_from_nonmain_thread()	hangs
	on the FreeBSD 10 buildbot
Message-ID: <1402585767.95.0.817144752371.issue21735@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/2220/steps/test/logs/stdio

[390/390] test_threading
Timeout (1:00:00)!
Thread 0x0000000801c06400 (most recent call first):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/selectors.py", line 364 in select
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 1618 in _communicate
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 971 in communicate
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/script_helper.py", line 45 in _assert_python
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/script_helper.py", line 69 in assert_python_ok
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 536 in test_main_thread_after_fork_from_nonmain_thread
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 577 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 625 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 125 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 87 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 125 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 87 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 125 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 87 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1724 in _run_suite
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1758 in run_unittest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1277 in <lambda>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 967 in runtest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 532 in main
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1587 in <module>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1562, in main_in_temp_cwd
    main()
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_threading: Exit code 1
*** Error code 1

----------
components: Tests
keywords: buildbot
messages: 220359
nosy: haypo
priority: normal
severity: normal
status: open
title: test_threading.test_main_thread_after_fork_from_nonmain_thread() hangs on the FreeBSD 10 buildbot
versions: Python 3.5

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

From report at bugs.python.org  Thu Jun 12 18:14:49 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 12 Jun 2014 16:14:49 +0000
Subject: [New-bugs-announce] [issue21736] Add __file__ attribute to frozen
	modules
Message-ID: <1402589689.02.0.501075866976.issue21736@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The missing __file__ attribute on frozen modules causes lots of issues with the stdlib (see e.g. Issue21709 and the stdlib test suite) and other tools that expect this attribute to always be present.

The attached patch for 3.4.1 adds this attribute to all frozen modules and resolves most issues. It cannot resolve the problem of not necessarily finding the directories/files listed in those attributes, but at least makes it possible to continue using code that only uses the attribute for error reporting.

----------
components: Interpreter Core, Library (Lib)
messages: 220362
nosy: lemburg
priority: normal
severity: normal
status: open
title: Add __file__ attribute to frozen modules
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 18:24:20 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 12 Jun 2014 16:24:20 +0000
Subject: [New-bugs-announce] [issue21737] runpy.run_path() fails with frozen
	__main__ modules
Message-ID: <1402590260.07.0.642136179062.issue21737@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The logic in runpy.run_path() assumes that removing the __main__ entry from sys.modules is enough to be able to use the module search logic for e.g. importing packages and ZIP files (with embedded __main__.py files).

In Python 3.4 (and probably also 3.3 where the importlib was added), this no longer works if a frozen __main__ module is present.

The reason is that the sys.meta_path lists the FrozenImporter before the PathFinder. The runpy trick only works if the PathFinder gets a chance to do its magic, but never gets to play, since the FrozenImporter always returns the existing frozen __main__ module (causing all kinds of strange effects).

Now, looking at the implementation, the frozen __main__ is imported by import.c, not the importlib, so a working solution is to not have the FrozenImporter work on __main__ modules at all.

This then allows the PathFinder to deal with finding the __main__ module in directories or ZIP files and thus allows the hack in runpy to work again.

BTW: In the long run, it would probably better to clean up runpy altogether. It's really messy code due to the many details that it has to address, but I guess this a larger project on its own.

----------
components: Interpreter Core
messages: 220364
nosy: lemburg
priority: normal
severity: normal
status: open
title: runpy.run_path() fails with frozen __main__ modules
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 20:35:45 2014
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 12 Jun 2014 18:35:45 +0000
Subject: [New-bugs-announce] [issue21738] Enum docs claim replacing __new__
	is not possible
Message-ID: <1402598145.45.0.559693441236.issue21738@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Replacing __new__ in an Enum subclass is not possible /in the subclass definition/, but is easily replaced via monkey-patching after the class has been defined.

Docs need to be updated to reflect this.

----------
assignee: ethan.furman
messages: 220372
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: Enum docs claim replacing __new__ is not possible
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 21:17:59 2014
From: report at bugs.python.org (Karl Richter)
Date: Thu, 12 Jun 2014 19:17:59 +0000
Subject: [New-bugs-announce] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
Message-ID: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>


New submission from Karl Richter:

It would be useful to have a short statement in the docs (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) that the expression in a list comprehension isn't put into a block, but evaluated against the same block where it is located because intuitively one might think that variables can be overridden in the statement.
This applies to both 2.7 and 3.4.1.

----------
assignee: docs at python
components: Documentation
messages: 220374
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 12 22:59:13 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jun 2014 20:59:13 +0000
Subject: [New-bugs-announce] [issue21740] doctest doesn't allow duck-typing
	callables
Message-ID: <1402606753.04.0.326464066676.issue21740@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

doctest uses inspect.isfunction() to detect callable objects on which to detect docstrings. Unfortunately, this prevents running doctests on functions which have been decorated to return other types of callables (for example numba's @jit decorator). In the attached example file, the wrapped "bar" function does not have its doctest executed.

It would be useful for doctest to be more flexible here, although I'm not sure what the exact criterion should be.

----------
components: Library (Lib)
files: ducktest.py
messages: 220384
nosy: ezio.melotti, gvanrossum, michael.foord, pitrou, r.david.murray, rhettinger, tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: doctest doesn't allow duck-typing callables
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35601/ducktest.py

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

From report at bugs.python.org  Thu Jun 12 23:29:25 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 12 Jun 2014 21:29:25 +0000
Subject: [New-bugs-announce] [issue21741] Convert most of the test suite to
	using unittest.main()
Message-ID: <1402608565.65.0.506633774065.issue21741@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Attached is a quick-and-dirty script that converts a large chunk of the test suite away from support.run_unittest and test_main to unittest test discovery and unittest.main.  Several files are marked as 'do not touch' due to various issues that the script can't easily detect, many others are not touched due to issues that the script can detect but can't deal with on its own.  Tests that can be changed are changed directly, console output is a huge listing of test files checked and what was done with them, followed by a summary of what tests were not touched for what reason, and a list of changed tests is output in 'changed_tests.txt'.

----------
components: Tests
files: fix_test_main.py
messages: 220386
nosy: ezio.melotti, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Convert most of the test suite to using unittest.main()
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35602/fix_test_main.py

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

From report at bugs.python.org  Fri Jun 13 02:56:54 2014
From: report at bugs.python.org (Vishvananda Ishaya)
Date: Fri, 13 Jun 2014 00:56:54 +0000
Subject: [New-bugs-announce] [issue21742] WatchedFileHandler can fail due to
	race conditions or	file open issues.
Message-ID: <1402621014.45.0.896423515186.issue21742@psf.upfronthosting.co.za>


New submission from Vishvananda Ishaya:

If there is a failure during the re-opening of the file WatchedFileHandler can lose the ability to log and starts throwing IOErrors.

----------
messages: 220403
nosy: vishvananda
priority: normal
severity: normal
status: open
title: WatchedFileHandler can fail due to race conditions or file open issues.
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun 13 03:37:58 2014
From: report at bugs.python.org (Lita Cho)
Date: Fri, 13 Jun 2014 01:37:58 +0000
Subject: [New-bugs-announce] [issue21743] Create tests for RawTurtleScreen
Message-ID: <1402623478.68.0.125250729344.issue21743@psf.upfronthosting.co.za>


New submission from Lita Cho:

Create test coverage for the RawTurtleScreen class.

----------
messages: 220414
nosy: Lita.Cho, jesstess
priority: normal
severity: normal
status: open
title: Create tests for RawTurtleScreen

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

From report at bugs.python.org  Fri Jun 13 06:02:27 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 13 Jun 2014 04:02:27 +0000
Subject: [New-bugs-announce] [issue21744] itertools.islice() goes over all
	the pre-initial	elements even if the iterable can seek
Message-ID: <1402632147.52.0.812545873846.issue21744@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

If L is a big sequence and I do "itertool.islice(L, 1000000, None)", islice will go over a million elements before returning the first that I actually cared.

Since L is a sequence, islice could go directly to the element 1000000.

My program performance improved hugely replacing a "for i in L[p:]" for "for i in (L[p] for p in range(p, len(L)))".

Using itertools and doing "for i in itertools.islice(L, p, None)" is massively inefficient.

----------
components: Extension Modules
messages: 220417
nosy: jcea
priority: normal
severity: normal
status: open
title: itertools.islice() goes over all the pre-initial elements even if the iterable can seek
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Jun 13 06:19:25 2014
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 13 Jun 2014 04:19:25 +0000
Subject: [New-bugs-announce] [issue21745] Devguide: mention requirement to
	install Visual Studio	SP1 on Windows
Message-ID: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

Per my email on core-mentorship, the instructions for compiling CPython on Windows at
https://docs.python.org/devguide/setup.html#windows are good, however I did have one issue where the dev guide didn't help. During the link
step, I got this error:

LINK : fatal error LNK1123: failure during conversion to COFF: file
invalid or corrupt

It took me a while to figure out how to fix it. I found this question
on StackOverflow:

http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

The first part of the answer didn't help (because incremental linking
is already disabled). But the second part, kinda tucked away there, is
what fixed it for me -- simply installing Visual Studio 2010 SP1 here:

http://www.microsoft.com/en-us/download/details.aspx?id=23691

After this, I restarted my PC and it linked fine.

So I suggest a small addition to the dev guide to mention this -- adding the following paragraph after the "Python 3.3 and later" paragraph:

-----
You'll also need to install the Visual Studio `Service Pack 1 (SP1)
<http://www.microsoft.com/en-us/download/details.aspx?id=23691>`_. If you
don't install this service pack, you may receive errors like the following
during linking: ``LINK : fatal error LNK1123: failure during conversion to
COFF: file invalid or corrupt``.
-----

Patch attached.

----------
assignee: docs at python
components: Documentation
files: visual_studio_sp1.patch
keywords: patch
messages: 220418
nosy: benhoyt, docs at python
priority: normal
severity: normal
status: open
title: Devguide: mention requirement to install Visual Studio SP1 on Windows
type: enhancement
Added file: http://bugs.python.org/file35607/visual_studio_sp1.patch

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

From report at bugs.python.org  Fri Jun 13 11:09:52 2014
From: report at bugs.python.org (Matthew Gilson)
Date: Fri, 13 Jun 2014 09:09:52 +0000
Subject: [New-bugs-announce] [issue21746] urlparse.BaseResult no longer
	exists
Message-ID: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>


New submission from Matthew Gilson:

The BaseResult has been replaced by namedtuple.  This also opens up all of the documented methods on namedtuple which would be nice to have as part of the API.  I've taken a stab and re-writing the docs here.  Feel free to use it (or not)...

----------
files: python_doc_patch.patch
keywords: patch
messages: 220425
nosy: mgilson
priority: normal
severity: normal
status: open
title: urlparse.BaseResult no longer exists
Added file: http://bugs.python.org/file35612/python_doc_patch.patch

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

From report at bugs.python.org  Fri Jun 13 14:36:17 2014
From: report at bugs.python.org (Serhiy Ivanov)
Date: Fri, 13 Jun 2014 12:36:17 +0000
Subject: [New-bugs-announce] [issue21747] argvars: error while parsing under
	windows
Message-ID: <1402662977.19.0.12734733742.issue21747@psf.upfronthosting.co.za>


New submission from Serhiy Ivanov:

have 1.py as:
import argparse
import sys
print (sys.argv)
parser = argparse.ArgumentParser(prog='demo')
parser.add_argument('--host -h', help='host for the server of %(prog)', nargs=1, required=True, metavar='<host>')
parser.add_argument('--port -p', help='port for the server of %(prog)', nargs=1, required=True, metavar='<port>')
parser.parse_args(sys.argv)


and run C:\Python34\python.exe 1.py -h 1.
Will obtain:

Traceback (most recent call last):
  File "1.py", line 7, in <module>
    parser.parse_args(sys.argv)
  File "C:\Python34\lib\argparse.py", line 1717, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "C:\Python34\lib\argparse.py", line 1749, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "C:\Python34\lib\argparse.py", line 1955, in _parse_known_args
    start_index = consume_optional(start_index)
  File "C:\Python34\lib\argparse.py", line 1895, in consume_optional
    take_action(action, args, option_string)
  File "C:\Python34\lib\argparse.py", line 1823, in take_action
    action(self, namespace, argument_values, option_string)
  File "C:\Python34\lib\argparse.py", line 1016, in __call__
    parser.print_help()
  File "C:\Python34\lib\argparse.py", line 2348, in print_help
    self._print_message(self.format_help(), file)
  File "C:\Python34\lib\argparse.py", line 2332, in format_help
    return formatter.format_help()
  File "C:\Python34\lib\argparse.py", line 278, in format_help
    help = self._root_section.format_help()
  File "C:\Python34\lib\argparse.py", line 208, in format_help
    func(*args)
  File "C:\Python34\lib\argparse.py", line 208, in format_help
    func(*args)
  File "C:\Python34\lib\argparse.py", line 515, in _format_action
    help_text = self._expand_help(action)
  File "C:\Python34\lib\argparse.py", line 602, in _expand_help
    return self._get_help_string(action) % params
ValueError: incomplete format

----------
components: Library (Lib)
messages: 220432
nosy: icegood
priority: normal
severity: normal
status: open
title: argvars: error while parsing under windows
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 13 15:31:43 2014
From: report at bugs.python.org (David Jones)
Date: Fri, 13 Jun 2014 13:31:43 +0000
Subject: [New-bugs-announce] [issue21748] glob.glob does not sort its results
Message-ID: <1402666303.8.0.471997942959.issue21748@psf.upfronthosting.co.za>


New submission from David Jones:

```
for f in glob.glob('input/*/*.dat'): print f
```

outputs:

```
input/ghcnm.v3.2.2.20140611/ghcnm.tavg.v3.2.2.20140611.qca.dat
input/ghcnm.v3.2.2.20140506/ghcnm.tavg.v3.2.2.20140506.qca.dat
```

Note that these are not in the right order.  Compare with shell which always sorts its globs:

```
drj$ printf '%s\n' input/*/*.dat
input/ghcnm.v3.2.2.20140506/ghcnm.tavg.v3.2.2.20140506.qca.dat
input/ghcnm.v3.2.2.20140611/ghcnm.tavg.v3.2.2.20140611.qca.dat
```

I think the shell behaviour is better and we should be allowed to rely on glob.glob sorting its result.

Note from the documentation: "The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell". The Unix shell has always sorted its globs.

----------
components: Library (Lib)
messages: 220441
nosy: drj
priority: normal
severity: normal
status: open
title: glob.glob does not sort its results
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 13 16:08:31 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 Jun 2014 14:08:31 +0000
Subject: [New-bugs-announce] [issue21749] pkgutil ImpLoader does not support
	frozen modules
Message-ID: <1402668511.45.0.703803525132.issue21749@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

This leads to problems when using runpy, since it relies on pkgutil to find importers.

In Python 2, ImpLoader is used by ImpImporter which is used as fallback importer by get_importer(). get_importer() is used by runpy to implement e.g. the -m option. As a result, -m doesn't work with frozen modules.

In Python 3, ImpLoader still exists, but is deprecated. get_importer() also no longer falls back to the ImpImporter as default, so the situation is less bothersome.

Here's a patch for Python 3.4.1 which shows how to add support for frozen modules. The same patch also works in Python 2.6 and 2.7.

----------
components: Distutils, Library (Lib)
files: pkgutil-frozen-modules-support.patch
keywords: patch
messages: 220442
nosy: dstufft, eric.araujo, lemburg
priority: normal
severity: normal
status: open
title: pkgutil ImpLoader does not support frozen modules
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35617/pkgutil-frozen-modules-support.patch

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

From report at bugs.python.org  Fri Jun 13 20:14:49 2014
From: report at bugs.python.org (Paul Koning)
Date: Fri, 13 Jun 2014 18:14:49 +0000
Subject: [New-bugs-announce] [issue21750] mock_open data is visible only
	once for the life of the	class
Message-ID: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>


New submission from Paul Koning:

The read_data iterator that supplies bits of read data when asked from unittest.mock.mock_open is a class attribute.  The result is that, if you instantiate the class multiple times, that iterator is shared.  This isn't documented and it seems counterintuitive.  The purpose of mock_open is to act like a file, and read_data is that file's data.  A file contains the same data each time you read it.  So it would seem better for the data iterator to be an instance attribute, initialized from the mock_open read_data value each time mock_open is called to create a new file instance.

----------
components: Library (Lib)
messages: 220474
nosy: pkoning
priority: normal
severity: normal
status: open
title: mock_open data is visible only once for the life of the class
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 13 20:29:15 2014
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 13 Jun 2014 18:29:15 +0000
Subject: [New-bugs-announce] [issue21751] Expand zipimport to support bzip2
	and lzma
Message-ID: <1402684155.71.0.642460028392.issue21751@psf.upfronthosting.co.za>


New submission from Donald Stufft:

Since Python 3.3 the zipfile module has support bzip2 and lzma compression, however the zipimporter does not support these. It would be awesome if zipimport did support them.

----------
messages: 220477
nosy: brett.cannon, dstufft, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Expand zipimport to support bzip2 and lzma
versions: Python 3.5

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

From report at bugs.python.org  Fri Jun 13 21:07:49 2014
From: report at bugs.python.org (Don Spaulding)
Date: Fri, 13 Jun 2014 19:07:49 +0000
Subject: [New-bugs-announce] [issue21752] Document Backwards Incompatible
	change to logging in 3.4
Message-ID: <1402686469.59.0.301170999664.issue21752@psf.upfronthosting.co.za>


New submission from Don Spaulding:

Discussion of this issue on ML:

https://mail.python.org/pipermail/python-dev/2014-June/135048.html

The behavior of logging.getLevelName changed in Python 3.4.  Previously when passed a string, it would return the corresponding integer value of the level.  In 3.4 it was changed to match the behavior of its documentation.  The patch can be found in issue #18046.

This seems like something that should be documented somewhere.

----------
assignee: docs at python
components: Documentation
messages: 220482
nosy: docs at python, donspaulding
priority: normal
severity: normal
status: open
title: Document Backwards Incompatible change to logging in 3.4
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 13 21:10:48 2014
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 13 Jun 2014 19:10:48 +0000
Subject: [New-bugs-announce] [issue21753] subprocess shell=True on Windows
	character escaping
Message-ID: <1402686648.11.0.572463197198.issue21753@psf.upfronthosting.co.za>


New submission from Jim Jewett:

Inspired by https://mail.python.org/pipermail/python-dev/2014-June/135029.html and the following thread.  

"""
Normal Windows behavior:

  >hg status --rev ".^1"
  M mercurial\commands.py
  ? pysptest.py

  >hg status --rev .^1
  abort: unknown revision '.1'!

So, ^ is an escape character. See
http://www.tomshardware.co.uk/forum/35565-45-when-special-command-line
"""

It probably isn't possible to pre-escape commands for every possible command interpreter, but it makes sense to get the standard shells right. 

In fact, global function list2cmdline already exists (and is apparently specific to the Microsoft compiler), but ... its rules are not the same as those of the default windows shell.  (Per the tomshardware link, those rules (for windows) did change a while back.)

I propose a similar list2shellcmd function.  Based on my own very incomplete information, it would currently look like:

def list2shellcmd(seq):
    """Turn the sequence of arguments into a single command line, with escaped characters."""
    if mswindows:
        line=list2cmdline(seq).replace("^", "^^")
    else:
        line=" ".join(seq)
    return line

but there may well be escapes (such as \) that are appropriate even for posix.

Note that related issue http://bugs.python.org/issue7839 proposes a larger cleanup, such as forbidding the problematic functionality entirely.

----------
components: Library (Lib)
messages: 220483
nosy: Jim.Jewett
priority: normal
severity: normal
status: open
title: subprocess shell=True on Windows character escaping
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Jun 14 09:30:01 2014
From: report at bugs.python.org (ingrid)
Date: Sat, 14 Jun 2014 07:30:01 +0000
Subject: [New-bugs-announce] [issue21754] Add tests for
	turtle.TurtleScreenBase
Message-ID: <1402731001.27.0.625153965073.issue21754@psf.upfronthosting.co.za>


Changes by ingrid <hi at ingridcheung.com>:


----------
components: Tests
files: TurtleScreenBase_tests.patch
keywords: patch
nosy: ingrid, jesstess
priority: normal
severity: normal
status: open
title: Add tests for turtle.TurtleScreenBase
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35624/TurtleScreenBase_tests.patch

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

From report at bugs.python.org  Sat Jun 14 10:22:29 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Jun 2014 08:22:29 +0000
Subject: [New-bugs-announce] [issue21755] test_importlib.test_locks fails
	--without-threads
Message-ID: <1402734149.6.0.706440396249.issue21755@psf.upfronthosting.co.za>


New submission from Berker Peksag:

======================================================================
ERROR: test.test_importlib.test_locks (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 58, in testPartExecutor
    yield
  File "/home/berker/projects/cpython-default/Lib/unittest/case.py", line 577, in run
    testMethod()
  File "/home/berker/projects/cpython-default/Lib/unittest/loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: test.test_importlib.test_locks
Traceback (most recent call last):
  File "/home/berker/projects/cpython-default/Lib/unittest/loader.py", line 312, in _find_tests
    module = self._get_module_from_name(name)
  File "/home/berker/projects/cpython-default/Lib/unittest/loader.py", line 290, in _get_module_from_name
    __import__(name)
  File "/home/berker/projects/cpython-default/Lib/test/test_importlib/test_locks.py", line 123, in <module>
    DeadlockError=DEADLOCK_ERRORS)
  File "/home/berker/projects/cpython-default/Lib/test/test_importlib/util.py", line 82, in test_both
    return split_frozen(test_class, base, **kwargs)
  File "/home/berker/projects/cpython-default/Lib/test/test_importlib/util.py", line 76, in split_frozen
    frozen = specialize_class(cls, 'Frozen', base, **kwargs)
  File "/home/berker/projects/cpython-default/Lib/test/test_importlib/util.py", line 70, in specialize_class
    value = values[kind]
KeyError: 'Frozen'

I've used the same logic as ModuleLockAsRLockTests to silence the test failure.

Patch attached.

----------
components: Tests
files: test_locks.diff
keywords: patch
messages: 220534
nosy: berker.peksag, brett.cannon, eric.snow
priority: normal
severity: normal
stage: patch review
status: open
title: test_importlib.test_locks fails --without-threads
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35625/test_locks.diff

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

From report at bugs.python.org  Sat Jun 14 11:48:15 2014
From: report at bugs.python.org (Tal Einat)
Date: Sat, 14 Jun 2014 09:48:15 +0000
Subject: [New-bugs-announce] [issue21756] IDLE - ParenMatch fails to find
	closing paren of	multi-line statements
Message-ID: <1402739295.59.0.675144010232.issue21756@psf.upfronthosting.co.za>


New submission from Tal Einat:

Originally reported on issue #21694.

Regarding, for example, the following code:
(3  +
 4 -   1)

Placing the cursor after the opening parenthesis and invoking the "Show surrounding parens" event causes just the first line to be highlighted. Obviously, the second line should be highlighted as well.

I've found a good (clean & fast) solution for shell windows, but can't find any good way for editor windows other than always parsing the entire code. Doing this every time HyperParser is used could significantly degrade IDLE's performance. Therefore I've decided to have this done only by ParenMatch.flash_paren_event(). Note that ParenMatch.paren_closed_event() doesn't need this, since all of the code which is relevant for inspection lies before the closing parenthesis.

See attached patch fixing this issue. Review and additional testing are required.

----------
components: IDLE
files: taleinat.20140614.IDLE_parenmatch_multiline_statement.patch
keywords: patch
messages: 220542
nosy: taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE - ParenMatch fails to find closing paren of multi-line statements
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35626/taleinat.20140614.IDLE_parenmatch_multiline_statement.patch

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

From report at bugs.python.org  Sat Jun 14 16:04:10 2014
From: report at bugs.python.org (Mark Bell)
Date: Sat, 14 Jun 2014 14:04:10 +0000
Subject: [New-bugs-announce] [issue21757] Can't reenable menus in Tkinter on
	Mac
Message-ID: <1402754650.33.0.85036696975.issue21757@psf.upfronthosting.co.za>


New submission from Mark Bell:

The following example is a Tkinter app with a button that toggles the menu being enabled based off of https://mail.python.org/pipermail/tkinter-discuss/2004-September/000204.html

#-----------------------------------

from Tkinter import *

root=Tk()

def hello():
    print('hello!')

def toggle():
	print('I think the menu bar is %s' % menubar.entrycget(0, 'state'))
	if menubar.entrycget(0, 'state')=='normal':
		print('disabling')
		menubar.entryconfig(0,state=DISABLED)
		print('disbled')
	else:
		print('enabling')
		menubar.entryconfig(0,state=NORMAL)
		print('enabled')

menubar = Menu(root)
submenu = Menu(menubar, tearoff=0)
submenu.add_command(label='Hello', command=hello)
menubar.add_cascade(label='test', menu=submenu)

# this cascade will have index 0 in submenu
b = Button(root, text='Toggle', command=toggle)
b.pack()

# display the menu
root.config(menu=menubar)
root.mainloop()

#-----------------------------------

On Windows 7 and Ubuntu 14.04 (using Python 2.7.6 and Tkinter Revision 81008) clicking the button toggles the menu being enabled. However, on Mac 10.9 (again under Python 2.7.6 and Tkinter Revision 81008) the menu becomes stuck disabled. 

Additionally, the example also prints out what state it thinks the menu has (using entrycget) and it would print out that it thought that the menu was in fact alternating between enabled and disabled.

Others have verified this being the case. See: http://stackoverflow.com/questions/24207870/cant-reenable-menus-in-python-tkinter-on-mac

----------
components: Tkinter
files: tkinter_test.py
messages: 220553
nosy: Mark.Bell
priority: normal
severity: normal
status: open
title: Can't reenable menus in Tkinter on Mac
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35628/tkinter_test.py

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

From report at bugs.python.org  Sat Jun 14 18:17:58 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Jun 2014 16:17:58 +0000
Subject: [New-bugs-announce] [issue21758] Not so correct documentation
	about	asyncio.subprocess_shell method
Message-ID: <1402762678.44.0.429008087381.issue21758@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

subprocess_shell in asyncio accepts cmd as a string or a bytes but the test unit, the documentation and the exception indicates that it only accepts a string.

----------
assignee: docs at python
components: Documentation, asyncio
files: fix_doc_asyncio_subprocess_shell.patch
keywords: patch
messages: 220567
nosy: docs at python, gvanrossum, haypo, vajrasky, yselivanov
priority: normal
severity: normal
status: open
title: Not so correct documentation about asyncio.subprocess_shell method
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35634/fix_doc_asyncio_subprocess_shell.patch

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

From report at bugs.python.org  Sat Jun 14 21:18:33 2014
From: report at bugs.python.org (are-you-watching-closely)
Date: Sat, 14 Jun 2014 19:18:33 +0000
Subject: [New-bugs-announce] [issue21759] URL Typo in Documentation FAQ
Message-ID: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>


New submission from are-you-watching-closely:

Under this question (https://docs.python.org/2/faq/programming.html#my-program-is-too-slow-how-do-i-speed-it-up) in the 2.7 programming FAQ, it gives a link to an anecdote that Guido van Rossum wrote.

The URL it gives:
http://www.python.org/doc/essays/list2str.html

The correct URL (no .html):
http://www.python.org/doc/essays/list2str

I'm sure there are some people who didn't think to remove the '.html', and couldn't find the story.

Just a quick typo fix.

----------
assignee: docs at python
components: Documentation
messages: 220575
nosy: are-you-watching-closely, docs at python
priority: normal
severity: normal
status: open
title: URL Typo in Documentation FAQ
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 14 21:58:13 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Jun 2014 19:58:13 +0000
Subject: [New-bugs-announce] [issue21760] inspect documentation describes
	module type inaccurately
Message-ID: <1402775893.22.0.955121317915.issue21760@psf.upfronthosting.co.za>


New submission from Eric Snow:

In the documentation for the inspect module, the module type is described with just 2 of its potential 7 attributes.  The language reference[2] and importlib docs[3] both provide an accurate list of module attributes.

Furthermore, the description for __file__ should be fixed.  It should be clear that __file__ reflects the location from which the module was loaded, that location is not necessarily a filename, and the attribute may not exist if the module was not loaded from a specific location (e.g. builtin and frozen modules).  The same goes for __cached__

[1] https://docs.python.org/dev/library/inspect.html#types-and-members
[2] https://docs.python.org/3/reference/import.html#import-related-module-attributes
[3] https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec

----------
assignee: docs at python
components: Documentation
messages: 220576
nosy: docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect documentation describes module type inaccurately
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun 14 22:33:24 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Jun 2014 20:33:24 +0000
Subject: [New-bugs-announce] [issue21761] language reference describes the
	role of module.__file__	inaccurately
Message-ID: <1402778004.82.0.418404996295.issue21761@psf.upfronthosting.co.za>


New submission from Eric Snow:

The language reference [1] says:

  Ultimately, the loader is what makes use of __file__ and/or __cached__

This implies that loaders should use __file__ and __cached__ when loading a module.  Instead loaders are meant to implement exec_module() and use the spec that's passed in.

The entire section should have a clear note that loaders are not meant to rely a module's import-related attributes.

[1] https://docs.python.org/3/reference/import.html#__file__
[2] https://docs.python.org/3/reference/import.html#import-related-module-attributes

----------
messages: 220578
nosy: barry, brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: language reference describes the role of module.__file__ inaccurately
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun 14 23:33:51 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Jun 2014 21:33:51 +0000
Subject: [New-bugs-announce] [issue21762] update the import machinery to
	only use __spec__
Message-ID: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za>


New submission from Eric Snow:

With PEP 451, Python 3.4 introduced module specs to encapsulate the module's import-related information, particularly for loading.  While __loader__, __file__, and __cached__ are no longer used by the import machinery, in a few places it still uses __name__, __package__, and __path__.

Typically the spec and the module attrs will have the same values, so it would be a non-issue.  However, the import-related module attributes are not read-only and the consequences of changing them (i.e. accidentally or to rely on an implementation detail) are not clearly defined.  Making the spec strictly authoritative reduces the likelihood accidental changes and gives a better focus point for a module's import behavior (which was kind of the point of PEP 451 in the first place).  Furthermore, objects in sys.modules are not required to be modules.  By relying strictly on __spec__ we likewise give a more distinct target (of import-related info) for folks that need to use that trick.

I don't recall the specifics on why we didn't change those 3 attributes for PEP 451 (unintentional or for backward compatibility?).  At one point we discussed the idea that a module's spec contains the values that *were* used to load the module.  Instead, each spec became the image of how the import system sees and treats the module.

So unless there's some solid reason, I'd like to see the use of __name__, __package__, and __path__ by the import machinery eliminated (and accommodated separately if appropriate).  Consistent use of specs in the import machinery will help limit future surprises.

Here are the specific places:

__name__
--------
mod.__repr__()
ExtensionFileLoader.load_module()
importlib._bootstrap._handle_fromlist()
importlib._bootstrap._calc___package__()
importlib._bootstrap.__import__()

__package__
-----------
importlib._bootstrap._calc___package__()

__path__
--------
importlib._bootstrap._find_and_load_unlocked()
importlib._bootstrap._handle_fromlist()
importlib._bootstrap._calc___package__()

__file__
--------
mod.__repr__()

Note that I'm not suggesting the module attributes be eliminated (they are useful for informational reasons).  I would just like the import system to stop using them.  I suppose they could be turned into read-only properties, but anything like that should be addressed in a separate issue.

If we do make this change, the language reference, importlib docs, and inspect docs should be updated to clearly reflect the role of the module attributes in the import system.

I have not taken into account the impact on the standard library.  However, I expect that it will be minimal at best.  (See issue #21736 for a related discussion).

----------
components: Interpreter Core
messages: 220581
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: update the import machinery to only use __spec__
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun 15 00:16:50 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Jun 2014 22:16:50 +0000
Subject: [New-bugs-announce] [issue21763] Clarify requirements for file-like
	objects
Message-ID: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

It is currently not perfectly clear what Python (and the standard library) assumes about file-like objects (see e.g. http://article.gmane.org/gmane.comp.python.devel/148199).

The attached doc patch tries to improve the current situation by  stating explicitly that the description of IOBase et al specifies a *mandatory* interface for anything that claims to be file-like.

----------
assignee: docs at python
components: Documentation
files: iobase.diff
keywords: patch
messages: 220588
nosy: benjamin.peterson, docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek, ncoghlan, nikratio, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Clarify requirements for file-like objects
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35636/iobase.diff

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

From report at bugs.python.org  Sun Jun 15 00:47:56 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Jun 2014 22:47:56 +0000
Subject: [New-bugs-announce] [issue21764] Document that IOBase.__del__ calls
	self.close
Message-ID: <1402786076.21.0.846118348944.issue21764@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

CPython's io.IOBase.__del__ calls self.close(), but this isn't documented anywhere (and may be surprised for derived classes).

The attached patch extends the documentation.

----------
assignee: docs at python
components: Documentation
files: iobase2.diff
keywords: patch
messages: 220591
nosy: benjamin.peterson, docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek, nikratio, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Document that IOBase.__del__ calls self.close
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35637/iobase2.diff

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

From report at bugs.python.org  Sun Jun 15 01:12:54 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Jun 2014 23:12:54 +0000
Subject: [New-bugs-announce] [issue21765] Idle: make 3.x HyperParser work
	with non-ascii	identifiers.
Message-ID: <1402787574.99.0.986548729035.issue21765@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

idlelib.HyperParser.Hyperparser has these lines
    _whitespace_chars = " \t\n\\"
    _id_chars = string.ascii_letters + string.digits + "_"
    _id_first_chars = string.ascii_letters + "_"
used in _eat_identifier() and get_expression. At least the latter two should be turned into functions that access the unicode datebase. (Such functions, if not already present in the stdlib, should be. But adding something elsewhere would be another issue.)

----------
messages: 220593
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: make 3.x HyperParser work with non-ascii identifiers.
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun 15 03:33:28 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 15 Jun 2014 01:33:28 +0000
Subject: [New-bugs-announce] [issue21766] CGIHTTPServer File Disclosure
Message-ID: <1402796008.56.0.634825726515.issue21766@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

>From the security list:

The CGIHTTPServer Python module does not properly handle URL-encoded
path separators in URLs. This may enable attackers to disclose a CGI
script's source code or execute arbitrary scripts in the server's
document root.

Details
=======

Product: Python CGIHTTPServer
Affected Versions: 2.7.5, 3.3.4 (possibly others)
Fixed Versions: <FIXED-VERSIONS>
Vulnerability Type: File Disclosure, Directory Traversal
Security Risk: high
Vendor URL: https://docs.python.org/2/library/cgihttpserver.html
Vendor Status: notified
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2014-008
Advisory Status: private
CVE: GENERIC-MAP-NOMATCH
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=GENERIC-MAP-NOMATCH


Introduction
============

The CGIHTTPServer module defines a request-handler class, interface
compatible with BaseHTTPServer. BaseHTTPRequestHandler and inherits
behavior from SimpleHTTPServer. SimpleHTTPRequestHandler but can also
run CGI scripts.

(from the Python documentation)

More Details
============

The CGIHTTPServer module can be used to set up a simple HTTP server with
CGI scripts. A sample server script in Python may look like the
following:

------------------------------------------------------------------------
#!/usr/bin/env python2

import CGIHTTPServer
import BaseHTTPServer

if __name__ == "__main__":
    server = BaseHTTPServer.HTTPServer
    handler = CGIHTTPServer.CGIHTTPRequestHandler
    server_address = ("", 8000)
    # Note that only /cgi-bin will work:
    handler.cgi_directories = ["/cgi-bin", "/cgi-bin/subdir"]
    httpd = server(server_address, handler)
    httpd.serve_forever()
------------------------------------------------------------------------

This server should execute any scripts located in the subdirectory
"cgi-bin". A sample CGI script can be placed in that directory, for
example a script like the following:

------------------------------------------------------------------------
#!/usr/bin/env python2
import json
import sys

db_credentials = "SECRET"
sys.stdout.write("Content-type: text/json\r\n\r\n")
sys.stdout.write(json.dumps({"text": "This is a Test"}))
------------------------------------------------------------------------

The Python library CGIHTTPServer.py implements the CGIHTTPRequestHandler
class which inherits from SimpleHTTPServer.SimpleHTTPRequestHandler:

class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
[...]
    def do_GET(self):
        """Serve a GET request."""
        f = self.send_head()
        if f:
            try:
                self.copyfile(f, self.wfile)
            finally:
                f.close()

    def do_HEAD(self):
        """Serve a HEAD request."""
        f = self.send_head()
        if f:
            f.close()

    def translate_path(self, path):
    [...]
        path = posixpath.normpath(urllib.unquote(path))
        words = path.split('/')
        words = filter(None, words)
        path = os.getcwd()
        [...]

The CGIHTTPRequestHandler class inherits, among others, the methods
do_GET() and do_HEAD() for handling HTTP GET and HTTP HEAD requests. The
class overrides send_head() and implements several new methods, such as
do_POST(), is_cgi() and run_cgi():

class CGIHTTPRequestHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
[...]
    def do_POST(self):
        [...]
        if self.is_cgi():
            self.run_cgi()
        else:
            self.send_error(501, "Can only POST to CGI scripts")

    def send_head(self):
        """Version of send_head that support CGI scripts"""
        if self.is_cgi():
            return self.run_cgi()
        else:
            return SimpleHTTPServer.SimpleHTTPRequestHandler.send_head(self)

    def is_cgi(self):
        [...]
        collapsed_path = _url_collapse_path(self.path)
        dir_sep = collapsed_path.find('/', 1)
        head, tail = collapsed_path[:dir_sep], collapsed_path[dir_sep+1:]
        if head in self.cgi_directories:
            self.cgi_info = head, tail
            return True
        return False
[...]
    def run_cgi(self):
        """Execute a CGI script."""
        dir, rest = self.cgi_info

        [...]

        # dissect the part after the directory name into a script name &
        # a possible additional path, to be stored in PATH_INFO.
        i = rest.find('/')
        if i >= 0:
            script, rest = rest[:i], rest[i:]
        else:
            script, rest = rest, ''

        scriptname = dir + '/' + script
        scriptfile = self.translate_path(scriptname)
        if not os.path.exists(scriptfile):
            self.send_error(404, "No such CGI script (%r)" % scriptname)
            return
        if not os.path.isfile(scriptfile):
            self.send_error(403, "CGI script is not a plain file (%r)" %
                            scriptname)
            return
        [...]
[...]

For HTTP GET requests, do_GET() first invokes send_head(). That method
calls is_cgi() to determine whether the requested path is to be executed
as a CGI script. The is_cgi() method uses _url_collapse_path() to
normalize the path, i.e. remove extraneous slashes (/),current directory
(.), or parent directory (..) elements, taking care not to permit
directory traversal below the document root. The is_cgi() function
returns True when the first path element is contained in the
cgi_directories list. As _url_collaps_path() and is_cgi() never URL
decode the path, replacing the forward slash after the CGI directory in
the URL to a CGI script with the URL encoded variant %2f leads to
is_cgi() returning False. This will make CGIHTTPRequestHandler's
send_head() then invoke its parent's send_head() method which translates
the URL path to a file system path using the translate_path() method and
then outputs the file's contents raw. As translate_path() URL decodes
the path, this then succeeds and discloses the CGI script's file
contents:

$ curl http://localhost:8000/cgi-bin%2ftest.py
#!/usr/bin/env python2
import json
import sys

db_credentials = "SECRET"
sys.stdout.write("Content-type: text/json\r\n\r\n")
sys.stdout.write(json.dumps({"text": "This is a Test"}))

Similarly, the CGIHTTPRequestHandler can be tricked into executing CGI
scripts that would normally not be executable. The class normally only
allows executing CGI scripts that are direct children of one of the
directories listed in cgi_directories. Furthermore, only direct
subdirectories of the document root (the current working directory) can
be valid CGI directories.

This can be seen in the following example. Even though the sample server
shown above includes "/cgi-bin/subdir" as part of the request handler's
cgi_directories, a CGI script named test.py in that directory is not
executed:

$ curl http://localhost:8000/cgi-bin/subdir/test.py
[...]
<p>Error code 403.
<p>Message: CGI script is not a plain file ('/cgi-bin/subdir').
[...]

Here, is_cgi() set self.cgi_info to ('/cgi-bin', 'subdir/test.py') and
returned True. Next, run_cgi() further dissected these paths to perform
some sanity checks, thereby mistakenly assuming subdir to be the
executable script's filename and test.py to be path info. As subdir is
not an executable file, run_cgi() returns an error message. However, if
the forward slash between subdir and test.py is replaced with %2f,
invoking the script succeeds:

$ curl http://localhost:8000/cgi-bin/subdir%2ftest.py
{"text": "This is a Test"}

This is because neither is_cgi() nor run_cgi() URL decode the path
during processing until run_cgi() tries to determine whether the target
script is an executable file. More specifically, as subdir%2ftest.py
does not contain a forward slash, it is not split into the script name
subdir and path info test.py, as in the previous example.

Similarly, using URL encoded forward slashes, executables outside of a
CGI directory can be executed:

$ curl http://localhost:8000/cgi-bin/..%2ftraversed.py
{"text": "This is a Test"}

Workaround
==========

Subclass CGIHTTPRequestHandler and override the is_cgi() method  with a
variant that first URL decodes the supplied path, for example:

class FixedCGIHTTPRequestHandler(CGIHTTPServer.CGIHTTPRequestHandler):
    def is_cgi(self):
        self.path = urllib.unquote(self.path)
        return CGIHTTPServer.CGIHTTPRequestHandler.is_cgi(self)

Fix
===

<FIX>


Security Risk
=============

The vulnerability can be used to gain access to the contents of CGI
binaries or the source code of CGI scripts. This may reveal sensitve
information, for example access credentials. This can greatly help
attackers in mounting further attacks and is therefore considered to
pose a high risk. Furthermore attackers may be able to execute code that
was not intended to be executed. 

The CGIHTTPServer code does contain this warning:
"SECURITY WARNING: DON'T USE THIS CODE UNLESS YOU ARE INSIDE A FIREWALL"
Even when used on a local computer this may allow other local users to
execute code in the context of another user.

----------
components: Library (Lib)
messages: 220603
nosy: benjamin.peterson
priority: critical
severity: normal
status: open
title: CGIHTTPServer File Disclosure
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun 15 06:00:26 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jun 2014 04:00:26 +0000
Subject: [New-bugs-announce] [issue21767] singledispatch docs should
	explicitly mention support	for abstract base classes
Message-ID: <1402804826.39.0.801339966603.issue21767@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

functools.singledispatch is integrated with the abc module for fast single dispatch even in the absence of concrete inheritance. However, this isn't obvious from the documentation, so users may not realise they can register a single ABC with the generic function, and then multiple classes with the ABC, rather than having to register each class with the generic function directly.

----------
components: Library (Lib)
messages: 220611
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: singledispatch docs should explicitly mention support for abstract base classes
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun 15 10:26:03 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 15 Jun 2014 08:26:03 +0000
Subject: [New-bugs-announce] [issue21768] Fix a NameError in test_pydoc
Message-ID: <1402820763.05.0.689844101555.issue21768@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

There's no 'o' in test_pydoc.TestDescriptions.test_builtin, but 'name'.

----------
components: Tests
files: test_pydoc_nameerror.patch
keywords: patch
messages: 220618
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Fix a NameError in test_pydoc
versions: Python 3.5
Added file: http://bugs.python.org/file35642/test_pydoc_nameerror.patch

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

From report at bugs.python.org  Sun Jun 15 10:43:52 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 15 Jun 2014 08:43:52 +0000
Subject: [New-bugs-announce] [issue21769] Fix a NameError in test_descr
Message-ID: <1402821832.43.0.295083108794.issue21769@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi. Here's a patch which uses `self.fail` in test_descr instead of `raise TestFailed`.

----------
components: Tests
files: test_descr_nameerror.patch
keywords: patch
messages: 220619
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Fix a NameError in test_descr
versions: Python 3.5
Added file: http://bugs.python.org/file35643/test_descr_nameerror.patch

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

From report at bugs.python.org  Sun Jun 15 11:18:06 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 15 Jun 2014 09:18:06 +0000
Subject: [New-bugs-announce] [issue21770] Module not callable in
	script_helper.py
Message-ID: <1402823886.54.0.105174822288.issue21770@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Using make_zip_pkg from script_helper with compiled=True will lead to the following failure:

Traceback (most recent call last):
  File "D:\Projects\cpython\lib\test\test_cmd_line_script.py", line 305, in test_module_in_subpackage_in_zipfile
    zip_name, run_name = _make_test_zip_pkg(script_dir, 'test_zip', 'test_pkg', 'script', depth=2)
  File "D:\Projects\cpython\lib\test\test_cmd_line_script.py", line 86, in _make_test_zip_pkg
    source, depth, compiled=True)
  File "D:\Projects\cpython\lib\test\script_helper.py", line 158, in make_zip_pkg
    init_name = py_compile(init_name, doraise=True)
TypeError: 'module' object is not callable

The attached patch fixes this.

----------
components: Tests
files: script_helper_fix.patch
keywords: patch
messages: 220622
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Module not callable in script_helper.py
versions: Python 3.5
Added file: http://bugs.python.org/file35644/script_helper_fix.patch

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

From report at bugs.python.org  Sun Jun 15 16:07:16 2014
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Sun, 15 Jun 2014 14:07:16 +0000
Subject: [New-bugs-announce] [issue21771] name of 2nd parameter to
	itertools.groupby()
Message-ID: <1402841236.86.0.756808540729.issue21771@psf.upfronthosting.co.za>


New submission from Uwe Kleine-K?nig:

The name of the 2nd parameter to itertools.groupby() is documented inconsitently. Sometimes it's "key", sometimes "keyfunc". The code actually uses "key", so I adapted all occurences I found to "key".

>>> from itertools import groupby
>>> groupby.__doc__
'groupby(iterable[, keyfunc]) -> create an iterator which returns\n(key, sub-iterator) grouped by each value of key(value).\n'

>>> groupby([], keyfunc=lambda x: x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'keyfunc' is an invalid keyword argument for this function

>>> groupby([], key=lambda x: x)
<itertools.groupby object at 0x7fee025d2048>

----------
assignee: docs at python
components: Documentation
files: groupby-keyfunc.patch
keywords: patch
messages: 220639
nosy: docs at python, ukl
priority: normal
severity: normal
status: open
title: name of 2nd parameter to itertools.groupby()
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35645/groupby-keyfunc.patch

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

From report at bugs.python.org  Sun Jun 15 19:32:30 2014
From: report at bugs.python.org (Tor Colvin)
Date: Sun, 15 Jun 2014 17:32:30 +0000
Subject: [New-bugs-announce] [issue21772] platform.uname() not EINTR safe
Message-ID: <1402853550.81.0.562777788511.issue21772@psf.upfronthosting.co.za>


New submission from Tor Colvin:

platform.uname() periodically spews EINTR errors on mac - so use subproces.communicate() which is EINTR safe after http://bugs.python.org/issue1068268

Calling f.read() on naked os.open() output can produce "IOError: [Errno 4] Interrupted system call". Attached is a suggested fix.

----------
files: platform.py.fix
messages: 220654
nosy: Tor.Colvin
priority: normal
severity: normal
status: open
title: platform.uname() not EINTR safe
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/file35646/platform.py.fix

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

From report at bugs.python.org  Sun Jun 15 22:09:13 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 15 Jun 2014 20:09:13 +0000
Subject: [New-bugs-announce] [issue21773] Fix a NameError in test_enum
Message-ID: <1402862953.59.0.696190178474.issue21773@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

There's a bug in test_enum.TestStdLib.test_pydoc, print_diffs is undefined and using assertEqual seems to be clearer.

----------
components: Tests
files: test_enum.patch
keywords: patch
messages: 220669
nosy: Claudiu.Popa, ethan.furman
priority: normal
severity: normal
status: open
title: Fix a NameError in test_enum
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35650/test_enum.patch

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

From report at bugs.python.org  Sun Jun 15 23:05:11 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 15 Jun 2014 21:05:11 +0000
Subject: [New-bugs-announce] [issue21774] Fix a NameError in xml.dom.minidom
Message-ID: <1402866311.66.0.898311617544.issue21774@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi. This patch fixes a NameError found in xml.dom.minidom. Here's an example for reproducing it:


from xml.dom import minidom
dom = minidom.parseString("<a>1</a>")
pi = dom.createProcessingInstruction('xml-stylesheet',
                                     'type="text/xsl" href="mystyle.xslt"')
pi.nodeValue = "4"

with output:


Traceback (most recent call last):
  File "a.py", line 5, in <module>
    pi.nodeValue = "4"
  File "C:\Python34\lib\xml\dom\minidom.py", line 979, in _set_nodeValue
    self.data = data
NameError: name 'data' is not defined

----------
components: Library (Lib)
files: minidom.patch
keywords: patch
messages: 220673
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Fix a NameError in xml.dom.minidom
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35652/minidom.patch

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

From report at bugs.python.org  Sun Jun 15 23:37:40 2014
From: report at bugs.python.org (Greg Ward)
Date: Sun, 15 Jun 2014 21:37:40 +0000
Subject: [New-bugs-announce] [issue21775] shutil.copytree() crashes copying
	to VFAT on Linux:	AttributeError: 'PermissionError' object
	has no attribute 'winerror'
Message-ID: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za>


New submission from Greg Ward:

When using shutil.copytree() on Linux to copy to a VFAT filesystem, it crashes like this:

Traceback (most recent call last):
  File "/data/src/cpython/3.4/Lib/shutil.py", line 336, in copytree
    copystat(src, dst)
  File "/data/src/cpython/3.4/Lib/shutil.py", line 190, in copystat
    lookup("chmod")(dst, mode, follow_symlinks=follow)
PermissionError: [Errno 1] Operation not permitted: '/mnt/example_nt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "copytree-crash.py", line 14, in <module>
    shutil.copytree('PC/example_nt', '/mnt/example_nt')
  File "/data/src/cpython/3.4/Lib/shutil.py", line 339, in copytree
    if why.winerror is None:
AttributeError: 'PermissionError' object has no attribute 'winerror'

I am *not* complaining about the PermissionError. That has been issue1545. Rather, I'm complaining about the crash that happens while attempting to handle the PermissionError.

Reproducing this is fairly easy, although it requires root privilege.

1. dd if=/dev/zero of=dummy bs=1024 count=1024
2. mkfs.vfat -v dummy
3. sudo mount -o loop /tmp/dummy /mnt

Then create the reproduction script in the root of Python's source dir:

cat > copytree-crash.py <<EOF
import os
import shutil

# assumptions:
#   1. /mnt is a directory writeable by current user
#   2. /mnt is a VFAT filesystem
#   3. current OS is Linux-ish

if os.path.exists('/mnt/example_nt'):
    print('cleaning up')
    shutil.rmtree('/mnt/example_nt')

print('copying')
shutil.copytree('PC/example_nt', '/mnt/example_nt')
EOF

and run it:

sudo ./python copytree-crash.py

Crash happens as documented above.

----------
components: Library (Lib)
messages: 220676
nosy: gward
priority: normal
severity: normal
status: open
title: shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror'
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 16 11:33:29 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 16 Jun 2014 09:33:29 +0000
Subject: [New-bugs-announce] [issue21776] distutils.upload uses the wrong
	order of exceptions
Message-ID: <1402911209.04.0.940354382674.issue21776@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hi. Currently, distutils.command.upload has this code:

try:
    result = urlopen(request)
    status = result.getcode()
    reason = result.msg
except OSError as e:
    self.announce(str(e), log.ERROR)
    return
except HTTPError as e:
    status = e.code
    reason = e.msg

This is wrong because HTTPError is a subclass of OSError and OSError branch will be chosen in case HTTPError is raised. The HTTPError branch was added in 4373f0e4eb21, but after a while socket.error became an alias for OSError, as well for HTTPError. This patch also adds a `return` in order to prevent an UnboundLocalError (found in issue10367 as well), but it can be removed if other solutions are preferable.

----------
components: Distutils
files: distutils.patch
keywords: patch
messages: 220705
nosy: Claudiu.Popa, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.upload uses the wrong order of exceptions
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35653/distutils.patch

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

From report at bugs.python.org  Mon Jun 16 13:36:45 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jun 2014 11:36:45 +0000
Subject: [New-bugs-announce] [issue21777] Separate out documentation of
	binary sequence methods
Message-ID: <1402918605.38.0.604956966245.issue21777@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

There are currently no dedicated docs for the bytes and bytearray methods - the relevant section just refers back to the str methods. This isn't sufficient, since the str methods cover of lot of stuff related to Unicode that isn't relevant to the binary sequence types, and it doesn't cleanly cover the differences either (like the fact that several methods accept integers).

I've started work on a patch that documents the binary APIs explicitly, although bytes and bytearray still share docs. The methods are grouped into three categories:

- work with arbitrary binary data
- assume ASCII compatibility by default, but can still be used with arbitrary binary data when given suitable arguments
- can only be used safely with data in an ASCII compatible format

I've worked through and updated the new entries for the first category, but the latter two categories are still just copy-and-paste from the str docs.

----------
assignee: ncoghlan
components: Documentation
files: separate_binary_sequence_docs.diff
keywords: patch
messages: 220711
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Separate out documentation of binary sequence methods
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35654/separate_binary_sequence_docs.diff

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

From report at bugs.python.org  Mon Jun 16 16:03:24 2014
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 16 Jun 2014 14:03:24 +0000
Subject: [New-bugs-announce] [issue21778] PyBuffer_FillInfo() from 3.3
Message-ID: <1402927404.66.0.0840543943961.issue21778@psf.upfronthosting.co.za>


New submission from Armin Rigo:

Following the documentation at https://docs.python.org/3/c-api/buffer.html, if we write a custom object in C with a getbufferproc that simply returns PyBuffer_FillInfo(...), then it works fine up to Python 3.2 but segfaults in Python 3.3 depending on what we do with it.  The segfault is caused by memoryobject.c:last_dim_is_contiguous(), which reads from the "strides" array without checking that it is not NULL.

Attached the simplest example of C extension module I could make.  When executing this:

>>> import xy
>>> m=memoryview(bytearray(b"abcdef"))
>>> m[:5] = xy.gm

...it segfaults in Python 3.3.  (I'm told it works fine in 3.2 and segfaults in 3.4 as well, but didn't confirm it.)

----------
messages: 220721
nosy: arigo
priority: normal
severity: normal
status: open
title: PyBuffer_FillInfo() from 3.3

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

From report at bugs.python.org  Mon Jun 16 17:35:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Jun 2014 15:35:04 +0000
Subject: [New-bugs-announce] [issue21779] est_multiprocessing_spawn fails
	when ran with -Werror
Message-ID: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -Werror -m test.regrtest -v -m test_sys_exit test_multiprocessing_spawn
== CPython 3.5.0a0 (default:149cc6364180+, Jun 12 2014, 15:45:54) [GCC 4.6.3]
==   Linux-3.8.0-36-generic-i686-with-debian-wheezy-sid little-endian
==   hash algorithm: siphash24 32bit
==   /home/serhiy/py/cpython/build/test_python_9425
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_multiprocessing_spawn
test_sys_exit (test.test_multiprocessing_spawn.WithProcessesTestSubclassingProcess) ... Exception ignored in: <_io.FileIO name='@test_9425_tmp' mode='wb'>
ResourceWarning: unclosed file <_io.TextIOWrapper name='@test_9425_tmp' mode='w' encoding='UTF-8'>
FAIL

======================================================================
FAIL: test_sys_exit (test.test_multiprocessing_spawn.WithProcessesTestSubclassingProcess)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/_test_multiprocessing.py", line 483, in test_sys_exit
    self.assertEqual(f.read().rstrip(), str(reason))
AssertionError: "[1, 2, 3]\nException ignored in: <_io.Fi[123 chars]-8'>" != '[1, 2, 3]'
- [1, 2, 3]
?          -
+ [1, 2, 3]- Exception ignored in: <_io.FileIO name='/dev/null' mode='rb'>
- ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

----------------------------------------------------------------------
Ran 1 test in 1.247s

FAILED (failures=1)
test test_multiprocessing_spawn failed
1 test failed:
    test_multiprocessing_spawn

----------
components: Tests
messages: 220732
nosy: jnoller, sbt, serhiy.storchaka
priority: normal
severity: normal
status: open
title: est_multiprocessing_spawn fails when ran with -Werror
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jun 16 18:13:10 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Jun 2014 16:13:10 +0000
Subject: [New-bugs-announce] [issue21780] make unicodedata module 64-bit safe
Message-ID: <1402935190.8.0.797585156018.issue21780@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Follow-up of issue #8677: patch to make the unicodedata module 64-bit safe.

----------
files: unicodedata_64bit.patch
keywords: patch
messages: 220734
nosy: haypo
priority: normal
severity: normal
status: open
title: make unicodedata module 64-bit safe
versions: Python 3.5
Added file: http://bugs.python.org/file35657/unicodedata_64bit.patch

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

From report at bugs.python.org  Mon Jun 16 18:18:56 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Jun 2014 16:18:56 +0000
Subject: [New-bugs-announce] [issue21781] make _ssl module 64-bit clean
Message-ID: <1402935536.94.0.808370256195.issue21781@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Follow-up of issue #8677: patch to make the _ssl module 64-bit clean.

----------
files: ssl_64bit.patch
keywords: patch
messages: 220736
nosy: haypo
priority: normal
severity: normal
status: open
title: make _ssl module 64-bit clean
versions: Python 3.5
Added file: http://bugs.python.org/file35658/ssl_64bit.patch

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

From report at bugs.python.org  Mon Jun 16 20:36:54 2014
From: report at bugs.python.org (Giacomo Alzetta)
Date: Mon, 16 Jun 2014 18:36:54 +0000
Subject: [New-bugs-announce] [issue21782] hashable documentation error:
	shouldn't mention id
Message-ID: <1402943814.73.0.280307813498.issue21782@psf.upfronthosting.co.za>


New submission from Giacomo Alzetta:

The documentation for hashable in the glossary (https://docs.python.org/3.4/reference/datamodel.html#object.__hash__) is incorrect:

they all compare unequal (except with themselves), **and their hash value is their id().**

It is *not* true that their hash is their id (see relevant SO question: http://stackoverflow.com/questions/24249729/user-defined-class-hash-and-id-and-doc)

Also the documentation for __hash__ (https://docs.python.org/3.4/reference/datamodel.html#object.__hash__) doesn't even mention id().

----------
assignee: docs at python
components: Documentation
messages: 220746
nosy: Giacomo.Alzetta, docs at python
priority: normal
severity: normal
status: open
title: hashable documentation error: shouldn't mention id
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun 16 22:27:57 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Mon, 16 Jun 2014 20:27:57 +0000
Subject: [New-bugs-announce] [issue21783] smtpd.py does not allow multiple
	helo/ehlo commands
Message-ID: <1402950477.07.0.805297062536.issue21783@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

Sending HELO or EHLO more then once causes smtpd.SMTPChannel to respond with b'503 Duplicate HELO/EHLO\r\n' (see Lib/test/test_smtpd.py:124 for an example).

My interpretation of RFC 821, section 4.1.1.5 is that multiple HELO commands are fine outside a mail transaction and a second HELO is eauivalent to a RSET during a mail transaction (undoing any changes made by previous greetings).

I would propose to reject greetings during mail transactiond (thats what RSET is for) and else accept them. The question is how we should handle backwards compatibility here.

I am willing to work on this right after #21725.

----------
components: email
messages: 220754
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: smtpd.py does not allow multiple helo/ehlo commands
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun 17 04:48:32 2014
From: report at bugs.python.org (abraithwaite)
Date: Tue, 17 Jun 2014 02:48:32 +0000
Subject: [New-bugs-announce] [issue21784] __init__.py can be a directory
Message-ID: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>


New submission from abraithwaite:

Is this expected?  It was very confusing when I cloned a repo that didn't have the __init__.py there when I had just made it, but of course git doesn't track files, only directories.  I had accidentaly done mkdir instead of touch.

$ mkdir pkg/__init__.py
$ touch pkg/foobar.py
$ python
Python 3.4.1 (default, May 19 2014, 17:23:49) 
[GCC 4.9.0 20140507 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg import foobar
>>> foobar
<module 'pkg.foobar' from '/home/abraithwaite/pkg/foobar.py'>
>>>

----------
assignee: docs at python
components: Documentation
messages: 220787
nosy: abraithwaite, docs at python
priority: normal
severity: normal
status: open
title: __init__.py can be a directory
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 17 07:16:03 2014
From: report at bugs.python.org (Konstantin Tretyakov)
Date: Tue, 17 Jun 2014 05:16:03 +0000
Subject: [New-bugs-announce] [issue21785] __getitem__ and __setitem__ try to
	be smart when invoked	with negative slice indices
Message-ID: <1402982163.43.0.0546629268469.issue21785@psf.upfronthosting.co.za>


New submission from Konstantin Tretyakov:

Consider the following example:

class A:
     def __getitem__(self, index):
         return True

If you invoke A()[-1], everything is fine. However, if you invoke A()[-1:2], you get an "AttributeError: A instance has no attribute '__len__'".

Moreover, if you define __len__ for your class, you will discover that __getitem__ will act "smart" and modify slice you are passing into the function. Check this out:

class A:
    def __getitem__(self, index):
        return index.start
    def __len__(self):
        return 10

Now A()[-1:10] outputs "9". The same kind of argument-mangling happens within __setitem__.

This is completely unintuitive and contrary to what I read in the docs (https://docs.python.org/2/reference/datamodel.html#object.__getitem__):
"Note that the special interpretation of negative indexes (if the class wishes to emulate a sequence type) is up to the __getitem__() method.".

Especially intuitive is the fact that if you do A()[slice(-1,10)] or A().__getitem__(slice(-1,10)), no special treatment is done for the -1, everything works fine and the __len__ method is not invoked.

As far as I understand, the root cause is the behaviour of STORE_SLICE+3 command, which tries to be too smart.

I have discovered this within code where slice indexing was used to insert arbitrary intervals into a data structure (hence using negative numbers would be totally fine), and obviuosly such behaviour broke the whole idea, albeit it was nontrivial to debug and discover.

This does not seem to be a problem for Python 3.3, however I believe fixing this in Python 2.7 is important as well.

----------
components: Interpreter Core
messages: 220792
nosy: kt
priority: normal
severity: normal
status: open
title: __getitem__ and __setitem__ try to be smart when invoked with negative slice indices
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 17 07:27:42 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Tue, 17 Jun 2014 05:27:42 +0000
Subject: [New-bugs-announce] [issue21786] Use self.assertEqual in test_pydoc
Message-ID: <1402982862.21.0.976348306375.issue21786@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hello. Here's a patch which uses self.assertEqual in various places across test_pydoc, instead of the current idiom:

if result != expected_text:
   print_diffs(expected_text, result)
   self.fail("outputs are not equal, see diff above")

----------
components: Tests
files: modernize_test_pydoc.patch
keywords: patch
messages: 220793
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Use self.assertEqual in test_pydoc
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35667/modernize_test_pydoc.patch

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

From report at bugs.python.org  Tue Jun 17 08:58:02 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Jun 2014 06:58:02 +0000
Subject: [New-bugs-announce] [issue21787] Idle: make 3.x
	Hyperparser.get_expression recognize ...
Message-ID: <1402988282.32.0.521097525019.issue21787@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

3.0 introduced ... as Ellipsis literal. Test: add '...\n' to the end of the test code.  In test_get_expression, add at the end
        p = get('12.3')
        self.assertEqual(p.get_expression(), '...')
which now fails with AssertionError: '' != '...'.

----------
messages: 220800
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: make 3.x  Hyperparser.get_expression recognize ...
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 17 09:40:27 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Jun 2014 07:40:27 +0000
Subject: [New-bugs-announce] [issue21788] Rework Python finalization
Message-ID: <1402990827.19.0.536092854004.issue21788@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Hi,

During the development of Python 3.4, I tried to emit warnings if a file is destroyed without being explicitly closed. The warnings were not emited in threads during Python finalization. Here are related changes:

- Issue #19421: "FileIO destructor imports indirectly the io module at exit"
- Issue #19424: "_warnings: patch to avoid conversions from/to UTF-8"
- Issue #19442: "Python crashes when a warning is emitted during shutdown"
- Change in Python shutdown: issue #19466 "Clear state of threads earlier in Python shutdown"
- Regression => issue #20526

The change #19466 had to be reverted a few days before the release of Python 3.4.0 because it caused the regression #20526.

I'm still not convinced that #20526 was a new bug. IMO the bug still exists, but it is just less likely without the change #19466.

There is still something wrong in Python finalization, so I open this issue to rework it.

The goal is to get warnings in test_4_daemon_threads() of test_threading. I attached the test as a Python script.

----------
files: test_4_daemon_threads.py
messages: 220804
nosy: benjamin.peterson, haypo
priority: normal
severity: normal
status: open
title: Rework Python finalization
versions: Python 3.5
Added file: http://bugs.python.org/file35669/test_4_daemon_threads.py

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

From report at bugs.python.org  Tue Jun 17 15:00:08 2014
From: report at bugs.python.org (Jan Varho)
Date: Tue, 17 Jun 2014 13:00:08 +0000
Subject: [New-bugs-announce] [issue21789] Broken link to PEP 263 in Python
	2.7 error message
Message-ID: <1403010008.76.0.912286060236.issue21789@psf.upfronthosting.co.za>


New submission from Jan Varho:

When trying to run a file with non-ASCII symbols without declaring an encoding, python 2.7 gives the following error:

  File "foo.py", line 2
SyntaxError: Non-ASCII character '\xc3' in file fo.py on line 2, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details

That link is broken, however. The attached patch fixes the link.

Python 3 (.4) has the correct link already.

----------
files: 0001-Fix-link-to-PEP-263-in-encoding-error-message.patch
keywords: patch
messages: 220821
nosy: otus
priority: normal
severity: normal
status: open
title: Broken link to PEP 263 in Python 2.7 error message
versions: Python 2.7
Added file: http://bugs.python.org/file35670/0001-Fix-link-to-PEP-263-in-encoding-error-message.patch

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

From report at bugs.python.org  Tue Jun 17 17:40:24 2014
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Jun 2014 15:40:24 +0000
Subject: [New-bugs-announce] [issue21790] Change blocksize in http.client to
	the value of	resource.getpagesize
Message-ID: <1403019624.98.0.809499942301.issue21790@psf.upfronthosting.co.za>


New submission from Demian Brecht:

When sending data, the blocksize is currently hardcoded to 8192. It should likely be set to the value of resource.getpagesize().

----------
components: Library (Lib)
files: set_blocksize_to_getpagesize.diff
keywords: patch
messages: 220839
nosy: dbrecht
priority: normal
severity: normal
status: open
title: Change blocksize in http.client to the value of resource.getpagesize
versions: Python 3.5
Added file: http://bugs.python.org/file35671/set_blocksize_to_getpagesize.diff

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

From report at bugs.python.org  Tue Jun 17 18:23:08 2014
From: report at bugs.python.org (Eric Radman)
Date: Tue, 17 Jun 2014 16:23:08 +0000
Subject: [New-bugs-announce] [issue21791] Proper return status of os.WNOHANG
	is not always (0, 0)
Message-ID: <1403022188.82.0.702725813338.issue21791@psf.upfronthosting.co.za>


New submission from Eric Radman:

The documentation for the WNOHANG flag (https://docs.python.org/3.4/library/os.html#os.WNOHANG) suggests that a return value of (0, 0) indicates success. This is not always true, the second value may contain a value even on success. On OpenBSD 5.5 this is an exaple status of a process that is still running:

pid, status = os.waitpid(pid, os.WNOHANG)
(0, -168927460)

It would be more accurate to say that if pid==0 then the process is running and that status is platform dependent.

----------
assignee: docs at python
components: Documentation
messages: 220843
nosy: docs at python, eradman
priority: normal
severity: normal
status: open
title: Proper return status of os.WNOHANG is not always (0, 0)
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 17 20:41:11 2014
From: report at bugs.python.org (Nathanel Titane)
Date: Tue, 17 Jun 2014 18:41:11 +0000
Subject: [New-bugs-announce] [issue21792] Invitation to connect on LinkedIn
Message-ID: <17216793.30165653.1403030460903.JavaMail.app@ela4-app2322.prod>


New submission from Nathanel Titane:

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

Python,

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

- Nathanel

Nathanel Titane
Industrial Designer at TNDesigns Industrial + Graphic design solutions
Montreal, Canada Area

Confirm that you know Nathanel Titane:
https://www.linkedin.com/e/-3qcne3-hwjk4065-6h/isd/5884736256985808896/G43uJ4zE/?hs=false&tok=0jzJwnzwAxPSg1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hwjk4065-6h/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I7283032682_1/?hs=false&tok=05rqftCWUxPSg1

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

----------
messages: 220856
nosy: nathanel.titane
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

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

From report at bugs.python.org  Tue Jun 17 21:02:36 2014
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Jun 2014 19:02:36 +0000
Subject: [New-bugs-announce] [issue21793] httplib client/server status
	refactor
Message-ID: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za>


New submission from Demian Brecht:

This patch is a follow up to an out of scope comment made by R. David Murray in #20898 (http://bugs.python.org/issue20898#msg213771).

In a nutshell, there is some redundancy between http.client and http.server insofar as the definition of http status code, names and descriptions go. The included patch is a stab at cleaning some of this up while remaining backwards compatible and is intended to solicit feedback before finishing work.

TODOs:
* Populate descriptions for status codes
* Documentation
* Tests (?)

----------
components: Library (Lib)
files: refactor_http_status_codes.patch
keywords: patch
messages: 220860
nosy: dbrecht, r.david.murray
priority: normal
severity: normal
status: open
title: httplib client/server status refactor
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35672/refactor_http_status_codes.patch

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

From report at bugs.python.org  Tue Jun 17 21:12:26 2014
From: report at bugs.python.org (the mulhern)
Date: Tue, 17 Jun 2014 19:12:26 +0000
Subject: [New-bugs-announce] [issue21794] stack frame contains name of
	wrapper method, not that of wrapped method
Message-ID: <1403032346.55.0.812128446286.issue21794@psf.upfronthosting.co.za>


New submission from the mulhern:

>>> def decorator(f):
...     @functools.wraps(f)
...     def new_func(self, junk):
...             stack = inspect.stack()
...             for i, frame in enumerate(stack):
...                     print("%s" % frame[3])
...             f(self, junk)
...     return new_func
... 
>>> @decorator
... def junk(self, p):
...     print("%s" % junk.__name__)
... 
>>> junk("a", "b")
new_func
<module>
junk
>>> junk.__name__
'junk'


Note that the wrapper function itself inspects the stack, printing out the names of methods on the stack.
Note that "junk", the name of the wrapped function does not appear on the stack, it is only printed out by the junk method itself.

I think that the name of the function at the top of the stack should be the name of the wrapped function, not of its wrapper. The name of the wrapper function should not appear at all.

----------
components: Interpreter Core
messages: 220863
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: stack frame contains name of wrapper method, not that of wrapped method
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 17 21:30:01 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Tue, 17 Jun 2014 19:30:01 +0000
Subject: [New-bugs-announce] [issue21795] smtpd.SMTPServer should announce
	8BITMIME when supported
Message-ID: <1403033401.43.0.395080659803.issue21795@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

The smtpd.SMTPServer does support 8BITMIME if decode_date is False (#19662) and could be announced under this condition. The patch for #21725 already implements 8BITMIME so this can easily be done afterwards.

----------
components: email
messages: 220868
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: smtpd.SMTPServer should announce 8BITMIME when supported
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun 17 22:11:01 2014
From: report at bugs.python.org (Shal)
Date: Tue, 17 Jun 2014 20:11:01 +0000
Subject: [New-bugs-announce] [issue21796] tempfile.py", line 83,
	in <module> once_lock = _allocate_lock() thread.error: can't
	allocat	lock
Message-ID: <1403035861.92.0.338846597048.issue21796@psf.upfronthosting.co.za>


New submission from Shal:

The following error is with using python 2.7.3 on HP-UX 11.11
Very occasionally get following error. The error occurs once every 20 - 30 days. OS HP-UX 11.11

applicationCode.py is invoked via  a cgi wrapper by apache httpd .

############### ERROR LISTNG #############################

sem_init: Device busy
Traceback (most recent call last):
  File "applicationCode.py", line 4, in <module>
      import cgi

        File "local/lib/python2.7/cgi.py", line 51, in <module>
        import mimetools

        File "local/lib/python2.7/SECURITY WARNING!!
        import tempfile

        File "local/lib/python2.7/tempfile.py", line 83, in <module>
        once_lock = _allocate_lock()

        thread.error: can't allocate lock

##### END OF ERROR LISTING ##################



applicationCode.py

has line of

form = cgi.FieldStorage()

----------
components: Extension Modules
files: tempfile.py
messages: 220873
nosy: pythonbug1shal
priority: normal
severity: normal
status: open
title: tempfile.py", line 83,	in <module> once_lock = _allocate_lock() thread.error: can't allocat lock
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35675/tempfile.py

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

From report at bugs.python.org  Tue Jun 17 22:18:53 2014
From: report at bugs.python.org (Kevin Smith)
Date: Tue, 17 Jun 2014 20:18:53 +0000
Subject: [New-bugs-announce] [issue21797] mmap read of single byte accesses
	more that just that	byte
Message-ID: <1403036333.47.0.341368949906.issue21797@psf.upfronthosting.co.za>


New submission from Kevin Smith:

I am using the mmap module on Linux with python 2.7.6 to access memory-mapped IO.  The device that I am accessing implements a hardware FIFO that holds 16-bit values and pops an entry when the MSB of the entry is read.  I am trying to use the mmap module to do an 8-bit read of the LSB then an 8-bit read of the MSB, which should pop the value.  However, I am finding that the LSB read is sometimes popping the value before I read the MSB.

I am mapping the memory like this:
        self.fd = os.open ("/dev/mem", os.O_RDWR | os.O_SYNC)
        self.mempage = mmap.mmap (self.fd, mmap_size, mmap.MAP_SHARED,
                mmap.PROT_READ | mmap.PROT_WRITE, offset = pc104_base)

Then trying to read a value like this:
        val = self.mempage[pos]

The LSB of the hardware device is a lower address than the MSB.  The read of the LSB seems to sometimes overlap into a read of the MSB, which causes the following read of the MSB to be incorrect, as the value has already been popped.  Sometimes the reads of the MSB are correct; I am not sure why this behavior is not consistent across all reads.

The reads for this device need to be 8-bit, as the bus the device is connected to only supports 8-bit reads.

I think that a single-byte access of the memory mapping should only access a single byte in the underlying memory region.

----------
components: Extension Modules
messages: 220877
nosy: FazJaxton
priority: normal
severity: normal
status: open
title: mmap read of single byte accesses more that just that byte
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 17 23:10:40 2014
From: report at bugs.python.org (Gerrit Holl)
Date: Tue, 17 Jun 2014 21:10:40 +0000
Subject: [New-bugs-announce] [issue21798] Allow adding Path or str to Path
Message-ID: <1403039440.73.0.798100402294.issue21798@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

It would be great if we could "add" either str or Path to Path objects.  Currently, we can join paths only by adding a directory, or by replacing the suffix.  But sometimes we want to build up a path more directly.  With strings we can do that simply by concatenating strings.  It would be great if we could do the same with Path objects, like this:

In [2]: b = pathlib.Path("/tmp/some_base")

In [3]: b + "_name.dat"
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-939467ea0aa5> in <module>()
----> 1 b + "_name.dat"

TypeError: unsupported operand type(s) for +: 'PosixPath' and 'str'

In [4]: b + pathlib.Path("_name.dat")
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-460bf8ac7710> in <module>()
----> 1 b + pathlib.Path("_name.dat")

TypeError: unsupported operand type(s) for +: 'PosixPath' and 'PosixPath'

In [11]: b.with_name(b.name + "_name.dat")  # desired effect
Out[11]: PosixPath('/tmp/some_base_name.dat')

----------
components: Library (Lib)
messages: 220893
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: Allow adding Path or str to Path
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Jun 17 23:53:58 2014
From: report at bugs.python.org (Pat Le Cat)
Date: Tue, 17 Jun 2014 21:53:58 +0000
Subject: [New-bugs-announce] [issue21799] Py_SetPath() gives compile error:
	undefined reference to	'__imp_Py_SetPath'
Message-ID: <1403042038.73.0.889262541766.issue21799@psf.upfronthosting.co.za>


New submission from Pat Le Cat:

I use Python 3.4.1 x64 (binaries downloaded) under Windows 8.1 with mingw64 (GCC 4.9 using C++). All the other functions work fine.

Excerpt:
    Py_SetPath(L"python34.zip");
    wchar_t* pyPath = Py_GetPath();
    Py_Initialize();

----------
components: Build, Library (Lib), Windows
messages: 220902
nosy: Pat.Le.Cat
priority: normal
severity: normal
status: open
title: Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 18 01:28:22 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Tue, 17 Jun 2014 23:28:22 +0000
Subject: [New-bugs-announce] [issue21800] Implement RFC 6855 (IMAP Support
	for UTF-8) in imaplib.
Message-ID: <1403047702.77.0.884020391465.issue21800@psf.upfronthosting.co.za>


Changes by Milan Oberkirch <milan.py at oberkirch.org>:


----------
components: email
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Implement RFC 6855 (IMAP Support for UTF-8) in imaplib.
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 18 14:41:45 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Wed, 18 Jun 2014 12:41:45 +0000
Subject: [New-bugs-announce] [issue21801] inspect.signature doesn't always
	return a signature
Message-ID: <1403095305.91.0.217669494481.issue21801@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

Hello. I noticed the following behaviour while working with xmlrpc proxy methods.

>>> import inspect, xmlrpc.client
>>> proxy = xmlrpc.client.ServerProxy('http://localhost:8000')
>>> proxy.mul
<xmlrpc.client._Method object at 0x03B0C890>
>>> inspect.signature(proxy.mul)
<xmlrpc.client._Method object at 0x03B0CC90>
>>>


Now, according to the documentation, inspect.signature should return a signature or fail, but in this case it returns the actual object, which is misleading at least. This happens because _Method implements a proxy __getattr__, any accessed attribute becoming again a _Method. At the same time, inspect.signature happily uses 

try:
   obj.__signature__
except AttributeError:
   ...

to obtain the signature, if present.

The attached patch checks if __signature__ is an actual Signature object. I searched, but couldn't find any, if __signature__ can be anything, so I hope that this approach works.

----------
components: Library (Lib)
files: inspect_signature.patch
keywords: patch
messages: 220936
nosy: Claudiu.Popa, yselivanov
priority: normal
severity: normal
status: open
title: inspect.signature doesn't always return a signature
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35682/inspect_signature.patch

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

From report at bugs.python.org  Wed Jun 18 19:52:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Jun 2014 17:52:22 +0000
Subject: [New-bugs-announce] [issue21802] Reader of BufferedRWPair is not
	closed if writer's	close() fails
Message-ID: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Current implementation of BufferedRWPair.close() is:

    def close(self):
        self.writer.close()
        self.reader.close()

When self.writer.close() raises an exception, self.reader left non-closed. This can cause file description leak unless GC sweep it.

Proposed patch fixes this issue. With applied patch for issue21715 it would be a little simpler.

----------
components: IO
files: bufferedrwpair_close.patch
keywords: patch
messages: 220945
nosy: benjamin.peterson, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Reader of BufferedRWPair is not closed if writer's close() fails
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35684/bufferedrwpair_close.patch

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

From report at bugs.python.org  Wed Jun 18 21:00:51 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Jun 2014 19:00:51 +0000
Subject: [New-bugs-announce] [issue21803] Remove macro indirections in
	complexobject
Message-ID: <1403118051.82.0.958241354648.issue21803@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I thought this would make things less confusing to read.

----------
components: Interpreter Core
files: complex_macros.patch
keywords: patch
messages: 220947
nosy: mark.dickinson, pitrou
priority: low
severity: normal
stage: patch review
status: open
title: Remove macro indirections in complexobject
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35685/complex_macros.patch

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

From report at bugs.python.org  Thu Jun 19 01:14:44 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Wed, 18 Jun 2014 23:14:44 +0000
Subject: [New-bugs-announce] [issue21804] Implement thr UTF8 command (RFC
	6856) in poplib.
Message-ID: <1403133284.52.0.0735782261823.issue21804@psf.upfronthosting.co.za>


New submission from Milan Oberkirch:

The poplib classes already use Unicode internally (for everything but capability names). So to implement the UTF8 part of RFC 6856 we only need to enable the user to switch to UTF-8 mode if supported by the server.

----------
components: email
files: poputf8.patch
keywords: patch
messages: 220956
nosy: barry, jesstess, pitrou, r.david.murray, zvyn
priority: normal
severity: normal
status: open
title: Implement thr UTF8 command (RFC 6856) in poplib.
versions: Python 3.5
Added file: http://bugs.python.org/file35686/poputf8.patch

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

From report at bugs.python.org  Thu Jun 19 05:49:54 2014
From: report at bugs.python.org (d0n)
Date: Thu, 19 Jun 2014 03:49:54 +0000
Subject: [New-bugs-announce] [issue21805] Argparse Revert config_file
	defaults
Message-ID: <1403149794.76.0.705668916508.issue21805@psf.upfronthosting.co.za>


New submission from d0n:

Hi,

first of all I want to thank you (bethard) for your great work and efforts on developing argparse which is a great tool of versatile use in mostly all of my programs. 
I've faced a specific problem while implementing argparse which I have not been able to fix by the functions supplied through argparse or its functions. And here we are getting to it:

---
Lets assume I have a configuration file which sets the argparser argument of "verbose" to True. Further we assume I would have done that by reading a configuration file into an python-dictionary (maybe via ConfigParser or sth. like that) and passing it to the function "set_defaults" of the class "ArgumentParser" from argparse. 

So far so good - now I have my default set. But now my "verbose" switch still is setting the value for "verbose" to True (or False) regardless of the actual state. So, I do not want to set my value for "verbose" to True and neither I want it to set to False (or None) i want it to be set to the opposite value it has till now


{code}

def opposite(bool):
  if bool is True:
    return False
  elif bool is False:
    return True

from argparse import ArgumentParser
parser = ArgumentParser()
parser.set_defaults(**config_defaults)
parser.add_argument('-V', '--verbose', dest='vrb', action='store_const', const=opposite(config_defaults['verbose']), help='switch on/off verbosity')

{/code}


In that case I would be glad to just set my action to 'store_opposite' (or sth. like that).

I am sorry if I have missed something here or was misguiding somehow.

Best regards,
d0n

----------
components: Extension Modules
messages: 220960
nosy: bethard, d0n
priority: normal
severity: normal
status: open
title: Argparse Revert config_file defaults
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Jun 19 09:15:58 2014
From: report at bugs.python.org (ingrid)
Date: Thu, 19 Jun 2014 07:15:58 +0000
Subject: [New-bugs-announce] [issue21806] Add tests for turtle.TPen class
Message-ID: <1403162158.45.0.0956616967366.issue21806@psf.upfronthosting.co.za>


Changes by ingrid <hi at ingridcheung.com>:


----------
components: Tests
files: TPen_tests.patch
keywords: patch
nosy: ingrid, jesstess
priority: normal
severity: normal
status: open
title: Add tests for turtle.TPen class
versions: Python 3.5
Added file: http://bugs.python.org/file35688/TPen_tests.patch

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

From report at bugs.python.org  Thu Jun 19 10:12:08 2014
From: report at bugs.python.org (Omer Katz)
Date: Thu, 19 Jun 2014 08:12:08 +0000
Subject: [New-bugs-announce] [issue21807] SysLogHandler closes TCP
	connection after first message
Message-ID: <1403165528.71.0.804407602636.issue21807@psf.upfronthosting.co.za>


New submission from Omer Katz:

import logging
import logging.handlers
import socket

logger = logging.getLogger('mylogger')
handler = logging.handlers.SysLogHandler(('****', logging.handlers.SYSLOG_TCP_PORT), socktype=socket.SOCK_STREAM)
formatter = logging.Formatter('%(name)s: [%(levelname)s] %(message)s')
handler.setFormatter(formatter)

logger.addHandler(handler)

logger.info("TEST 1")
logger.info("TEST 2")

I have verified that this code only sends 'TEST 1' to Splunk and syslog-ng on both Python 2.7 and Python 3.4. After that, the connection appears closed. UDP on the other hand works just fine.

----------
components: Library (Lib)
messages: 220961
nosy: Omer.Katz
priority: normal
severity: normal
status: open
title: SysLogHandler closes TCP connection after first message
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Jun 19 12:59:05 2014
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Thu, 19 Jun 2014 10:59:05 +0000
Subject: [New-bugs-announce] [issue21808] 65001 code page not supported
Message-ID: <1403175545.64.0.775481802975.issue21808@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian:

cp65001 is purported to be an alias for utf8.

I get these results:

C:\Python27>chcp 65001
Active code page: 65001

C:\Python27>python
Python 2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale

LookupError: unknown encoding: cp65001
>>>

LookupError: unknown encoding: cp65001
>>> locale.getpreferredencoding()

LookupError: unknown encoding: cp65001
>>>




And on Python 3.4 chcp doesn't seem to have any effect:

C:\Python34>chcp 65001
Active code page: 65001

C:\Python34>python
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
'cp1252'
>>> locale.getlocale()
(None, None)
>>> locale.getlocale(locale.LC_ALL)
(None, None)

----------
components: Interpreter Core, Unicode, Windows
messages: 220964
nosy: ezio.melotti, haypo, ionel.mc
priority: normal
severity: normal
status: open
title: 65001 code page not supported
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Jun 19 15:05:14 2014
From: report at bugs.python.org (John Malmberg)
Date: Thu, 19 Jun 2014 13:05:14 +0000
Subject: [New-bugs-announce] [issue21809] Building Python3 on VMS - External
	repository
Message-ID: <1403183114.72.0.0988291504524.issue21809@psf.upfronthosting.co.za>


New submission from John Malmberg:

With issue 16136 VMS support was removed for Python V3

A test build of the in-development branch using the UNIX instruction and the current GNV product with a few minor tweaks produced a Python.exe interpreter that is somewhat functional.

Most of the issues that showed up in the build process were either bugs in the VMS C library, or that Python would prefer some additional libraries would be present.  These issues are common to porting other software to VMS, and not something that the Python project should need to concern it self with.

I have setup a repository on the Sourceforge VMS-PORTS project, and a
VMS specific discussion thread for doing the port.

https://sourceforge.net/p/vms-ports/discussion/portingprojects/thread/333ab40a/

This is not intended as a fork of the Python project, rather it is a project to provide the build and runtime environment that Python 3 will need on VMS.

Description on how to use this repository on VMS:

https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/readme

The plan is to keep the current status in this file.

https://sourceforge.net/p/vms-ports/cpython/ci/default/tree/vms_source/cpython/vms/aaa_readme.txt

----------
components: Build
hgrepos: 257
messages: 220970
nosy: John.Malmberg
priority: normal
severity: normal
status: open
title: Building Python3 on VMS - External repository
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Jun 19 21:36:34 2014
From: report at bugs.python.org (John-Mark Bell)
Date: Thu, 19 Jun 2014 19:36:34 +0000
Subject: [New-bugs-announce] [issue21810] SIGSEGV in PyObject_Malloc when
	ARENAS_USE_MMAP
Message-ID: <1403206594.61.0.272134624699.issue21810@psf.upfronthosting.co.za>


New submission from John-Mark Bell:

In low-memory scenarios, the Python 2.7 interpreter may crash as a result of failing to correctly check the return value from mmap in new_arena().

This changeset appears to be the point at which this issue was introduced: http://hg.python.org/cpython/rev/4e43e5b3f7fc

Looking at the head of the 2.7 branch in Mercurial, we see the issue is still present: http://hg.python.org/cpython/file/cf70f030a744/Objects/obmalloc.c#l595

On failure, mmap will return MAP_FAILED ((void *) -1), whereas malloc will return NULL (0). Thus, the check for allocation failure on line 601 will erroneously decide that the allocation succeeded in the mmap case.

The interpreter will subsequently crash once the invalid address is accessed. I've attached a potential fix for this issue.

----------
components: Interpreter Core
files: obmalloc.diff
keywords: patch
messages: 221013
nosy: John-Mark.Bell
priority: normal
severity: normal
status: open
title: SIGSEGV in PyObject_Malloc when ARENAS_USE_MMAP
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file35694/obmalloc.diff

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

From report at bugs.python.org  Fri Jun 20 00:24:11 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Jun 2014 22:24:11 +0000
Subject: [New-bugs-announce] [issue21811] Anticipate fixes to 3.x and 2.7
	for OS X 10.10 Yosemite	support
Message-ID: <1403216651.03.0.831203410022.issue21811@psf.upfronthosting.co.za>


New submission from Ned Deily:

Apple recently announced an upcoming public beta and anticipated fall release of the next version of OS X, 10.10 Yosemite.  As usual, developer previews of 10.10 have been made under non-disclosure since the exact details of 10.10 may change prior to the final release.  However, by inspection, there are definitely some issues in Python that will need to be addressed for 10.10 and beyond.  There are a number of places within the cpython code base where decisions are made based on either the running system version or the OS X ABI (e.g. the value of MACOSX_DEPLOYMENT_TARGET) that the interpreter was built with or is being built with.  Most of the current tests do string comparisons of these values which will not work properly with a two-digit version number ('10.10' < '10.9' --> True).  At a minimum, this will likely have the following effects:

1. When running current 3.4.1 and 2.7.7 binary installers on 10.10, building C extension modules will likely result in an incorrect universal platform name, for example, "x86_64" instead of "intel", and that could affect extension module file names and wheel or egg names.

2. In addition, when building Python on 10.10, standard library and third-party extension modules may be built with obsolete link options ("-bundle -bundle_loader python" rather than "-bundle -undefined dynamic_lookup") and some extension module builds may fail as a result.

3. Various tests in the Python test suite may fail, including test_distutils, test__osx_support, and test_sysconfig.

Note that versions of Python older than 3.4 and 2.7 are no longer eligible for bug fixes under python-dev policy but are likely to have similar and/or additional problems.  And, again, there may be other issues identified once 10.10 is released in its final form.

----------
assignee: ned.deily
components: Build, Macintosh, Tests
messages: 221042
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Anticipate fixes to 3.x and 2.7 for OS X 10.10 Yosemite support
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun 20 08:14:40 2014
From: report at bugs.python.org (Lita Cho)
Date: Fri, 20 Jun 2014 06:14:40 +0000
Subject: [New-bugs-announce] [issue21812] turtle.shapetransform doesn't
	transform the turtle on	the first call
Message-ID: <1403244880.01.0.345411438078.issue21812@psf.upfronthosting.co.za>


New submission from Lita Cho:

When you call turtle.shapetransform with a transformation matrix, nothing happens. You have to call turtle.shapesize or turtle.shearfactor first before turtle.shapetransform will take affect. Here is an example.

turtle.shapetransform(2,0,0,2) 
turtle.shapesize(1) 
turtle.shapetransform(2,0,0,2)

Nothing happens with the first call of shapetransform, but after calling shapesize, shapetransform then doubles in size, like it should.

----------
components: Library (Lib)
messages: 221068
nosy: Lita.Cho
priority: normal
severity: normal
status: open
title: turtle.shapetransform doesn't transform the turtle on the first call

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

From report at bugs.python.org  Fri Jun 20 11:18:22 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Jun 2014 09:18:22 +0000
Subject: [New-bugs-announce] [issue21813] Enhance doc of os.stat_result
Message-ID: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch creates a stat_result class in the os documentation and complete the documentation of each field. It makes possible to link directly an attribute of this class in the documentation, which is useful for the new st_file_attributes (issue #21719) for example.

----------
assignee: docs at python
components: Documentation
files: stat_result.patch
keywords: patch
messages: 221080
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Enhance doc of os.stat_result
versions: Python 3.5
Added file: http://bugs.python.org/file35704/stat_result.patch

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

From report at bugs.python.org  Fri Jun 20 12:02:12 2014
From: report at bugs.python.org (Vincent Besanceney)
Date: Fri, 20 Jun 2014 10:02:12 +0000
Subject: [New-bugs-announce] [issue21814] object.__setattr__ or
	super(...).__setattr__?
Message-ID: <1403258532.08.0.198623829613.issue21814@psf.upfronthosting.co.za>


New submission from Vincent Besanceney:

In: https://docs.python.org/2.7/reference/datamodel.html#customizing-attribute-access

Regarding the description of __setattr__ method: "For new-style classes, rather than accessing the instance dictionary, it should call the base class method with the same name, for example, object.__setattr__(self, name, value)."

Wouldn't it be more consistent for new-style classes, instead of calling "object.__setattr__(self, name, value)", to call "super(<ClassName>, self).__setattr__(name, value)"?

----------
assignee: docs at python
components: Documentation
messages: 221082
nosy: docs at python, vincentbesanceney
priority: normal
severity: normal
status: open
title: object.__setattr__ or super(...).__setattr__?
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 20 16:39:56 2014
From: report at bugs.python.org (=?utf-8?b?UmFmYcWCIFN0b8W8ZWs=?=)
Date: Fri, 20 Jun 2014 14:39:56 +0000
Subject: [New-bugs-announce] [issue21815] imaplib truncates some untagged
	responses
Message-ID: <1403275196.37.0.409307454531.issue21815@psf.upfronthosting.co.za>


New submission from Rafa? Sto?ek:

The regexp in Response_code checks for the existence of [] characters. The problem is that the strings may contain [] characters. I attach debug log which shows the data received from server and what the python extracted from it.

You can see that the PERNANENTFLAGS is truncated and everything from the ] character is lost:

(\Answered \Flagged \Draft \Deleted \Seen OIB-Seen-OIB/Social Networking $Phishing $Forwarded OIB-Seen-OIB/Home OIB-Seen-OIB/Shopping OIB-Seen-INBOX OIB-Seen-OIB/Business OIB-Seen-OIB/Entertainment $NotJunk $NotPhishing $Junk OIB-Seen-[Gmail

----------
components: Library (Lib)
messages: 221091
nosy: rafales
priority: normal
severity: normal
status: open
title: imaplib truncates some untagged responses
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 20 21:18:11 2014
From: report at bugs.python.org (Thomas Ball)
Date: Fri, 20 Jun 2014 19:18:11 +0000
Subject: [New-bugs-announce] [issue21816] OverflowError: Python int too
	large to convert to C long
Message-ID: <1403291891.37.0.500451065377.issue21816@psf.upfronthosting.co.za>


New submission from Thomas Ball:

The attached file raises the exception:

OverflowError: Python int too large to convert to C long

in Python 2.7.7, which clearly is a bug. 

The error is not present in Python 3.4.

----------
files: testint.py
messages: 221116
nosy: Thomas.Ball
priority: normal
severity: normal
status: open
title: OverflowError: Python int too large to convert to C long
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35712/testint.py

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

From report at bugs.python.org  Sat Jun 21 00:13:22 2014
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 20 Jun 2014 22:13:22 +0000
Subject: [New-bugs-announce] [issue21817]
	`concurrent.futures.ProcessPoolExecutor` swallows	tracebacks
Message-ID: <1403302402.66.0.944637105053.issue21817@psf.upfronthosting.co.za>


New submission from Ram Rachum:

When you use `concurrent.futures.ProcessPoolExecutor` and an exception is raised in the created process, it doesn't show you the traceback. This makes debugging very annoying.

Example file:

    #!python
    
    import sys
    import concurrent.futures 
    
    def f():
        # Successful assert:
        assert True
        return g()
    
    def g():
        # Hard-to-find failing assert:
        assert False
    
        
    if __name__ == '__main__':
        with concurrent.futures.ProcessPoolExecutor(max_workers=1) as executor:
            assert isinstance(executor, concurrent.futures.Executor)
            future = executor.submit(f)
            future.result()
        print('Main process finished')
        
        
If you run this under Windows, you get this: 

    Traceback (most recent call last):
      File "./bug.py", line 20, in <module>
        future.result()
      File "c:\python34\lib\concurrent\futures\_base.py", line 402, in result
        return self.__get_result()
      File "c:\python34\lib\concurrent\futures\_base.py", line 354, in __get_result
        raise self._exception
    AssertionError

This is the traceback of the main process, while we want the traceback of the process that failed.

----------
components: Library (Lib)
messages: 221128
nosy: cool-RR
priority: normal
severity: normal
status: open
title: `concurrent.futures.ProcessPoolExecutor` swallows tracebacks
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 21 01:28:07 2014
From: report at bugs.python.org (Angus Taggart)
Date: Fri, 20 Jun 2014 23:28:07 +0000
Subject: [New-bugs-announce] [issue21818] cookielib documentation references
	Cookie module, not cookielib.Cookie class
Message-ID: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>


New submission from Angus Taggart:

all the links to Cookie class in the cookielib documentation point to Cookie module.


for example:

CookieJar.set_cookie(cookie)

    Set a *Cookie*, without checking with policy to see whether or not it should be set.


cookie in the documentation links to
https://docs.python.org/2/library/cookie.html#module-Cookie

cookie in the documentation should link to
https://docs.python.org/2/library/cookielib.html#cookielib.Cookie

----------
assignee: docs at python
components: Documentation
messages: 221133
nosy: Ajtag, docs at python
priority: normal
severity: normal
status: open
title: cookielib documentation references Cookie module, not cookielib.Cookie class
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 21 07:04:51 2014
From: report at bugs.python.org (Sworddragon)
Date: Sat, 21 Jun 2014 05:04:51 +0000
Subject: [New-bugs-announce] [issue21819] Remaining buffer from socket isn't
	available anymore	after calling socket.recv the first time
Message-ID: <1403327091.28.0.269013779192.issue21819@psf.upfronthosting.co.za>


New submission from Sworddragon:

If I'm receiving data from a socket (several bytes) and making the first call to socket.recv(1) all is fine but the second call won't get any further data. But doing this again with socket.recv(2) instead will successfully get the 2 bytes. Here is a testcase:


Script:

def icmp_packet(type, code, data):
	length_data = len(data)
	if length_data % 2 == 1:
		data += b'\x00'
	checksum = code | type << 8
	i = 0
	while i < length_data:
		checksum += data[i + 1] | data[i] << 8
		checksum = (checksum & 65535) + (checksum >> 16)
		i += 2
	return bytes([type]) + bytes([code]) + (checksum ^ 65535).to_bytes(2, 'big') + data

import socket

connection = socket.socket(proto = socket.IPPROTO_ICMP, type = socket.SOCK_RAW)
connection.settimeout(1)
connection.sendto(icmp_packet(8, 0, b'\x00\x00\x00\x00'), ('8.8.8.8', 0))
print(connection.recv(2))
connection.close()
connection = socket.socket(proto = socket.IPPROTO_ICMP, type = socket.SOCK_RAW)
connection.settimeout(1)
connection.sendto(icmp_packet(8, 0, b'\x00\x00\x00\x00'), ('8.8.8.8', 0))
print(connection.recv(1))
print(connection.recv(1))
connection.close()


Here is the result:

root at ubuntu:/home/sworddragon/tmp# python3 test.py
b'E\x00'
b'E'
Traceback (most recent call last):
  File "test.py", line 24, in <module>
    print(connection.recv(1))
socket.timeout: timed out

----------
components: Library (Lib)
messages: 221155
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Remaining buffer from socket isn't available anymore after calling socket.recv the first time
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 21 12:34:46 2014
From: report at bugs.python.org (Chris Withers)
Date: Sat, 21 Jun 2014 10:34:46 +0000
Subject: [New-bugs-announce] [issue21820] unittest: unhelpful truncating of
	long strings.
Message-ID: <1403346886.23.0.538670310002.issue21820@psf.upfronthosting.co.za>


New submission from Chris Withers:

This code, prior to 3.4:

from testfixtures import Comparison as C

class AClass:
    def __init__(self,x,y=None):
        self.x = x
        if y:
            self.y = y
    def __repr__(self):
        return '<'+self.__class__.__name__+'>'

...

self.assertEqual(
    C('testfixtures.tests.test_comparison.AClass',
      y=5, z='missing'),
      AClass(1, 2))

Would give the following output in the failure message:

"""
<C(failed):testfixtures.tests.test_comparison.AClass>
  x:1 not in Comparison
  y:5 != 2
  z:'missing' not in other
</C> != <AClass>"
"""

Now, in 3.4, you get the (rather unhelpful):

"""
<C(failed):testfixtures.tests.test_com[79 chars] </C> != <AClass>
"""

It's particularly disappointing that there's no API (class attribute, etc) to control whether or not this new behaviour is enabled.

I believe the change that introduced this behaviour was in [issue18996]

----------
components: Tests
keywords: 3.4regression
messages: 221167
nosy: cjw296
priority: normal
severity: normal
status: open
title: unittest: unhelpful truncating of long strings.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 21 16:35:56 2014
From: report at bugs.python.org (PierreAugier)
Date: Sat, 21 Jun 2014 14:35:56 +0000
Subject: [New-bugs-announce] [issue21821] The function
	cygwinccompiler.is_cygwingcc leads to	FileNotFoundError under
	Windows 7
Message-ID: <1403361356.73.0.508496637116.issue21821@psf.upfronthosting.co.za>


New submission from PierreAugier:

Under Windows 7, with Python 3.4.1 |Anaconda 2.0.1 (64-bit), calling the function cygwinccompiler.is_cygwingcc of the distutils package leads to a FileNotFoundError.

I solved the problem for me by adding the argument shell=True in l. 404 of cygwinccompiler.py:

out_string = check_output(['gcc', '-dumpmachine'], shell=True)

----------
components: Distutils
messages: 221177
nosy: dstufft, eric.araujo, paugier
priority: normal
severity: normal
status: open
title: The function cygwinccompiler.is_cygwingcc leads to FileNotFoundError under Windows 7
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Jun 21 17:44:35 2014
From: report at bugs.python.org (Steve)
Date: Sat, 21 Jun 2014 15:44:35 +0000
Subject: [New-bugs-announce] [issue21822] KeyboardInterrupt during
	Thread.join hangs that Thread
Message-ID: <1403365475.16.0.757881205569.issue21822@psf.upfronthosting.co.za>


New submission from Steve:

I am attempting to join a thread after a previous join was interrupted by Ctrl-C.

I did not find any warning for this case in threading module docs, so I assume this is legal.

The full test script is attached, but the essential code is:

def work(t):
    sleep(t)

twork = 3; twait = 4
t = Thread(target=work, args=(twork,))
try:
	t.start()
	t.join(twait)  # here I do Ctrl-C
except KeyboardInterrupt:
	pass
t.join()  # this hangs if twork < twait


I can observe the following reproduce sequence:

1. start another thread that sleeps (or works) for T seconds
2. join that thread with timeout longer than T
3. before thread finishes and join returns, hit Ctrl-C to raise KeyboardInterrupt (KI)
4. after T seconds, thread finishes its (Python) code and KI is raised
5. Process Explorer confirms that thread really terminates (looked at .ident())
6. thread still reports .is_alive() == True
7. second attempt to join that thread hangs indefinitely

I tried replacing try-except clause with custom signal handler for SIGINT, as shown in the script. If the handler does not raise an exception, the thread can be normally joined. If it does, however, the behavior is the same as with default handler.

My _guess_ is that the exception prevents some finishing code that puts Thread into proper stopped state after its target completes.

Running Python 3.4.0 on Windows 7 x64

----------
components: Library (Lib)
files: join.py
messages: 221180
nosy: tupl
priority: normal
severity: normal
status: open
title: KeyboardInterrupt during Thread.join hangs that Thread
versions: Python 3.4
Added file: http://bugs.python.org/file35715/join.py

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

From report at bugs.python.org  Sun Jun 22 06:15:08 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Jun 2014 04:15:08 +0000
Subject: [New-bugs-announce] [issue21823] Catch turtle.Terminator exceptions
	in turtledemo
Message-ID: <1403410508.48.0.229814389673.issue21823@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

When a turtle update operation cannot finish because the underlying canvas has been cleared (when the STOP button is pushed), turtle.Terminator is raised. When turtledemo runs the main function of a demo, it catches any Termininator raised before main returns. 

However, special demos leave an event loop running after main returns.  If the demo is free running, as with clock and minimal_hanoi, clicking STOP causes such exceptions.  (This is not be a problem with paint as updates only happen in response to mouse events on the canvas and complete before a user could move the mouse to the STOP button.)

This is the clock trackback, with common file prefix removed:
  \tkinter\__init__.py", line 1487, in __call__
    return self.func(*args)
  \tkinter\__init__.py", line 532, in callit
    func(*args)
  \turtledemo\clock.py", line 116, in tick
    second_hand.setheading(6*sekunde)
  \turtle.py", line 1935, in setheading
    self._rotate(angle)
  \turtle.py", line 3277, in _rotate
    self._update()
  \turtle.py", line 2659, in _update
    self._update_data()
  \turtle.py", line 2645, in _update_data
    self.screen._incrementudc()
  \turtle.py", line 1291, in _incrementudc
    raise Terminator

The hanoi traceback starts differently:
  \tkinter\__init__.py", line 1487, in __call__
    return self.func(*args)
  \turtle.py", line 686, in eventfun
    fun()
  \turtledemo\minimal_hanoi.py", line 53, in play
    hanoi(6, t1, t2, t3)
  ...<5 recursive calls deleted>
  \turtledemo\minimal_hanoi.py", line 36, in push
    to_.push(from_.pop())
  \turtledemo\minimal_hanoi.py", line 36, in push
    d.setx(self.x)
  \turtle.py", line 1807, in setx
    self._goto(Vec2D(x, self._position[1]))
  \turtle.py", line 3178, in _goto
  <last 3 lines as above>

These exceptions and tracebacks do not stop the master demo window, but are printed to the console (python -m turtledemo) or Idle Shell (open in editor, run). They are ugly, might unnecessarily alarm a naive user, or falsely teach that tracebacks are to be ignored.

In the patch to clock.tick, I put try: at the top, to be safe, although just before the update of the second hand might be good enough.

----------
assignee: terry.reedy
messages: 221215
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Catch turtle.Terminator exceptions in turtledemo
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jun 22 07:50:45 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Jun 2014 05:50:45 +0000
Subject: [New-bugs-announce] [issue21824] Make turtledemo 2.7 help show file
	contents, not file name.
Message-ID: <1403416245.17.0.0382058231746.issue21824@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

When Demo/turtle/turtleDemo.py is run and the user selects any of the 3 Help menu entries, the filename is displayed in the test viewer instead of the file contents. The bug is that the 3 showxyz functions call textView.TextViewer directly, with the filename, instead of the viewfile function that opens and reads the file and passes the contents on to TextViewer.

----------
assignee: terry.reedy
messages: 221219
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Make turtledemo 2.7 help show file contents, not file name.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun 22 17:33:28 2014
From: report at bugs.python.org (Pat Le Cat)
Date: Sun, 22 Jun 2014 15:33:28 +0000
Subject: [New-bugs-announce] [issue21825] Embedding-Python example code from
	documentation crashes
Message-ID: <1403451208.28.0.571545120594.issue21825@psf.upfronthosting.co.za>


New submission from Pat Le Cat:

When I comment out the Py_SetPath() function call (Line 56), then the code runs up to the 4th test print and then crashes again, possibly at: "Py_XDECREF(pArgs)" else it crashes at Py_Initalize. The same behavior can be observed under Python 3.4.0 and 3.4.1 and on both the MSVC and GCC compiler.
BTW: The multiply.py runs fine when called with "py -3" directly.

>>Output without Py_SetPath:
C:\Development\xxx\Testo1\Snakes\Release>Snakes.exe multiply multiply 3 2
Number of arguments 5
Will compute 3 times 2
Result:  6
***Test1***Test2***Test3Will compute 3 times 2
***Test4

>>Output with Py_SetPath:
C:\Development\xxx\Testo1\Snakes\Release>Snakes.exe multiply multiply 3 2
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'


**Dev-Environment:
Windows 8.1 64bit, MSVC-2013 and MingW (installed with mingw-w64-install.exe downloaded in June 2014).

**Microsoft Visual Studio Professional 2013: v12.0.30501.00 Update2

**GCC/G++ Version:
C:\Development\xxx\Testo1\Snakes\Release>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=C:/MingW64/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --targe
t=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw490/x86_64-490-win32-seh-rt_v3-rev1/mingw64 --wi
th-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=win32 --ena
ble-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic
-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-cloog-version-check --dis
able-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --dis
able-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 -
-with-libiconv --with-system-zlib --with-gmp=/c/mingw490/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/
c/mingw490/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw490/prerequisites/x86_64-w64-mingw32-sta
tic --with-isl=/c/mingw490/prerequisites/x86_64-w64-mingw32-static --with-cloog=/c/mingw490/prerequisites/x86_
64-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='x86_64-win32-seh-rev1, Built by MinGW-W64
project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw490/x86_64-490-wi
n32-seh-rt_v3-rev1/mingw64/opt/include -I/c/mingw490/prerequisites/x86_64-zlib-static/include -I/c/mingw490/pr
erequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw490/x86_64-490-win32-seh-rt_v3-re
v1/mingw64/opt/include -I/c/mingw490/prerequisites/x86_64-zlib-static/include -I/c/mingw490/prerequisites/x86_
64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw490/x86_64-490-win32-seh-rt_v3-rev1/mingw64/
opt/lib -L/c/mingw490/prerequisites/x86_64-zlib-static/lib -L/c/mingw490/prerequisites/x86_64-w64-mingw32-stat
ic/lib'
Thread model: win32
gcc version 4.9.0 (x86_64-win32-seh-rev1, Built by MinGW-W64 project)

----------
components: Build, Demos and Tools
files: main.cpp
messages: 221259
nosy: Pat.Le.Cat
priority: normal
severity: normal
status: open
title: Embedding-Python example code from documentation crashes
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file35724/main.cpp

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

From report at bugs.python.org  Sun Jun 22 18:01:11 2014
From: report at bugs.python.org (tw.bert)
Date: Sun, 22 Jun 2014 16:01:11 +0000
Subject: [New-bugs-announce] [issue21826] Performance issue (+fix) AIX
	ctypes.util with no	/sbin/ldconfig present
Message-ID: <1403452871.25.0.30621640858.issue21826@psf.upfronthosting.co.za>


New submission from tw.bert:

Preample: This is my first post to the python issue tracker, I included a fix.

This issue is probably related to http://bugs.python.org/issue11063 .

The problem:

After upgrading a package on AIX 7.1 x64 that started using the uuid module, we experienced serious performance issues.

The culprit (found after a day of debugging) is here:

File: ctypes/util.py
Note: The file /sbin/ldconfig does *not* exist, so no useful information is collected here.
The statement: 

`f = os.popen('/sbin/ldconfig -p 2>/dev/null')`

To be more specific about the performace at popen(), the performance degradation happens in it's close() method. It takes 300 ms, which is unacceptable. In a larger scope, statements that took 200ms now take 1400ms (because the above is called several times.

If I simply check for os.path.exists before the popen, the performance is fine again. See the included simple patch. It's a simple unix diff, we don't have git on that machine. Git can handle those diffs easily to my knowledge.

More information:

Small scope, culprit identified:

import os, time, traceback
print os.__file__
print time.clock(),'pre'
f = None
try:
  #if os.path.exists('/sbin/ldconfig'):
  f = os.popen('/sbin/ldconfig -p 2>/dev/null')
except:
  print traceback.format_exc()
finally:
  print time.clock(),'post close'
  if f: f.close()
  print time.clock(),'post finally'

This takes 300ms (post finally) without the check for exists.

Large scope, before patch:
time python -c "import hiredis;import redis;print 'redis-py version: %s , hiredis-py version: %s' %(redis.VERSION,hiredis.__ver
sion__,)"
redis-py version: (2, 10, 1) , hiredis-py version: 0.1.3

real    0m1.409s
user    0m0.416s
sys     0m0.129s

Large scope, after patch:
time python -c "import hiredis;import redis;print 'redis-py version: %s , hiredis-py version: %s' %(redis.VERSION,hiredis.__ver
sion__,)"
redis-py version: (2, 10, 1) , hiredis-py version: 0.1.3

real    0m0.192s
user    0m0.056s
sys     0m0.050s

----------
components: ctypes
files: patch_ctypes_util_py.diff
keywords: patch
messages: 221266
nosy: tw.bert
priority: normal
severity: normal
status: open
title: Performance issue (+fix) AIX ctypes.util with no /sbin/ldconfig present
versions: Python 2.7
Added file: http://bugs.python.org/file35726/patch_ctypes_util_py.diff

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

From report at bugs.python.org  Sun Jun 22 18:44:47 2014
From: report at bugs.python.org (Robert Li)
Date: Sun, 22 Jun 2014 16:44:47 +0000
Subject: [New-bugs-announce] [issue21827] textwrap.dedent() fails when
	largest common whitespace	is a substring of smallest leading
	whitespace
Message-ID: <1403455487.85.0.474137406062.issue21827@psf.upfronthosting.co.za>


New submission from Robert Li:

Failing test case: "  \tboo\n \tghost"

expected:          " \tboo\n\tghost"
returns:           "  \tboo\n \tghost"

----------
components: Library (Lib)
messages: 221277
nosy: pitrou, r.david.murray, robertjli, yjchen
priority: normal
severity: normal
status: open
title: textwrap.dedent() fails when largest common whitespace is a substring of smallest leading whitespace
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Jun 23 14:37:41 2014
From: report at bugs.python.org (Nicolas Limage)
Date: Mon, 23 Jun 2014 12:37:41 +0000
Subject: [New-bugs-announce] [issue21828] added/corrected containment
	relationship for networks in	lib ipaddress
Message-ID: <1403527061.43.0.332069268045.issue21828@psf.upfronthosting.co.za>


New submission from Nicolas Limage:

The current version of the ipaddress library implements containment relationship in a way that a network is never contained in another network :

>>> from ipaddress import IPv4Network,IPv4Address
>>> IPv4Network(u'192.168.22.0/24') in IPv4Network(u'192.168.0.0/16')
False

I think it would be better to define the containment relationship between networks as such :

- if network A contains all the ip addresses of network B, then B in A is True
- by extension of this rule, A in A is True

It is useful to quickly determine if a network is a subnet of another

----------
components: Library (Lib)
files: ipaddress-network-containment.diff
keywords: patch
messages: 221350
nosy: Nicolas.Limage
priority: normal
severity: normal
status: open
title: added/corrected containment relationship for networks in lib ipaddress
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/file35737/ipaddress-network-containment.diff

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

From report at bugs.python.org  Mon Jun 23 14:52:05 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 23 Jun 2014 12:52:05 +0000
Subject: [New-bugs-announce] [issue21829] Wrong test in ctypes
Message-ID: <1403527925.65.0.212984709862.issue21829@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

There's a problem with ctypes.test.test_values on Windows.
First, the test is wrong because it uses the following:

if __debug__:
    self.assertEqual(opt, 0)
elif ValuesTestCase.__doc__ is not None:
    self.assertEqual(opt, 1)

ValuesTestCase doesn't have a docstring and the check always fails when running the test suite with -O or -OO.
Second, running the test suite with -O and afterwards with -OO, will lead to the following failure:

======================================================================
FAIL: test_optimizeflag (ctypes.test.test_values.Win_ValuesTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Projects\cpython\lib\ctypes\test\test_values.py", line 50, in test_optimizeflag
    self.assertEqual(opt, 1)
AssertionError: 2 != 1

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

That's because the .pyo file for test_values already exist when rerunning with -OO and the docstring will be there. Now, I don't know why the file is not rebuilt and the documentation regarding -OO and -O is pretty scarce. The attached file tries a different approach, regenerate a test class each time the test is run in order to obtain its docstring. If run with -OO, it will be dropped properly.

----------
components: Tests, ctypes
files: ctypes.patch
keywords: patch
messages: 221351
nosy: Claudiu.Popa
priority: normal
severity: normal
stage: patch review
status: open
title: Wrong test in ctypes
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file35738/ctypes.patch

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

From report at bugs.python.org  Mon Jun 23 21:11:02 2014
From: report at bugs.python.org (David M Noriega)
Date: Mon, 23 Jun 2014 19:11:02 +0000
Subject: [New-bugs-announce] [issue21830] ssl.wrap_socket fails on Windows 7
	when specifying	ca_certs
Message-ID: <1403550662.12.0.944818442815.issue21830@psf.upfronthosting.co.za>


New submission from David M Noriega:

When trying to use python3-ldap package on Windows 7, found I could not get a TLS connection to work and traced it to its use of ssl.wrap_socket. Trying out the following simple socket test fails

import socket
import ssl
sock = socket.socket()
sock.connect(("host.name", 636))
ssl = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_REQUIRED, ca_certs=r"C:path\to\cert\file")
Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    sock = ssl.wrap_socket(sock, cert_reqs=ssl.CERT_REQUIRED, ca_certs=r"F:\Downloads\csbc-cacert.pem")
  File "C:\Python34\lib\ssl.py", line 888, in wrap_socket
    ciphers=ciphers)
  File "C:\Python34\lib\ssl.py", line 511, in __init__
    self._context.load_verify_locations(ca_certs)
ssl.SSLError: unknown error (_ssl.c:2734)

This code works on Windows XP(and of course linux) and I'm able to use getpeercert()

A workaround I was able to figure out was to use ssl.SSLContext in conjunction with Windows central certificate store. By first loading my CA cert into the trusted root cert store, I could use SSLContext.load_default_certs() to create an ssl socket.

----------
components: Windows
messages: 221373
nosy: David.M.Noriega
priority: normal
severity: normal
status: open
title: ssl.wrap_socket fails on Windows 7 when specifying ca_certs
versions: Python 3.4

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

From report at bugs.python.org  Tue Jun 24 05:11:23 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 Jun 2014 03:11:23 +0000
Subject: [New-bugs-announce] [issue21831] integer overflow in 'buffer' type
	allows reading memory
Message-ID: <1403579483.71.0.894080875478.issue21831@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

Reported by Chris Foster on the security list:

$ ./python 
Python 2.7.7+ (2.7:8e0b7393e921, Jun 24 2014, 03:01:40) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = bytearray('hola mundo')
>>> b = buffer(a, 0x7fffffff, 0x7fffffff)
>>> print repr(b[:0x100])
"\x00\x08\x11\x00\x00\x00\x00\x00\x00\x00\xa00_\xf7\x10\x00\x00\x00i\x03\x00\x00\x02\x00\x00\x00\xa0\xd1\x18\x08I\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00Directory tree walk with callback function.\n\n    For each directory in the directory tree rooted at top (including top\n    itself, but excluding '.' and '..'), call func(arg, dirname, fnames).\n    dirname is the na"

----------
components: Interpreter Core
messages: 221392
nosy: benjamin.peterson
priority: release blocker
severity: normal
status: open
title: integer overflow in 'buffer' type allows reading memory
type: security
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 05:52:23 2014
From: report at bugs.python.org (Kevin Norris)
Date: Tue, 24 Jun 2014 03:52:23 +0000
Subject: [New-bugs-announce] [issue21832] collections.namedtuple does
	questionable things when	passed questionable arguments
Message-ID: <1403581943.09.0.462599950196.issue21832@psf.upfronthosting.co.za>


New submission from Kevin Norris:

Code such as this:

    class Foo:
        def __str__(self):
            # Perhaps this value comes from user input, or
            # some other unsafe source
            return something_untrusted
        def isidentifier(self):
            # Perhaps it returns false in some esoteric case
            # which we don't care about. Assume developer
            # did not know about str.isidentifier() and
            # the name clash is accidental.
            return True

    collections.namedtuple(Foo(), ())

...may result in arbitrary code execution.  Since the collections documentation does not say that such things can happen, this could result in highly obscure security vulnerabilities.  The easiest fix is to simply call str() on the typename argument to namedtuple(), as is currently done with the field_names argument.  But IMHO this is like cleaning up an SQL injection with string sanitizing, instead of just switching to prepared statements.  The "switch to prepared statements" route is conveniently available as a rejected patch for issue 3974.

The above code will not work as such in Python 2.7, but more elaborate shenanigans can fool the sanitizing in that version as well.

This issue was originally reported on security at python.org, where I was advised to file a bug report normally.

----------
components: Library (Lib)
messages: 221394
nosy: Kevin.Norris
priority: normal
severity: normal
status: open
title: collections.namedtuple does questionable things when passed questionable arguments
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 24 08:53:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 06:53:22 +0000
Subject: [New-bugs-announce] [issue21833] Fix unicodeless build of Python
Message-ID: <1403592802.89.0.505189213304.issue21833@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since 2.2 Python can be compiled without unicode support (built with --disable-unicode configure option). Unfortunately, testing suite depends on the io module, which in 2.7 depends on the _io module, which requires unicode support. So for now testing unicodeless Python is not possible. Some other modules are failed when built without unicode support too.

Proposed patch fixes the io module in unicodeless build and includes also minor fixes fixes of compilation errors for other modules (except sqlite) and changes to auxilary files needed to build Python and run tests.

Patches for other components will be provided in separate issues.

----------
components: Build, IO, Tests
files: main.patch
keywords: patch
messages: 221402
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix unicodeless build of Python
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file35744/main.patch

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

From report at bugs.python.org  Tue Jun 24 08:58:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 06:58:20 +0000
Subject: [New-bugs-announce] [issue21834] Fix a number of tests in
	unicodeless build
Message-ID: <1403593100.61.0.321675638626.issue21834@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes a number of tests for Python built with --disable-unicode configure option.

----------
components: Tests
files: tests.patch
keywords: patch
messages: 221403
nosy: christian.heimes, giampaolo.rodola, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix a number of tests in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35745/tests.patch

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

From report at bugs.python.org  Tue Jun 24 09:07:31 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:07:31 +0000
Subject: [New-bugs-announce] [issue21835] Fix Tkinter in unicodeless build
Message-ID: <1403593651.52.0.581013671758.issue21835@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the Tkinter module and it's tests for Python built with --disable-unicode configure option.

----------
components: Build, Tests, Tkinter
files: tkinter.patch
keywords: patch
messages: 221404
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix Tkinter in unicodeless build
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file35746/tkinter.patch

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

From report at bugs.python.org  Tue Jun 24 09:07:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:07:40 +0000
Subject: [New-bugs-announce] [issue21836] Fix sqlite3 in unicodeless build
Message-ID: <1403593660.62.0.0164715886324.issue21836@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the sqlite3 module and it's tests for Python built with --disable-unicode configure option.

----------
components: Extension Modules, Library (Lib), Tests
files: sqlite.patch
keywords: patch
messages: 221405
nosy: ghaering, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix sqlite3 in unicodeless build
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file35747/sqlite.patch

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

From report at bugs.python.org  Tue Jun 24 09:08:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:08:37 +0000
Subject: [New-bugs-announce] [issue21837] Fix tarfile in unicodeless build
Message-ID: <1403593717.46.0.937130819445.issue21837@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the tarfile module and it's tests for Python built with --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: tarfile.patch
keywords: patch
messages: 221406
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix tarfile in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35748/tarfile.patch

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

From report at bugs.python.org  Tue Jun 24 09:10:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:10:06 +0000
Subject: [New-bugs-announce] [issue21838] Fix ctypes in unicodeless build
Message-ID: <1403593806.9.0.0462136346954.issue21838@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the ctypes module and it's tests for Python built with --disable-unicode configure option.

----------
components: Library (Lib), Tests, ctypes
files: ctypes.patch
keywords: patch
messages: 221407
nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix ctypes in unicodeless build
type: behavior
Added file: http://bugs.python.org/file35749/ctypes.patch

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

From report at bugs.python.org  Tue Jun 24 09:11:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:11:09 +0000
Subject: [New-bugs-announce] [issue21839] Fix distutils in unicodeless build
Message-ID: <1403593869.13.0.236302983697.issue21839@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes distutils and it's tests for Python built with the --disable-unicode configure option.

----------
components: Distutils, Tests
messages: 221408
nosy: dstufft, eric.araujo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix distutils in unicodeless build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 09:15:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:15:10 +0000
Subject: [New-bugs-announce] [issue21840] Fix os.path in unicodeless build
Message-ID: <1403594110.07.0.0949253630199.issue21840@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes os.path implementations and their's tests for Python built with --disable-unicode configure option.

It also fixes a bug in posixpath which affects unicode build too.

----------
components: Library (Lib), Tests
files: os_path.patch
keywords: patch
messages: 221410
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix os.path in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35751/os_path.patch

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

From report at bugs.python.org  Tue Jun 24 09:17:11 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:17:11 +0000
Subject: [New-bugs-announce] [issue21841] Fix xml.sax in unicodeless build
Message-ID: <1403594231.26.0.541614967311.issue21841@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the xml.sax module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: xml_sax.patch
keywords: patch
messages: 221412
nosy: christian.heimes, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix xml.sax in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35752/xml_sax.patch

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

From report at bugs.python.org  Tue Jun 24 09:18:08 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:18:08 +0000
Subject: [New-bugs-announce] [issue21842] Fix IDLE in unicodeless build
Message-ID: <1403594288.8.0.587190115284.issue21842@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes IDLE and it's tests for Python built with the --disable-unicode configure option.

----------
components: IDLE, Tests
messages: 221414
nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Fix IDLE in unicodeless build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 09:23:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:23:16 +0000
Subject: [New-bugs-announce] [issue21843] Fix doctest in unicodeless build
Message-ID: <1403594596.58.0.13815654086.issue21843@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the doctest module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: doctest.patch
keywords: patch
messages: 221415
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix doctest in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35754/doctest.patch

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

From report at bugs.python.org  Tue Jun 24 09:25:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:25:43 +0000
Subject: [New-bugs-announce] [issue21844] Fix HTMLParser in unicodeless build
Message-ID: <1403594743.84.0.436263477794.issue21844@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the HTMLParser module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
messages: 221417
nosy: benjamin.peterson, ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix HTMLParser in unicodeless build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 09:27:43 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:27:43 +0000
Subject: [New-bugs-announce] [issue21845] Fix plistlib in unicodeless build
Message-ID: <1403594863.87.0.835492015826.issue21845@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the plistlib module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: plistlib.patch
keywords: patch
messages: 221418
nosy: benjamin.peterson, ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix plistlib in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35755/plistlib.patch

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

From report at bugs.python.org  Tue Jun 24 09:28:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:28:53 +0000
Subject: [New-bugs-announce] [issue21846] Fix zipfile in unicodeless build
Message-ID: <1403594933.03.0.418363538618.issue21846@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the zipfile module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: zipfile.patch
keywords: patch
messages: 221420
nosy: alanmcintyre, benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix zipfile in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35756/zipfile.patch

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

From report at bugs.python.org  Tue Jun 24 09:29:48 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:29:48 +0000
Subject: [New-bugs-announce] [issue21847] Fix xmlrpc in unicodeless build
Message-ID: <1403594988.87.0.830257217468.issue21847@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the xmlrpc module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
messages: 221421
nosy: benjamin.peterson, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix xmlrpc in unicodeless build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 09:31:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:31:04 +0000
Subject: [New-bugs-announce] [issue21848] Fix logging in unicodeless build
Message-ID: <1403595064.28.0.0373165472144.issue21848@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the logging module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: logging.patch
keywords: patch
messages: 221422
nosy: benjamin.peterson, serhiy.storchaka, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: Fix logging  in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35757/logging.patch

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

From report at bugs.python.org  Tue Jun 24 09:32:38 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:32:38 +0000
Subject: [New-bugs-announce] [issue21849] Fix multiprocessing in unicodeless
	build
Message-ID: <1403595158.76.0.418417977176.issue21849@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the multiprocessing module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: multiprocessing.patch
keywords: patch
messages: 221423
nosy: benjamin.peterson, jnoller, sbt, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix multiprocessing in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35758/multiprocessing.patch

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

From report at bugs.python.org  Tue Jun 24 09:35:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:35:40 +0000
Subject: [New-bugs-announce] [issue21850] Fix httplib and SimpleHTTPServer
	in unicodeless build
Message-ID: <1403595340.98.0.841039748191.issue21850@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the httplib and the SimpleHTTPServer modules for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
messages: 221424
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix httplib and SimpleHTTPServer in unicodeless build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 09:39:04 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:39:04 +0000
Subject: [New-bugs-announce] [issue21851] Fix gettext in unicodeless build
Message-ID: <1403595544.94.0.0791965662749.issue21851@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the gettext module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: gettext.patch
keywords: patch
messages: 221425
nosy: benjamin.peterson, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix gettext in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35761/gettext.patch

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

From report at bugs.python.org  Tue Jun 24 09:40:12 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:40:12 +0000
Subject: [New-bugs-announce] [issue21852] Fix optparse in unicodeless build
Message-ID: <1403595612.48.0.11976821558.issue21852@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the optparse module and it's tests for Python built with the --disable-unicode configure option.

----------
files: optparse.patch
keywords: patch
messages: 221426
nosy: aronacher, benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix optparse in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35762/optparse.patch

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

From report at bugs.python.org  Tue Jun 24 09:41:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:41:09 +0000
Subject: [New-bugs-announce] [issue21853] Fix inspect in unicodeless build
Message-ID: <1403595669.37.0.0818329424469.issue21853@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the inspect module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
messages: 221427
nosy: benjamin.peterson, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Fix inspect in unicodeless build
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Jun 24 09:42:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:42:37 +0000
Subject: [New-bugs-announce] [issue21854] Fix cookielib in unicodeless build
Message-ID: <1403595757.33.0.450138611434.issue21854@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the cookielib module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: cookielib.patch
keywords: patch
messages: 221428
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix cookielib in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35763/cookielib.patch

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

From report at bugs.python.org  Tue Jun 24 09:43:42 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 07:43:42 +0000
Subject: [New-bugs-announce] [issue21855] Fix decimal in unicodeless build
Message-ID: <1403595822.86.0.526731488859.issue21855@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the decimal module and it's tests for Python built with the --disable-unicode configure option.

----------
components: Library (Lib), Tests
files: decimal.patch
keywords: patch
messages: 221429
nosy: benjamin.peterson, facundobatista, mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix decimal in unicodeless build
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file35764/decimal.patch

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

From report at bugs.python.org  Tue Jun 24 11:19:07 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Jun 2014 09:19:07 +0000
Subject: [New-bugs-announce] [issue21856] memoryview: no overflow on large
	slice values (start, stop, step)
Message-ID: <1403601547.35.0.914531351331.issue21856@psf.upfronthosting.co.za>


New submission from STINNER Victor:

As I following up to the issue #21831, I don't understand why memoryview[2**100:] doesn't raise an overflow error!? It looks like a bug.

Attached patch changes the behaviour to raise an OverflowError.

----------
messages: 221441
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: memoryview: no overflow on large slice values (start, stop, step)

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

From report at bugs.python.org  Tue Jun 24 11:49:31 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Jun 2014 09:49:31 +0000
Subject: [New-bugs-announce] [issue21857] assert that functions clearing the
	current exception are	not called with an exception set
Message-ID: <1403603371.13.0.654844548808.issue21857@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch detects (when Python is compiled in debug mode) if functions that may clear the current exception are called with an exception set.

The check avoids loosing an exception.

The problem is that the test_sqlite fails with the patch applied. I will open a new patch for that.

I already added similar checks in functions of Python/ceval.c.

----------
files: assert_exc.patch
keywords: patch
messages: 221444
nosy: haypo
priority: normal
severity: normal
status: open
title: assert that functions clearing the current exception are not called with an exception set
versions: Python 3.5
Added file: http://bugs.python.org/file35767/assert_exc.patch

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

From report at bugs.python.org  Tue Jun 24 11:50:54 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Jun 2014 09:50:54 +0000
Subject: [New-bugs-announce] [issue21858] Enhance error handling in the
	sqlite module
Message-ID: <1403603454.99.0.611583484215.issue21858@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The _sqlite module doesn't handle correctly Python errors. It may loose the current Python exception: test_sqlite fails when the patch of the issue #21857 is applied.

Attached patch is a work-in-progress patch to fail earlier when Python raises an exception.

----------
files: sqlite_error_handling-wip.patch
keywords: patch
messages: 221445
nosy: haypo
priority: normal
severity: normal
status: open
title: Enhance error handling in the sqlite module
versions: Python 3.5
Added file: http://bugs.python.org/file35768/sqlite_error_handling-wip.patch

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

From report at bugs.python.org  Tue Jun 24 13:06:53 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 11:06:53 +0000
Subject: [New-bugs-announce] [issue21859] Add Python implementation of FileIO
Message-ID: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds Python implementation of FileIO in _pyio. This will help to make io and _pyio dependency on _io optional (issue17984).

----------
components: IO, Library (Lib)
files: pyio_fileio.patch
keywords: patch
messages: 221449
nosy: alex, benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Add Python implementation of FileIO
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35769/pyio_fileio.patch

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

From report at bugs.python.org  Tue Jun 24 13:49:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 11:49:52 +0000
Subject: [New-bugs-announce] [issue21860] Correct FileIO docstrings
Message-ID: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Docstrings for seek() and truncate() methods of FileIO declare that they return None. Actually they return truncated size and new position respectively.

----------
assignee: docs at python
components: Documentation, IO
keywords: easy
messages: 221452
nosy: benjamin.peterson, docs at python, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Correct FileIO docstrings
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jun 24 19:36:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 17:36:58 +0000
Subject: [New-bugs-announce] [issue21861] io class name are hardcoded in
	reprs
Message-ID: <1403631418.74.0.109096243494.issue21861@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import io
>>> class F(io.FileIO): pass
... 
>>> f = F('/dev/null', 'r')
>>> f
<_io.FileIO name='/dev/null' mode='rb'>
>>> class B(io.BufferedReader): pass
... 
>>> b = B(f)
>>> b
<B name='/dev/null'>
>>> class T(io.TextIOBufferedReader): pass
io.TextIOBase(     io.TextIOWrapper(  
>>> class T(io.TextIOWrapper): pass
... 
>>> t = T(b)
>>> t
<_io.TextIOWrapper name='/dev/null' encoding='UTF-8'>

Expected results are "<__main__.F name='/dev/null' mode='rb'>", "<__main__.B name='/dev/null'>" and "<__main__.T name='/dev/null' encoding='UTF-8'>". Usually reprs of subclass instances substitute actual module and class names.

----------
components: Extension Modules, IO
keywords: easy
messages: 221476
nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: io class name are hardcoded in reprs
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jun 24 22:06:54 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jun 2014 20:06:54 +0000
Subject: [New-bugs-announce] [issue21862] cProfile command-line should
	accept "-m module_name" as	an alternative to script path
Message-ID: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

As the title says. You should be able to type:

$ python -m cProfile -m my.module.name

to profile execution of my.module.name.

----------
components: Library (Lib)
keywords: easy
messages: 221488
nosy: georg.brandl, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: cProfile command-line should accept "-m module_name" as an alternative to script path
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun 24 22:23:44 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jun 2014 20:23:44 +0000
Subject: [New-bugs-announce] [issue21863] Display module names of C
	functions in cProfile
Message-ID: <1403641424.56.0.722092394489.issue21863@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently, cProfile output displays "built-in functions" (i.e. module functions implemented in C, such as hasattr()) using only their names. This is not very useful when those functions may be provided by any third-party library. Attached patch adds the module name (as provided by __module__) to the output.

----------
components: Library (Lib)
files: cprofile_names.patch
keywords: patch
messages: 221493
nosy: georg.brandl, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Display module names of C functions in cProfile
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35774/cprofile_names.patch

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

From report at bugs.python.org  Wed Jun 25 01:41:00 2014
From: report at bugs.python.org (Peibolvig)
Date: Tue, 24 Jun 2014 23:41:00 +0000
Subject: [New-bugs-announce] [issue21864] Error in documentation of point
	9.8 'Exceptions are	classes too'
Message-ID: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>


New submission from Peibolvig:

At point 9.8 of the 3.4.1 version documentation, ( https://docs.python.org/3/tutorial/classes.html#exceptions-are-classes-too ), there is an example of two ways to use the 'raise' statement:
raise Class
raise Instance

The next two lines, state: 
"In the first form, Class must be an instance of type or of a class derived from it. The first form is a shorthand for: raise Class()"

That only says something about the first form twice.
I think that the correct way would be:
"In the first form, Class must be an instance of type or of a class derived from it. The SECOND form is a shorthand for: raise Class()"

----------
assignee: docs at python
components: Documentation
messages: 221511
nosy: Peibolvig, docs at python
priority: normal
severity: normal
status: open
title: Error in documentation of point 9.8 'Exceptions are classes too'
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 25 02:06:37 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Jun 2014 00:06:37 +0000
Subject: [New-bugs-announce] [issue21865] Improve invalid category exception
	for	warnings.filterwarnings
Message-ID: <1403654797.31.0.372707276339.issue21865@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This issue is similar to issue 16382 and issue 16845.

----------
components: Library (Lib)
files: filterwarnings_category.diff
keywords: patch
messages: 221512
nosy: berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: Improve invalid category exception for warnings.filterwarnings
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35776/filterwarnings_category.diff

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

From report at bugs.python.org  Wed Jun 25 07:56:09 2014
From: report at bugs.python.org (Benjamin Gilbert)
Date: Wed, 25 Jun 2014 05:56:09 +0000
Subject: [New-bugs-announce] [issue21866] zipfile.ZipFile.close() doesn't
	respect allowZip64
Message-ID: <1403675769.56.0.836465783864.issue21866@psf.upfronthosting.co.za>


New submission from Benjamin Gilbert:

The ZipFile documentation says:

> If allowZip64 is True (the default) zipfile will create ZIP files that
> use the ZIP64 extensions when the zipfile is larger than 2 GiB. If it
> is false zipfile will raise an exception when the ZIP file would
> require ZIP64 extensions.

ZipFile.close() will write ZIP64 central directory records if e.g. a member's local file header starts at an offset > 2 GB, or if there are more than 65535 files in the archive.  It will do this even if allowZip64 is False, whereas the documentation implies that it should raise an exception in that case.

----------
components: Library (Lib)
messages: 221525
nosy: bgilbert
priority: normal
severity: normal
status: open
title: zipfile.ZipFile.close() doesn't respect allowZip64
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 25 09:01:57 2014
From: report at bugs.python.org (Lita Cho)
Date: Wed, 25 Jun 2014 07:01:57 +0000
Subject: [New-bugs-announce] [issue21867] Turtle returns TypeError when
	undobuffer is set to 0	(aka no undo is allowed)
Message-ID: <1403679717.28.0.526098112146.issue21867@psf.upfronthosting.co.za>


New submission from Lita Cho:

Turtle currently has a bug where it will return a TypeError when undobuffer is set to less than or equal to 0 (aka undo is not allowed).

turtle.setundobuffer(0)
turtle.undo()


If an exception must be thrown, it should be a Turtle exception and not a TypeError. However, I also feel like if the user calls undo, nothing should happen when undobuffer is set to 0.

----------
messages: 221529
nosy: Lita.Cho
priority: normal
severity: normal
status: open
title: Turtle returns TypeError when undobuffer is set to 0 (aka no undo is allowed)

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

From report at bugs.python.org  Wed Jun 25 09:10:25 2014
From: report at bugs.python.org (Lita Cho)
Date: Wed, 25 Jun 2014 07:10:25 +0000
Subject: [New-bugs-announce] [issue21868] Tbuffer in turtle allows negative
	size
Message-ID: <1403680225.27.0.922926576552.issue21868@psf.upfronthosting.co.za>


New submission from Lita Cho:

Currently, you can set the undobuffer size to negative numbers. Aka, the Tbuffer can be set to negative.

s = turtle.Screen()
raw = turtle.RawTurtle(s)
raw.setundobuffer(-10)
raw.undobuffer.bufsize == -10 <-- returns True

This should not be possible. Tbuffer should not be allowed to have negative inputs. If the value is less than 0, it should just default to 0 or None. Otherwise, when you call undo, turtle just crashes.

----------
messages: 221530
nosy: Lita.Cho
priority: normal
severity: normal
status: open
title: Tbuffer in turtle allows negative size

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

From report at bugs.python.org  Wed Jun 25 10:51:10 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 25 Jun 2014 08:51:10 +0000
Subject: [New-bugs-announce] [issue21869] Clean up quopri,
	correct method names encodestring and decodestring
Message-ID: <1403686270.37.0.341302276582.issue21869@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

issue15588 brought the topic that quopri has ancient methods like encodestring, decodestring, which a user might expect that will send a string, but instead has to send bytes.

This needs to be cleaned up. 

a) function name should be accurate and represent what is sent and received.
b) tests in that main method should be killed.
c) All references in the stdlib should be updated.

----------
messages: 221537
nosy: orsenthil, r.david.murray
priority: normal
severity: normal
status: open
title: Clean up quopri, correct method names encodestring and decodestring
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Jun 25 16:13:05 2014
From: report at bugs.python.org (Alex)
Date: Wed, 25 Jun 2014 14:13:05 +0000
Subject: [New-bugs-announce] [issue21870] Ctrl-C doesn't interrupt simple
	loop
Message-ID: <1403705585.66.0.458181854344.issue21870@psf.upfronthosting.co.za>


New submission from Alex:

This infinite loop:

def f():
  a=b=0
  while 1:
    if a<b: pass

f()

doesn't respond to a Ctrl-C interrupt. If you modify the loop in various ways, like removing the function wrapper, then Ctrl-C works fine. It can be interrupted with Ctrl-\. This occurs if the program is run from a file or in the interactive interpreter.

Tested on Python 2.7.3 / Linux 3.2.0-64 x86_64, and Python 2.7.6 / Linux 3.13.0-27.

Reproducible: always
Expected behaviour: Ctrl-C interrupts program
Actual beviour: Ctrl-C prints ^C

----------
components: Interpreter Core
messages: 221550
nosy: apsaras
priority: normal
severity: normal
status: open
title: Ctrl-C doesn't interrupt simple loop
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 25 17:48:56 2014
From: report at bugs.python.org (agolde)
Date: Wed, 25 Jun 2014 15:48:56 +0000
Subject: [New-bugs-announce] [issue21871] Python 2.7.7 regression in
	mimetypes	read_windows_registry
Message-ID: <1403711336.08.0.362199436706.issue21871@psf.upfronthosting.co.za>


New submission from agolde:

Python 2.7.7 seems to contain a regression of issue #10162 as compared with 2.7.6, re-introduced by the fix of issue #9291.

import mimetypes
mimetypes.init()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\INRO\Emme\Emme 4\Emme-4.1.3\Python27\lib\mimetypes.py",
 line 348, in init
    db.read_windows_registry()
  File "C:\Program Files\INRO\Emme\Emme 4\Emme-4.1.3\Python27\lib\mimetypes.py",
 line 256, in read_windows_registry
    with _winreg.OpenKey(hkcr, subkeyname) as subkey:
WindowsError: [Error 5] Access is denied

Whereas with Python 2.7.6 on the same system, this doesn't generate any errors.

It looks like in Python 2.7.6, "with _winreg.OpenKey(hkcr, subkeyname) as subkey:" was within a try-except which was moved with the patch for issue#9291 in Python 2.7.7

----------
components: Library (Lib), Windows
messages: 221553
nosy: agolde
priority: normal
severity: normal
status: open
title: Python 2.7.7 regression in mimetypes read_windows_registry
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 25 20:28:55 2014
From: report at bugs.python.org (Ville Nummela)
Date: Wed, 25 Jun 2014 18:28:55 +0000
Subject: [New-bugs-announce] [issue21872] LZMA library sometimes fails to
	decompress a file
Message-ID: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>


New submission from Ville Nummela:

Python lzma library sometimes fails to decompress a file, even though the file does not appear to be corrupt. 

Originally discovered with OS X 10.9 / Python 2.7.7 / bacports.lzma
Now also reproduced on OS X / Python 3.4 / lzma, please see
https://github.com/peterjc/backports.lzma/issues/6 for more details.

Two example files are provided, a good one and a bad one. Both are compressed using the older lzma algorithm (not xz). An attempt to decompress the 'bad' file raises "EOFError: Compressed file ended before the end-of-stream marker was reached."

The 'bad' file appears to be ok, because
- a direct call to XZ Utils processes the files without complaints
- the decompressed files' contents appear to be ok.

The example files contain tick data and have been downloaded from the Dukascopy bank's historical data feed service. The service is well known for it's high data quality and utilised by multiple analysis SW platforms. Thus I think it is unlikely that a file integrity issue on their end would have gone unnoticed.

The error occurs relatively rarely; only around 1 - 5 times per 1000 downloaded files.

----------
components: Library (Lib)
files: Archive.zip
messages: 221566
nosy: nadeem.vawda, vnummela
priority: normal
severity: normal
status: open
title: LZMA library sometimes fails to decompress a file
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file35779/Archive.zip

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

From report at bugs.python.org  Thu Jun 26 10:23:29 2014
From: report at bugs.python.org (=?utf-8?b?TWFrIE5hemXEjWnEhy1BbmRybG9u?=)
Date: Thu, 26 Jun 2014 08:23:29 +0000
Subject: [New-bugs-announce] [issue21873] Tuple comparisons with NaNs are
	broken
Message-ID: <1403771009.56.0.175285571524.issue21873@psf.upfronthosting.co.za>


New submission from Mak Naze?i?-Andrlon:

While searching for a way to work around the breakage of the Schwartzian transform in Python 3 (and the resulting awkwardness if you wish to use heapq or bisect, which do not yet have a key argument), I thought of the good old IEEE-754 NaN. Unfortunately, that shouldn't work since lexicographical comparisons shouldn't stop for something comparing False all the time. Nevertheless:

>>> (1, float("nan"), A()) < (1, float("nan"), A())
False
>>> (0, float("nan"), A()) < (1, float("nan"), A())
True

Instead of as in
>>> nan = float("nan")
>>> (1, nan, A()) < (1, nan, A())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: A() < A()

(As a side note, PyPy3 does not have this bug.)

----------
components: Interpreter Core
messages: 221600
nosy: Electro
priority: normal
severity: normal
status: open
title: Tuple comparisons with NaNs are broken
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 27 01:45:45 2014
From: report at bugs.python.org (Bob Lightfoot)
Date: Thu, 26 Jun 2014 23:45:45 +0000
Subject: [New-bugs-announce] [issue21874] test_strptime fails on
	rhel/centos/fedora systems
Message-ID: <1403826345.9.0.88896627543.issue21874@psf.upfronthosting.co.za>


New submission from Bob Lightfoot:

when attempting build of 3.3.2-15 and 3.4.1 saw this error on both el7 and fc20 systems.

----------
components: Tests
files: fail.summary.log.el7
messages: 221667
nosy: boblfoot
priority: normal
severity: normal
status: open
title: test_strptime fails on rhel/centos/fedora systems
type: behavior
versions: Python 3.2, Python 3.4
Added file: http://bugs.python.org/file35788/fail.summary.log.el7

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

From report at bugs.python.org  Fri Jun 27 08:11:30 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 27 Jun 2014 06:11:30 +0000
Subject: [New-bugs-announce] [issue21875] Remove vestigial references to
	Classic Mac OS attributes	in os.stat() and os.name docs
Message-ID: <1403849490.21.0.904136900242.issue21875@psf.upfronthosting.co.za>


New submission from Ned Deily:

The documentation for os.stat() still contains references to optional stat fields that were supported on Classic Mac OS systems but are no longer supported in Python on Mac OS X:

    On Mac OS systems, the following attributes may also be available:

    st_rsize
    st_creator
    st_type

The section should be removed.

Also, the documentation for os.name still refers to a "mac" operating system-dependent module which also no longer exists.

----------
assignee: ned.deily
components: Documentation
keywords: easy
messages: 221676
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove vestigial references to Classic Mac OS attributes in os.stat() and os.name docs
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun 27 19:54:35 2014
From: report at bugs.python.org (Aaron Swan)
Date: Fri, 27 Jun 2014 17:54:35 +0000
Subject: [New-bugs-announce] [issue21876] os.rename(src,
	dst) does nothing when src and dst files are hard-linked
Message-ID: <1403891675.36.0.790137038971.issue21876@psf.upfronthosting.co.za>


New submission from Aaron Swan:

On Linux Red Hat os.rename(src,dst) does nothing when src and dst files are hard-linked.

It seems like the expected behavior would be the removal of the src file. This would be in keeping with the documentation that states: "On Unix, if dst exists and is a file, it will be replaced silently if the user has permission. "

----------
messages: 221699
nosy: Aaron.Swan
priority: normal
severity: normal
status: open
title: os.rename(src,dst) does nothing when src and dst files are hard-linked
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 27 23:17:37 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jun 2014 21:17:37 +0000
Subject: [New-bugs-announce] [issue21877] External.bat and pcbuild of
	tkinter do not match.
Message-ID: <1403903857.63.0.770312559658.issue21877@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

dir/pydir/Tools/buildbot/external.bat downloads tcl/tk 8.y.z into dir/tcl-8.y.z and dir/tk-8.y.x and compiles them into dir/tcltk. Of critical importance are dir/tcltk/bin/tcl8yg.dll and dir/tcltk/bin/tk8yg.dll (where y is currently 5 or 6.

dir/pydir/pcbuild/_tkinter.vcxprog compiles _tkinter is such a way that it looks for the two dlls 'everywhere' (in pcbuild itself and 5-10 other, non-existent directories) other than where they are.

The current manual fix, reported a year ago on core-mentorship list, is to copy the two .dlls into pcbuild. This should be done by external.bat.

A possible alternate fix would be to revise _tkinter.vcxproj so that _tkinter looks for the .dlls where they are. However, since multiple tcl/tk versions are compiled into /tcltk, this would break installations that use one 'dir' for multiple 'pydir's, as shown in the devguide. Currently, the .dlls must be copied into pcbuild before they get overwritten by another version.

----------
components: Build
messages: 221737
nosy: steve.dower, terry.reedy, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: External.bat and pcbuild of tkinter do not match.
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun 28 08:35:01 2014
From: report at bugs.python.org (Robin Schoonover)
Date: Sat, 28 Jun 2014 06:35:01 +0000
Subject: [New-bugs-announce] [issue21878] wsgi.simple_server's wsgi.input
	readline waits forever	for non-multipart/form-data
Message-ID: <1403937301.18.0.584032434522.issue21878@psf.upfronthosting.co.za>


New submission from Robin Schoonover:

In the reference WSGI server in wsgiref.simple_server, wsgi.input's readline() hangs if the request body does not actually contain any
newlines.

Consider the following (slightly silly) example:

    from wsgiref.simple_server import make_server

    def app(environ, start_response):
        result = environ['wsgi.input'].readline()

        # not reached...
        start_response("200 OK", [("Content-Type", "text/plain")])
        return []

    httpd = make_server('', 8000, app)
    httpd.serve_forever()

And the following also silly request (the data kwarg makes it a
POST request):

    from urllib.request import urlopen

    req = urlopen("http://localhost:8000/", data=b'some bytes')
    print(req)

Normally this isn't a problem, as the reference server isn't intended
for production, and typically the only reason .readline() would be
used is with a request body formatted as multipart/form-data, which
uses ample newlines, including with the content boundaries.  However,
for other types of request bodies (such as application/x-www-form-urlencoded)
newlines often wouldn't appear, and using .readline() would wait forever for new input.

----------
components: Library (Lib)
messages: 221774
nosy: rschoon
priority: normal
severity: normal
status: open
title: wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data
type: behavior

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

From report at bugs.python.org  Sun Jun 29 16:37:28 2014
From: report at bugs.python.org (Roy Smith)
Date: Sun, 29 Jun 2014 14:37:28 +0000
Subject: [New-bugs-announce] [issue21879] str.format() gives poor diagnostic
	on placeholder	mismatch
Message-ID: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za>


New submission from Roy Smith:

https://mail.python.org/pipermail/python-list/2014-June/674188.html

----------
messages: 221846
nosy: roysmith
priority: normal
severity: normal
status: open
title: str.format() gives poor diagnostic on placeholder mismatch

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

From report at bugs.python.org  Sun Jun 29 20:27:27 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sun, 29 Jun 2014 18:27:27 +0000
Subject: [New-bugs-announce] [issue21880] IDLE: Ability to run 3rd party
	code checkers
Message-ID: <1404066447.3.0.940760126754.issue21880@psf.upfronthosting.co.za>


New submission from Saimadhav Heblikar:

(This issue is continuation of http://bugs.python.org/issue18704)

This issue is about a feature to execute any 3rd party code checker from within IDLE.

I am attaching an initial patch(so as to get reviews, is functional logic wise, but missing a lot UI/UX wise.) 

It is implemented as an extension.

----------
components: IDLE
files: 3rdpartychecker-v1.diff
keywords: patch
messages: 221876
nosy: jesstess, sahutd, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Ability to run 3rd party code checkers
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35801/3rdpartychecker-v1.diff

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

From report at bugs.python.org  Sun Jun 29 21:38:46 2014
From: report at bugs.python.org (Andreas Schwab)
Date: Sun, 29 Jun 2014 19:38:46 +0000
Subject: [New-bugs-announce] [issue21881] python cannot parse tcl value
Message-ID: <1404070726.81.0.038892791749.issue21881@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

Lib/test/test_tcl.py fails with:

test test_tcl failed -- Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/Python-2.7.7/Lib/test/test_tcl.py", line 430
, in test_user_command
    check(float('nan'), 'NaN', eq=nan_eq)
  File "/home/abuild/rpmbuild/BUILD/Python-2.7.7/Lib/test/test_tcl.py", line 397
, in check
    eq(result[0], expected2)
  File "/home/abuild/rpmbuild/BUILD/Python-2.7.7/Lib/test/test_tcl.py", line 405
, in nan_eq
    actual = float(actual)
ValueError: invalid literal for float(): NaN(7ffffffffffff)

----------
components: Tkinter
messages: 221887
nosy: schwab
priority: normal
severity: normal
status: open
title: python cannot parse tcl value
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 30 01:56:01 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Jun 2014 23:56:01 +0000
Subject: [New-bugs-announce] [issue21882] turtledemo modules imported by
	test___all__ cause side	effects or failures
Message-ID: <1404086161.6.0.896977354321.issue21882@psf.upfronthosting.co.za>


New submission from Ned Deily:

Although the turtledemo modules are not run directly during by "make test" or by "python -m test -uall", they are currently being inadvertently imported by test___all__.  This can lead to test failures and side effects because some of the turtledemo modules execute code on import, rather than only when being run via calls to their main() functions.  A quick glance shows problems with the following demos: clock (calls mode("logo") which causes a window to appear), colormixer (which unconditionally calls sys.setrecursionlimit()), and two_canvases (which is not structured using functions at all).  Depending on how tests are run, these problems can cause serious side effects.

At a minimum,
1. test___all__ should be changed to exclude turtledemo modules.

It would also be nice to make the demos better citizens:
2. move the mode() call to main() in clock
3. move the setrecursionlimit call to main() and save and restore the original value on exit
4. restructure two_canvases to be like the other demos.
5. double-check all demos for other cases where interpreter state is changed and not restored.

----------
components: Tests
keywords: easy
messages: 221921
nosy: ned.deily
priority: normal
severity: normal
stage: test needed
status: open
title: turtledemo modules imported by test___all__ cause side effects or failures
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun 30 05:12:55 2014
From: report at bugs.python.org (Matt Bachmann)
Date: Mon, 30 Jun 2014 03:12:55 +0000
Subject: [New-bugs-announce] [issue21883] relpath: Provide better errors
	when mixing bytes and	strings
Message-ID: <1404097975.91.0.971553035109.issue21883@psf.upfronthosting.co.za>


New submission from Matt Bachmann:

Howdy!

I encountered this error when accidently passing in mixed types to reldir

>>> import os
>>> os.path.relpath('/Users/bachmann', b'.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/posixpath.py", line 451, in relpath
    start_list = [x for x in abspath(start).split(sep) if x]
TypeError: Type str doesn't support the buffer API

When this mistake is done in join we get a helpful error message.

I simply borrowed this logic and put in in relpath. Is this useful?

----------
components: Library (Lib)
messages: 221939
nosy: Matt.Bachmann
priority: normal
severity: normal
status: open
title: relpath: Provide better errors when mixing bytes and strings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 30 11:27:58 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Jun 2014 09:27:58 +0000
Subject: [New-bugs-announce] [issue21884] turtle regression of issue #21823:
	"uncaught exception"	on "AMD64 Snow Leop 3.x" buildbot
Message-ID: <1404120478.05.0.18720742305.issue21884@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since the changeset 1ae2382417dcc7202c708cac46ae8a61412ca787 from the issue #21823, Tcl/Tk crashs beacuse of an "uncaught exception" on the buildbot "AMD64 Snow Leop 3.x" on tk.call('update') called by tkinter.Misc().update().

First failure on the buildbot 3.4:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.4/builds/235

Last error on buildbot 3.x:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1831/steps/test/logs/stdio

Sun Jun 29 21:49:20 buddy.home.bitdance.com python.exe[75372] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
2014-06-29 21:49:22.399 python.exe[75372:903] An uncaught exception was raised
2014-06-29 21:49:22.400 python.exe[75372:903] Error (1002) creating CGSWindow
2014-06-29 21:49:22.419 python.exe[75372:903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1002) creating CGSWindow'
*** Call stack at first throw:
(
	0   CoreFoundation                      0x00007fff84954784 __exceptionPreprocess + 180
	1   libobjc.A.dylib                     0x00007fff84eb9f03 objc_exception_throw + 45
	2   CoreFoundation                      0x00007fff849545a7 +[NSException raise:format:arguments:] + 103
	3   CoreFoundation                      0x00007fff84954534 +[NSException raise:format:] + 148
	4   AppKit                              0x00007fff850a2f52 _NSCreateWindowWithOpaqueShape2 + 473
	5   AppKit                              0x00007fff85037691 -[NSWindow _commonAwake] + 1214
	6   AppKit                              0x00007fff850551c9 -[NSWindow _makeKeyRegardlessOfVisibility] + 96
	7   AppKit                              0x00007fff8505513e -[NSWindow makeKeyAndOrderFront:] + 24
	8   Tk                                  0x00000001035fd86c XMapWindow + 155
	9   Tk                                  0x000000010356c6d0 Tk_MapWindow + 89
	10  Tk                                  0x00000001035755e6 TkToplevelWindowForCommand + 2658
	11  Tcl                                 0x00000001034d20d3 TclServiceIdle + 76
	12  Tcl                                 0x00000001034b82ce Tcl_DoOneEvent + 329
	13  Tk                                  0x000000010354bf33 TkGetDisplayOf + 379
	14  Tcl                                 0x0000000103454559 Tcl_CreateInterp + 4820
	15  Tcl                                 0x0000000103455769 Tcl_EvalObjv + 66
	16  _tkinter.so                         0x0000000103433b4f Tkapp_Call + 562
	17  python.exe                          0x00000001000872af PyCFunction_Call + 202
	18  python.exe                          0x0000000100195bac call_function + 1715
	19  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	20  python.exe                          0x0000000100196256 fast_function + 515
	21  python.exe                          0x0000000100195df9 call_function + 2304
	22  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	23  python.exe                          0x0000000100196256 fast_function + 515
	24  python.exe                          0x0000000100195df9 call_function + 2304
	25  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	26  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	27  python.exe                          0x00000001001963aa fast_function + 855
	28  python.exe                          0x0000000100195df9 call_function + 2304
	29  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	30  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	31  python.exe                          0x00000001001963aa fast_function + 855
	32  python.exe                          0x0000000100195df9 call_function + 2304
	33  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	34  python.exe                          0x0000000100196256 fast_function + 515
	35  python.exe                          0x0000000100195df9 call_function + 2304
	36  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	37  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	38  python.exe                          0x00000001001963aa fast_function + 855
	39  python.exe                          0x0000000100195df9 call_function + 2304
	40  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	41  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	42  python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	43  python.exe                          0x0000000100057fee function_call + 586
	44  python.exe                          0x000000010000e39f PyObject_Call + 126
	45  python.exe                          0x0000000100034224 method_call + 332
	46  python.exe                          0x000000010000e39f PyObject_Call + 126
	47  python.exe                          0x00000001000bf187 slot_tp_init + 76
	48  python.exe                          0x00000001000aaf04 type_call + 376
	49  python.exe                          0x000000010000e39f PyObject_Call + 126
	50  python.exe                          0x0000000100196c5c do_call + 553
	51  python.exe                          0x0000000100195e15 call_function + 2332
	52  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	53  python.exe                          0x0000000100196256 fast_function + 515
	54  python.exe                          0x0000000100195df9 call_function + 2304
	55  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	56  python.exe                          0x0000000100196256 fast_function + 515
	57  python.exe                          0x0000000100195df9 call_function + 2304
	58  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	59  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	60  python.exe                          0x00000001001963aa fast_function + 855
	61  python.exe                          0x0000000100195df9 call_function + 2304
	62  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	63  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	64  python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	65  python.exe                          0x000000010017ce4f PyEval_EvalCode + 96
	66  python.exe                          0x0000000100174b34 builtin_exec + 550
	67  python.exe                          0x00000001000872af PyCFunction_Call + 202
	68  python.exe                          0x0000000100197338 ext_do_call + 1496
	69  python.exe                          0x000000010018e42b PyEval_EvalFrameEx + 71102
	70  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	71  python.exe                          0x00000001001963aa fast_function + 855
	72  python.exe                          0x0000000100195df9 call_function + 2304
	73  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	74  python.exe                          0x0000000100196256 fast_function + 515
	75  python.exe                          0x0000000100195df9 call_function + 2304
	76  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	77  python.exe                          0x0000000100196256 fast_function + 515
	78  python.exe                          0x0000000100195df9 call_function + 2304
	79  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	80  python.exe                          0x0000000100196256 fast_function + 515
	81  python.exe                          0x0000000100195df9 call_function + 2304
	82  python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	83  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	84  python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	85  python.exe                          0x0000000100057fee function_call + 586
	86  python.exe                          0x000000010000e39f PyObject_Call + 126
	87  python.exe                          0x000000010000f5f7 _PyObject_CallMethodIdObjArgs + 500
	88  python.exe                          0x00000001001c0ab1 PyImport_ImportModuleLevelObject + 3596
	89  python.exe          [160/390] test___all__
                0x00000001001733f3 builtin___import__ + 164
	90  python.exe                          0x000000010008731b PyCFunction_Call + 310
	91  python.exe                          0x000000010000e39f PyObject_Call + 126
	92  python.exe                          0x000000010019529c PyEval_CallObjectWithKeywords + 417
	93  python.exe                          0x000000010018af53 PyEval_EvalFrameEx + 57574
	94  python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	95  python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	96  python.exe                          0x000000010017ce4f PyEval_EvalCode + 96
	97  python.exe                          0x00000001001d97c0 run_mod + 102
	98  python.exe                          0x00000001001d9442 PyRun_StringFlags + 179
	99  python.exe                          0x0000000100174ba1 builtin_exec + 659
	100 python.exe                          0x00000001000872af PyCFunction_Call + 202
	101 python.exe                          0x0000000100195bac call_function + 1715
	102 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	103 python.exe                          0x0000000100196256 fast_function + 515
	104 python.exe                          0x0000000100195df9 call_function + 2304
	105 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	106 python.exe                          0x0000000100196256 fast_function + 515
	107 python.exe                          0x0000000100195df9 call_function + 2304
	108 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	109 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	110 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	111 python.exe                          0x0000000100057fee function_call + 586
	112 python.exe                          0x000000010000e39f PyObject_Call + 126
	113 python.exe                          0x0000000100197352 ext_do_call + 1522
	114 python.exe                          0x000000010018e42b PyEval_EvalFrameEx + 71102
	115 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	116 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	117 python.exe                          0x0000000100057fee function_call + 586
	118 python.exe                          0x000000010000e39f PyObject_Call + 126
	119 python.exe                          0x0000000100034224 method_call + 332
	120 python.exe                          0x000000010000e39f PyObject_Call + 126
	121 python.exe                          0x00000001000be65f slot_tp_call + 77
	122 python.exe                          0x000000010000e39f PyObject_Call + 126
	123 python.exe                          0x0000000100196c5c do_call + 553
	124 python.exe                          0x0000000100195e15 call_function + 2332
	125 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	126 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	127 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	128 python.exe                          0x0000000100057fee function_call + 586
	129 python.exe                          0x000000010000e39f PyObject_Call + 126
	130 python.exe                          0x0000000100197352 ext_do_call + 1522
	131 python.exe                          0x000000010018e42b PyEval_EvalFrameEx + 71102
	132 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	133 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	134 python.exe                          0x0000000100057fee function_call + 586
	135 python.exe                          0x000000010000e39f PyObject_Call + 126
	136 python.exe                          0x0000000100034224 method_call + 332
	137 python.exe                          0x000000010000e39f PyObject_Call + 126
	138 python.exe                          0x00000001000be65f slot_tp_call + 77
	139 python.exe                          0x000000010000e39f PyObject_Call + 126
	140 python.exe                          0x0000000100196c5c do_call + 553
	141 python.exe                          0x0000000100195e15 call_function + 2332
	142 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	143 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	144 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	145 python.exe                          0x0000000100057fee function_call + 586
	146 python.exe                          0x000000010000e39f PyObject_Call + 126
	147 python.exe                          0x0000000100197352 ext_do_call + 1522
	148 python.exe                          0x000000010018e42b PyEval_EvalFrameEx + 71102
	149 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	150 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	151 python.exe                          0x0000000100057fee function_call + 586
	152 python.exe                          0x000000010000e39f PyObject_Call + 126
	153 python.exe                          0x0000000100034224 method_call + 332
	154 python.exe                          0x000000010000e39f PyObject_Call + 126
	155 python.exe                          0x00000001000be65f slot_tp_call + 77
	156 python.exe                          0x000000010000e39f PyObject_Call + 126
	157 python.exe                          0x0000000100196c5c do_call + 553
	158 python.exe                          0x0000000100195e15 call_function + 2332
	159 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	160 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	161 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	162 python.exe                          0x0000000100057fee function_call + 586
	163 python.exe                          0x000000010000e39f PyObject_Call + 126
	164 python.exe                          0x0000000100197352 ext_do_call + 1522
	165 python.exe                          0x000000010018e42b PyEval_EvalFrameEx + 71102
	166 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	167 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	168 python.exe                          0x0000000100057fee function_call + 586
	169 python.exe                          0x000000010000e39f PyObject_Call + 126
	170 python.exe                          0x0000000100034224 method_call + 332
	171 python.exe                          0x000000010000e39f PyObject_Call + 126
	172 python.exe                          0x00000001000be65f slot_tp_call + 77
	173 python.exe                          0x000000010000e39f PyObject_Call + 126
	174 python.exe                          0x0000000100196c5c do_call + 553
	175 python.exe                          0x0000000100195e15 call_function + 2332
	176 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	177 python.exe                          0x0000000100196256 fast_function + 515
	178 python.exe                          0x0000000100195df9 call_function + 2304
	179 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	180 python.exe                          0x0000000100196256 fast_function + 515
	181 python.exe                          0x0000000100195df9 call_function + 2304
	182 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	183 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	184 python.exe                          0x00000001001963aa fast_function + 855
	185 python.exe                          0x0000000100195df9 call_function + 2304
	186 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	187 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	188 python.exe                          0x00000001001963aa fast_function + 855
	189 python.exe                          0x0000000100195df9 call_function + 2304
	190 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	191 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	192 python.exe                          0x00000001001963aa fast_function + 855
	193 python.exe                          0x0000000100195df9 call_function + 2304
	194 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	195 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	196 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	197 python.exe                          0x0000000100057fee function_call + 586
	198 python.exe                          0x000000010000e39f PyObject_Call + 126
	199 python.exe                          0x0000000100197352 ext_do_call + 1522
	200 python.exe                          0x000000010018e42b PyEval_EvalFrameEx + 71102
	201 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	202 python.exe                          0x00000001001963aa fast_function + 855
	203 python.exe                          0x0000000100195df9 call_function + 2304
	204 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	205 python.exe                          0x0000000100196256 fast_function + 515
	206 python.exe                          0x0000000100195df9 call_function + 2304
	207 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	208 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	209 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	210 python.exe                          0x000000010017ce4f PyEval_EvalCode + 96
	211 python.exe                          0x0000000100174b34 builtin_exec + 550
	212 python.exe                          0x00000001000872af PyCFunction_Call + 202
	213 python.exe                          0x0000000100195bac call_function + 1715
	214 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	215 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	216 python.exe                          0x00000001001963aa fast_function + 855
	217 python.exe                          0x0000000100195df9 call_function + 2304
	218 python.exe                          0x000000010018df4f PyEval_EvalFrameEx + 69858
	219 python.exe                          0x0000000100193136 _PyEval_EvalCodeWithName + 4056
	220 python.exe                          0x00000001001932aa PyEval_EvalCodeEx + 136
	221 python.exe                          0x0000000100057fee function_call + 586
	222 python.exe                          0x000000010000e39f PyObject_Call + 126
	223 python.exe                          0x0000000100202f75 RunModule + 1048
	224 python.exe                          0x0000000100204638 Py_Main + 3670
	225 python.exe                          0x00000001000011cb main + 475
	226 python.exe                          0x0000000100000fe8 start + 52
)
terminate called after throwing an instance of 'NSException'
Fatal Python error: Aborted

Current thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/tkinter/__init__.py", line 963 in update
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 562 in _update
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 583 in _bgcolor
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 1239 in bgcolor
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 1024 in clear
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 995 in __init__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 3689 in __init__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 3661 in Screen
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtle.py", line 3829 in _getscreen
  File "<string>", line 1 in mode
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/turtledemo/clock.py", line 17 in <module>
  File "<frozen importlib._bootstrap>", line 321 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1420 in exec_module
  File "<frozen importlib._bootstrap>", line 1149 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 2175 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2186 in _find_and_load
  File "<string>", line 1 in <module>
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test___all__.py", line 23 in check_all
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test___all__.py", line 104 in test_all
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 577 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 625 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 125 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 87 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 125 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 87 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 125 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 87 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/runner.py", line 168 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1724 in _run_suite
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1758 in run_unittest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1277 in <lambda>
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 967 in runtest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 532 in main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1587 in <module>
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 85 in _run_code
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1562, in main_in_temp_cwd
    main()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 738, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test___all__: Exit code -6
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=1584.387892

----------
assignee: ronaldoussoren
components: Macintosh, Tkinter
messages: 221952
nosy: haypo, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: turtle regression of issue #21823: "uncaught exception" on "AMD64 Snow Leop 3.x" buildbot
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun 30 16:05:12 2014
From: report at bugs.python.org (Karl Richter)
Date: Mon, 30 Jun 2014 14:05:12 +0000
Subject: [New-bugs-announce] [issue21885] shutil.copytree hangs (on copying
	root directory of a	lxc container) (should succeed or raise
	exception nested)
Message-ID: <1404137112.53.0.344262752308.issue21885@psf.upfronthosting.co.za>


New submission from Karl Richter:

reproduction (on Ubuntu 14.04 amd64 with lxc 1.0.4) (with python 2.7.6 and 3.4.0)

    # as root/with privileges
    lxc-create -n ubuntu-trusty-amd64 -t ubuntu -- --arch amd64 --release trusty
    lxc-stop -n ubuntu-trusty-amd64 # assert container isn't running
    cd /var/lib/lxc
    python
    > import shutil
    > shutil.copytree("ubuntu-trusty-amd64", "ubuntu-trusty-amd64-orig")
    > # never returns (after a multiple of the time rsync needs (see below) no more I/O operations)

verify behavior of rsync (3.1.0):

    # as root/with privileges
    rsync -a ubuntu-trusty-amd64/ ubuntu-trusty-amd64-orig/
    # succeeds

If the container is shutdown it should no longer point to system resources, and thus be able to get stuck on reading from a device file (and should rsync get stuck as well in this case?).

It would be nice if python fails with an exception (or succeeds, of course) instead of getting stuck.

----------
messages: 221960
nosy: krichter
priority: normal
severity: normal
status: open
title: shutil.copytree hangs (on copying root directory of a lxc container) (should succeed or raise exception nested)
versions: Python 2.7

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

From report at bugs.python.org  Mon Jun 30 16:05:18 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Jun 2014 14:05:18 +0000
Subject: [New-bugs-announce] [issue21886] asyncio: Future.set_result()
	called on cancelled Future	raises asyncio.futures.InvalidStateError
Message-ID: <1404137118.99.0.781732644161.issue21886@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Ok, I found a way to reproduce the error InvalidStateError in asyncio. I'm not sure that it's the same the error in #21447.

Output of attached bug.py in debug mode:
---
Exception in callback Future.set_result(None)
handle: <TimerHandle when=79580.878306285 Future.set_result(None)>
source_traceback: Object created at (most recent call last):
  File "/home/haypo/bug.py", line 11, in <module>
    loop.run_until_complete(task2)
  File "/home/haypo/prog/python/default/Lib/asyncio/base_events.py", line 239, in run_until_complete
    self.run_forever()
  File "/home/haypo/prog/python/default/Lib/asyncio/base_events.py", line 212, in run_forever
    self._run_once()
  File "/home/haypo/prog/python/default/Lib/asyncio/base_events.py", line 912, in _run_once
    handle._run()
  File "/home/haypo/prog/python/default/Lib/asyncio/events.py", line 96, in _run
    self._callback(*self._args)
  File "/home/haypo/prog/python/default/Lib/asyncio/tasks.py", line 241, in _step
    result = next(coro)
  File "/home/haypo/prog/python/default/Lib/asyncio/coroutines.py", line 72, in __next__
    return next(self.gen)
  File "/home/haypo/prog/python/default/Lib/asyncio/tasks.py", line 487, in sleep
    h = future._loop.call_later(delay, future.set_result, result)
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/asyncio/events.py", line 96, in _run
    self._callback(*self._args)
  File "/home/haypo/prog/python/default/Lib/asyncio/futures.py", line 326, in set_result
    raise InvalidStateError('{}: {!r}'.format(self._state, self))
asyncio.futures.InvalidStateError: CANCELLED: <Future cancelled>
---

The fix is to replace the following line of sleep():
---
    h = future._loop.call_later(delay, future.set_result, result)
---

with:
---
    def maybe_set_result(future, result):
        if not future.cancelled():
            future.set_result(result)
    h = future._loop.call_later(delay, maybe_set_result, future, result)
---

This generic issue was already discussed there:
https://groups.google.com/forum/?fromgroups#!searchin/python-tulip/set_result$20InvalidStateError/python-tulip/T1sxLqjuoVY/YghF-YsgosgJ

A patch was also proposed:
https://codereview.appspot.com/69870048/

----------
files: bug.py
messages: 221961
nosy: haypo
priority: normal
severity: normal
status: open
title: asyncio: Future.set_result() called on cancelled Future raises asyncio.futures.InvalidStateError
versions: Python 3.5
Added file: http://bugs.python.org/file35807/bug.py

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

From report at bugs.python.org  Mon Jun 30 17:11:14 2014
From: report at bugs.python.org (Joe Borg)
Date: Mon, 30 Jun 2014 15:11:14 +0000
Subject: [New-bugs-announce] [issue21887] Python3 can't detect Tcl
Message-ID: <1404141074.45.0.334350496286.issue21887@psf.upfronthosting.co.za>


New submission from Joe Borg:

Trying to configure 3.4.1 on Cent OS 6.4.  I have built Tcl and Tk, using the prefix /scratch/root.  I can confirm the builds with:

$ find /scratch/root/ -name "tcl.h"
/scratch/root/include/tcl.h

$ find /scratch/root/ -name "tk.h"
/scratch/root/include/tk.h

But, when configuring Python, they aren't picked up:

$ ./configure --prefix=/scratch/root --with-tcltk-includes=/scratch/root/include --with-tcltk-libs=/scratch/root/lib | grep tcl
checking for --with-tcltk-includes... /scratch/root/include
checking for --with-tcltk-libs... /scratch/root/lib
checking for UCS-4 tcl... no

I've tried to make install with this, but then get the usual exception from _tkinter.

----------
components: Build
messages: 221964
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Python3 can't detect Tcl
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 30 19:08:19 2014
From: report at bugs.python.org (Nathan Henrie)
Date: Mon, 30 Jun 2014 17:08:19 +0000
Subject: [New-bugs-announce] [issue21888] plistlib.FMT_BINARY behavior
	doesn't send required dict	parameter
Message-ID: <1404148099.9.0.0254576282966.issue21888@psf.upfronthosting.co.za>


New submission from Nathan Henrie:

When using the new plistlib.load and the FMT_BINARY option, line 997: 

p = _FORMATS[fmt]['parser'](use_builtin_types=use_builtin_types)

doesn't send the dict_type to _BinaryPlistParser.__init__ (line 601), which has dict_type as a required positional parameter, causing an error

def __init__(self, use_builtin_types, dict_type):

My first bugs.python.org report, hope I'm doing it right...

----------
components: Library (Lib)
messages: 221969
nosy: n8henrie
priority: normal
severity: normal
status: open
title: plistlib.FMT_BINARY behavior doesn't send required dict parameter
type: behavior
versions: Python 3.4

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