From report at bugs.python.org  Sun Sep  1 00:13:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 22:13:55 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1376341849.32.0.0261370392458.issue18720@psf.upfronthosting.co.za>
Message-ID: <3cSBfV6DXNzSbD@mail.python.org>


Roundup Robot added the comment:

New changeset 038543d34166 by Eli Bendersky in branch 'default':
Switch the AF_* and SOCK_* constants in the socket module to IntEnum.
http://hg.python.org/cpython/rev/038543d34166

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Sep  1 00:16:16 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 31 Aug 2013 22:16:16 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377987376.22.0.613222519232.issue18738@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, the final final patch.  ;)

----------
Added file: http://bugs.python.org/file31539/issue18738.stoneleaf.05.patch

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

From report at bugs.python.org  Sun Sep  1 00:18:38 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 31 Aug 2013 22:18:38 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <1377870942.88.0.889170323179.issue18720@psf.upfronthosting.co.za>
Message-ID: <52226BC0.1040601@stoneleaf.us>


Ethan Furman added the comment:

Eli Bendersky added the comment:
>
> Another issue is _intenum_converter. Ethan - do you think it belongs in the enum module as a helper function or something of the sort?

I'm fine with it being a non-public member of enum, although if we had a place for miscellaneous tools that might be a 
better spot for it.

----------

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

From report at bugs.python.org  Sun Sep  1 00:19:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Aug 2013 22:19:13 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <3cSBmd07hzzPkT@mail.python.org>


Roundup Robot added the comment:

New changeset 4d604f1f0219 by Eli Bendersky in branch 'default':
Update whatsnew/3.4.rst wrt. the socket constants switch to IntEnum
http://hg.python.org/cpython/rev/4d604f1f0219

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

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

From report at bugs.python.org  Sun Sep  1 00:21:55 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Aug 2013 22:21:55 +0000
Subject: [issue18720] Switch suitable constants in the socket module to IntEnum
In-Reply-To: <52226BC0.1040601@stoneleaf.us>
Message-ID: <CAF-Rda-aFudY=Etvig_Br=grYgXjev7A73=tJ29mU092HhQ5Yg@mail.gmail.com>


Eli Bendersky added the comment:

On Sat, Aug 31, 2013 at 3:18 PM, Ethan Furman <report at bugs.python.org>wrote:

>
> Ethan Furman added the comment:
>
> Eli Bendersky added the comment:
> >
> > Another issue is _intenum_converter. Ethan - do you think it belongs in
> the enum module as a helper function or something of the sort?
>
> I'm fine with it being a non-public member of enum, although if we had a
> place for miscellaneous tools that might be a
> better spot for it.
>

For the time being, I'm OK with Guido's suggestion to keep it lazy. As long
as it's just being used in a single module, there's not much to think
about. If we end up needing it when switching other modules, we'll see what
to do.

----------

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

From report at bugs.python.org  Sun Sep  1 00:22:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Aug 2013 22:22:11 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377987731.08.0.678877257083.issue18738@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

lgtm

----------

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

From report at bugs.python.org  Sun Sep  1 00:26:15 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 31 Aug 2013 22:26:15 +0000
Subject: [issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
Message-ID: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

I was trying to use DUMA to find errors in python runtime and it indeed killed python-based utility called emerge. Let's see what you say now:

# export LD_PRELOAD=/usr/lib64/libduma.so.0.0.0
# sysctl -w vm.max_map_count=1000000

# emerge dev-lang/python:2.7 
DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington at gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen at web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce at perens.com>

DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington at gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen at web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce at perens.com>

DUMA 2.5.15 (shared library, NO_LEAKDETECTION)
Copyright (C) 2006 Michael Eddington <meddington at gmail.com>
Copyright (C) 2002-2008 Hayati Ayguen <h_ayguen at web.de>, Procitec GmbH
Copyright (C) 1987-1999 Bruce Perens <bruce at perens.com>


DUMA Aborting: mprotect() failed: Cannot allocate memory.
Check README section 'MEMORY USAGE AND EXECUTION SPEED'
  if your (Linux) system may limit the number of different page mappings per process
Illegal instruction (core dumped)
# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 127104
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127104
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
#

(gdb) where
#0  0x00007febd6ed84d7 in kill () from /lib64/libc.so.6
#1  0x00007febd78e2f9c in DUMA_Abort () from /usr/lib64/libduma.so.0.0.0
#2  0x00007febd78e1b77 in _duma_allocate () from /usr/lib64/libduma.so.0.0.0
#3  0x00007febd78e1fef in _duma_malloc () from /usr/lib64/libduma.so.0.0.0
#4  0x00007febd7626c60 in sre_umatch (state=0x7fff96f0de10, pattern=0x7feb2804ecb8) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1173
#5  0x00007febd762932f in pattern_match (self=0x7feb2804ec58, args=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1896
#6  0x00007febd751ffcc in PyCFunction_Call (func=<built-in method match of _sre.SRE_Pattern object at remote 0x7feb2804ec58>, arg=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/methodobject.c:85
#7  0x00007febd75c4b81 in call_function (pp_stack=0x7fff96f0e6d0, oparg=1) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:4021
#8  0x00007febd75bf6c6 in PyEval_EvalFrameEx (f=Frame 0x7feb374ebce8, for file /usr/lib64/portage/pym/portage/dep/__init__.py, line 1227, in __init__ (self=<Atom(blocker=False, eapi=None) at remote 0x7fea931d5fb0>, s=u'>=gnome-base/libbonobo-2.32::gentoo-haskell', unevaluated_atom=None, allow_wildcard=True, allow_repo=True, _use=None, eapi=None, is_valid_flag=None, eapi_attrs=<_eapi_attrs at remote 0x7feb31931f48>, atom_re=<_sre.SRE_Pattern at remote 0x7feb2804ec58>, blocker_prefix=u'', blocker=False), throwflag=0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:2666

[cut]

(gdb) bt full
#0  0x00007febd6ed84d7 in kill () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007febd78e2f9c in DUMA_Abort () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#2  0x00007febd78e1b77 in _duma_allocate () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#3  0x00007febd78e1fef in _duma_malloc () from /usr/lib64/libduma.so.0.0.0
No symbol table info available.
#4  0x00007febd7626c60 in sre_umatch (state=0x7fff96f0de10, pattern=0x7feb2804ecb8) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1173
        end = 0x7fea931cfffc
        alloc_pos = 1648
        ctx_pos = 1648
        i = 128
        ret = 0
        jump = 2
        sigcount = 187
        ctx = 0x7fea931fbcf8
        nextctx = 0x7fea931fbcf8
        __PRETTY_FUNCTION__ = "sre_umatch"
#5  0x00007febd762932f in pattern_match (self=0x7feb2804ec58, args=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Modules/_sre.c:1896
        state = {ptr = 0x7fea931cffbc, beginning = 0x7fea931cff50, start = 0x7fea931cff50, end = 0x7fea931cfffc, string = u'>=gnome-base/libbonobo-2.32::gentoo-haskell', pos = 0, endpos = 43, charsize = 4, lastindex = 2, lastmark = 43, mark = {0x7fea931cff50, 0x0, 0x7fea931cff50, 0x7fea931cffbc, 0x7fea931cff50, 0x7fea931cff58, 0x7fea931cff58, 0x7fea931cffbc, 0x7fea931cff58, 0x7fea931cffa8, 0x0 <repeats 24 times>, 0x7fea931cffac, 0x7fea931cffb0, 0x7fea931cffb0, 0x7fea931cffbc, 0x7fea931cffb0, 0x7fea931cffbc, 0x7fea931cffbc, 0x7fea931cffbc, 0x7fea931cffbc, 0x7fea931cffbc, 0x0 <repeats 82 times>, 0x7fea931cffbc, 0x0, 0x7fea931cffc0, 0x0 <repeats 71 times>}, data_stack = 0x7fea931fb688 "\377\377\377\377\377\377\377\377", data_stack_size = 2424, data_stack_base = 1712, repeat = 0x0, lower = 0x7febd7620852 <sre_lower_unicode>}
        status = 32746
        string = u'>=gnome-base/libbonobo-2.32::gentoo-haskell'
        start = 0
        end = 9223372036854775807
        kwlist = {0x7febd7660ad8 "pattern", 0x7febd7660cd9 "pos", 0x7febd7660cdd "endpos", 0x0}
#6  0x00007febd751ffcc in PyCFunction_Call (func=<built-in method match of _sre.SRE_Pattern object at remote 0x7feb2804ec58>, arg=(u'>=gnome-base/libbonobo-2.32::gentoo-haskell',), kw=0x0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/methodobject.c:85
        f = 0x7feb37087fc8
        meth = 0x7febd76291f7 <pattern_match>
        self = <_sre.SRE_Pattern at remote 0x7feb2804ec58>
        size = -1282872823
#7  0x00007febd75c4b81 in call_function (pp_stack=0x7fff96f0e6d0, oparg=1) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:4021
        callargs = (u'>=gnome-base/libbonobo-2.32::gentoo-haskell',)
        flags = 3
        tstate = 0x7febd7bd1f58
        na = 1
        nk = 0
        n = 1
        pfunc = 0x7feb374ebf88
        func = <built-in method match of _sre.SRE_Pattern object at remote 0x7feb2804ec58>
        x = <_sre.SRE_Pattern at remote 0x7feb2804ec58>
        w = 0x0
#8  0x00007febd75bf6c6 in PyEval_EvalFrameEx (f=Frame 0x7feb374ebce8, for file /usr/lib64/portage/pym/portage/dep/__init__.py, line 1227, in __init__ (self=<Atom(blocker=False, eapi=None) at remote 0x7fea931d5fb0>, s=u'>=gnome-base/libbonobo-2.32::gentoo-haskell', unevaluated_atom=None, allow_wildcard=True, allow_repo=True, _use=None, eapi=None, is_valid_flag=None, eapi_attrs=<_eapi_attrs at remote 0x7feb31931f48>, atom_re=<_sre.SRE_Pattern at remote 0x7feb2804ec58>, blocker_prefix=u'', blocker=False), throwflag=0) at /mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Python/ceval.c:2666
        sp = 0x7feb374ebf90
        stack_pointer = 0x7feb374ebf98
        next_instr = 0x7feb930726fd "}\f"
        opcode = 131
        oparg = 1
        why = WHY_NOT
        err = 0
        x = u'>=gnome-base/libbonobo-2.32::gentoo-haskell'
        v = <unknown at remote 0x83>
        w = 'match'
        u = False
        t = <unknown at remote 0x1>
        stream = 0x0
        fastlocals = 0x7feb374ebe70
        freevars = 0x7feb374ebf88
        retval = 0x0
        tstate = 0x7febd7bd1f58
        co = 0x7feb92e96f70
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1

[cut]

----------
components: Interpreter Core
files: core.emerge.4097.gdb.txt
messages: 196684
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file31540/core.emerge.4097.gdb.txt

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

From report at bugs.python.org  Sun Sep  1 00:28:16 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 31 Aug 2013 22:28:16 +0000
Subject: [issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
In-Reply-To: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>
Message-ID: <1377988096.34.0.578555108498.issue18897@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

To a naive user two places with numbers are in the stacktrace:

size = -1282872823

and
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1

----------

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

From report at bugs.python.org  Sun Sep  1 00:46:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 31 Aug 2013 22:46:16 +0000
Subject: [issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
In-Reply-To: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>
Message-ID: <1377989176.74.0.969528844725.issue18897@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is a malloc() failure, not a Python bug ("DUMA Aborting: mprotect() failed: Cannot allocate memory").

Line 1173 in _sre.c allocates a fixed-sized structure (SRE_REPEAT):

            ctx->u.rep = (SRE_REPEAT*) PyObject_MALLOC(sizeof(*ctx->u.rep));

That structure is probably 32 bytes long in 64-bit mode.

----------
nosy: +haypo, pitrou
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Sep  1 00:49:10 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 31 Aug 2013 22:49:10 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <1377989350.04.0.634207467603.issue18738@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Looks good to me, too. Thanks for considering all of the feedback!

----------

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

From report at bugs.python.org  Sun Sep  1 01:16:37 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sat, 31 Aug 2013 23:16:37 +0000
Subject: [issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
In-Reply-To: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>
Message-ID: <1377990997.61.0.808263479972.issue18897@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

I was actually printing every 10 seconds how much memory it was using, the last before got killed was:

  PID    VSZ   RSS     TIME     ELAPSED %CPU %MEM COMMAND
 4097 4938188 2445712 00:22:44    25:04 90.7 15.0 /usr/bin/python2.7 /usr/bin/emerge dev-lang/python:2.7

Provided I have 16GB RAM then maybe it was really some limit in the Bourne shell or OS which prevented DUMA to obtain more memory. But my own python-based app can can grow to even 12GB RSS on this computer so I wonder what limit would be the cause. Probably some overhead due to DUMA.



I increased shell limits and looks it can continue further so far:

vostro crashtest # ulimit -l unlimited
vostro crashtest # ulimit -s unlimited
vostro crashtest # ulimit -i unlimited
vostro crashtest # 
vostro crashtest # ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 127104
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
#


Currently the emerge through DUMA is at:

  PID    VSZ   RSS     TIME     ELAPSED %CPU %MEM COMMAND
 9528 6121764 3041960 00:34:16    56:05 61.1 18.6 /usr/bin/python2.7 /usr/bin/emerge dev-lang/python:2.7

and still continues ...


Sorry, should better read the main STDERR output before diving into gdb stacktraces. I thought those negative numbers are a true sign of an error. ;)

----------

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

From report at bugs.python.org  Sun Sep  1 01:25:16 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 31 Aug 2013 23:25:16 +0000
Subject: [issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
In-Reply-To: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>
Message-ID: <1377991516.33.0.278379786429.issue18897@psf.upfronthosting.co.za>


Tim Peters added the comment:

Note this line in your first post:

    DUMA Aborting: mprotect() failed: Cannot allocate memory.

Python never calls mprotect(), but DUMA() probably does.  Also note what it said after that:

   Check README section 'MEMORY USAGE AND EXECUTION SPEED'
   if your (Linux) system may limit the number of different page
   mappings per process

That is, it may be a limitation of your kernel.

In any case, there's no Python issue here, so closing this.

----------
nosy: +tim.peters
stage:  -> committed/rejected

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

From report at bugs.python.org  Sun Sep  1 02:04:15 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 01 Sep 2013 00:04:15 +0000
Subject: [issue17628] str==str: compare the first character before calling
 memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1377993855.48.0.423478155584.issue17628@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Regarding benchmarking and code performance inspection, maybe you want to try on your linux box:

perf top
perf stat /usr/bin/python mytest.py

http://perf.wiki.kernel.org/

----------
nosy: +mmokrejs

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

From report at bugs.python.org  Sun Sep  1 02:26:08 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sun, 01 Sep 2013 00:26:08 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377995168.27.0.820602922435.issue18843@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

OK, I backed off the aggressive CFLAGS/CXXFLAGS to " -ggdb -pipe", and ran "emerge =dev-lang/python-2.7.5-r1" *once* each with and without the 'EXTRA_ECONF="--with-pydebug"' flag.  Compiled with GCC 4.7.3.

No crash, same test results as described previously for GCC 4.6.4.

If you have other suggestions, let me know.

----------

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

From report at bugs.python.org  Sun Sep  1 02:33:22 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 00:33:22 +0000
Subject: [issue18835] Add aligned memroy variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377995602.25.0.838170574477.issue18835@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Adding yet another API to allocate memory has a cost

Please don't FUD this one to death.  Aligned memory access is sometimes important and we currently have no straight-forward way to achieve it.  If you're truly worried about adding single new function to the public C API, we can create  just a single internal function:  void *PyMem_RawMallocAligned(size_t size, size_t alignment).

> aligning every data structure on a cacheline boundary 
> doesn't sound like a very good idea

We don't have to align EVERY data structure.  But I do have immediate beneficial use cases for set tables and for data blocks in deque objects.  I need this function and would appreciate your help in fitting it in nicely with the current memory management functions and macros.

----------

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

From report at bugs.python.org  Sun Sep  1 02:33:44 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 00:33:44 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377995624.36.0.798359421491.issue18835@psf.upfronthosting.co.za>


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


----------
title: Add aligned memroy variants to the suite of PyMem functions/macros -> Add aligned memory variants to the suite of PyMem functions/macros

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

From report at bugs.python.org  Sun Sep  1 02:35:47 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 00:35:47 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377995747.2.0.911587716216.issue18835@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  1 02:36:11 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 00:36:11 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1377995771.98.0.681989822972.issue18835@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Adding yet another API to allocate memory has a cost

Please don't FUD this one to death.  Aligned memory access is sometimes important and we currently have no straight-forward way to achieve it.  If you're truly worried about adding single new function to the public C API, we can create  just a single internal function:  void * _PyMem_RawMallocAligned(size_t size, size_t alignment).

> aligning every data structure on a cacheline boundary 
> doesn't sound like a very good idea

We don't have to align EVERY data structure.  But I do have immediate beneficial use cases for set tables and for data blocks in deque objects.  I need this function and would appreciate your help in fitting it in nicely with the current memory management functions and macros.

----------

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

From report at bugs.python.org  Sun Sep  1 02:47:56 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 00:47:56 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377996476.5.0.136828235745.issue18843@psf.upfronthosting.co.za>


Tim Peters added the comment:

Thanks for that, Stephen!  I don't know of anything else you could try that would be helpful.  The OP doesn't appear able to reproduce his problems either, and last I heard he was off running `emerge` under DUMA:

    http://duma.sourceforge.net/

Why?  Hope springs eternal ;-)

----------

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

From report at bugs.python.org  Sun Sep  1 03:46:28 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sun, 01 Sep 2013 01:46:28 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1377999988.51.0.70377220492.issue18843@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

Yeah, hope is a good thing.  But I've spent the last 20 years debugging an X11 application based on a Lisp interpreter, I save hope for fireflies, my dog, and my daughter these days. :-)

To the OP:

I don't follow Gentoo closely, but I have acquaintances who do.  Between them and the occasional foray into the forums, I've gotten the impression that providing CFLAGS for optimization is associated with having hard-to-debug problems.  They increase performance noticably only in a few applications.  Python being a  dynamic language, function calls and even variable references can be quite inefficient anyway.  So I see no good reason to compile Python with aggressive CFLAGS, because it should be used only for moderately performance sensitive applications and as "glue code" and to provide UI.  Instead, use them only for the specific applications that benefit (I suppose matplotlib *might* be one).

Second, I tend to agree with the maintainers.  The packages.env / pydebug.conf approach is the right thing for this kind of variant build.

Third, you said you hoped to get better backtraces from --with-pydebug.  That's a vain hope.  Such options are intended to get better backtraces of C code from coredumps where the interpreter breaks down, not of Python code induced by Python exceptions caused by problems in user code.  If you have trouble interpreting a backtrace, ask on python-list at python.org or comp.lang.python (they mirror each other, you only need one).  If, after understanding the backtrace, you have an idea for way to get a better backtrace in this case, you can suggest it on python-ideas at python.org.

Unfortunately, reporting "this backtrace is unintelligible, please improve it" as an RFE on the tracker is likely to get the reply "You're right, but we don't know how at this time.  Patches welcome!"  But you could try that if all else fails.

----------

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

From report at bugs.python.org  Sun Sep  1 03:58:54 2013
From: report at bugs.python.org (Martin Panter)
Date: Sun, 01 Sep 2013 01:58:54 +0000
Subject: [issue18335] Add textwrap.dedent, .indent, as str methods.
In-Reply-To: <1372656829.33.0.351971247179.issue18335@psf.upfronthosting.co.za>
Message-ID: <1378000734.59.0.18123441179.issue18335@psf.upfronthosting.co.za>


Martin Panter added the comment:

If this goes ahead, would a bytes.dedent() method be also considered? I recently discovered that textwrap.dedent() does not work on bytes() in Python 3. I would have used it for the contents of an input file in a test case.

For the record there?s an older issue 1237680 on this, rejected in 2005.

----------
nosy: +vadmium

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

From report at bugs.python.org  Sun Sep  1 04:18:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Sep 2013 02:18:13 +0000
Subject: [issue18738] String formatting (% and str.format) issues with Enum
In-Reply-To: <1376488136.41.0.00729697162282.issue18738@psf.upfronthosting.co.za>
Message-ID: <3cSJ4N2yNBzSCt@mail.python.org>


Roundup Robot added the comment:

New changeset 058cb219b3b5 by Ethan Furman in branch 'default':
Close #18738:  Route __format__ calls to mixed-in type for mixed Enums (such as IntEnum).
http://hg.python.org/cpython/rev/058cb219b3b5

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Sep  1 04:27:13 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 01 Sep 2013 02:27:13 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <1378002433.02.0.681655371071.issue18745@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Fixed formatting in patch.  ;)

----------
Added file: http://bugs.python.org/file31541/issue18745.stoneleaf.02.patch

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

From report at bugs.python.org  Sun Sep  1 06:07:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Sep 2013 04:07:14 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1378008434.54.0.182426822567.issue18896@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  1 06:22:36 2013
From: report at bugs.python.org (Phil Webster)
Date: Sun, 01 Sep 2013 04:22:36 +0000
Subject: [issue18592] IDLE: Unit test for SearchDialogBase.py
In-Reply-To: <1375146770.41.0.774627283078.issue18592@psf.upfronthosting.co.za>
Message-ID: <1378009356.61.0.0887689180392.issue18592@psf.upfronthosting.co.za>


Phil Webster added the comment:

Added tests for labels, a mock function for widget creation, a back option for radiobuttontests, and the docstring fixes that Terry mentioned.

----------
Added file: http://bugs.python.org/file31542/18592_test_searchdialog2.diff

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

From report at bugs.python.org  Sun Sep  1 06:40:17 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 04:40:17 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1378010417.88.0.912571579472.issue18835@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching a patch for what I would like to do with the alignment functions and macros.

----------
keywords: +patch
Added file: http://bugs.python.org/file31543/align.diff

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

From report at bugs.python.org  Sun Sep  1 06:41:53 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 04:41:53 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1378010513.51.0.595609194517.issue11798@psf.upfronthosting.co.za>


Tim Peters added the comment:

All the buildbots are failing due to changeset 868ad6fa8e68 - I'm going to back it out.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Sun Sep  1 06:45:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Sep 2013 04:45:00 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <3cSMKl4l3gz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 7035b5d8fc0f by Tim Peters in branch 'default':
Back out 868ad6fa8e68 - it left all the buildbots failing.
http://hg.python.org/cpython/rev/7035b5d8fc0f

----------

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

From report at bugs.python.org  Sun Sep  1 06:58:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Sep 2013 04:58:56 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <3cSMdq5lGdzPrk@mail.python.org>


Roundup Robot added the comment:

New changeset 39781c3737f8 by Andrew Svetlov in branch 'default':
Issue #11798: fix tests for regrtest -R :
http://hg.python.org/cpython/rev/39781c3737f8

----------

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

From report at bugs.python.org  Sun Sep  1 07:02:31 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 05:02:31 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1378011751.32.0.500077706901.issue18896@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would like to see the limitation removed.  IIRC, Guido has said the same.

That said, the limitation isn't due to anything in the namedtuple code.  Instead, it is due to a CPython bytecode implementation detail that limits all function/method definitions to no more than 255 arguments.

----------

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

From report at bugs.python.org  Sun Sep  1 07:13:31 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 01 Sep 2013 05:13:31 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1378012411.15.0.381353618737.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Now 'regrtest.py -j4 -R : ' passes.
Do we need to add parameter for disabling tests cleanup to TestSuite, TestLoader and TestProgrm constructors?

----------

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

From report at bugs.python.org  Sun Sep  1 07:14:53 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 05:14:53 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
Message-ID: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Once http://bugs.python.org/issue18835 is resolved, I would like to see the various set optimizations applied to dictionaries as well:

* Move the key before the hash in the dict struct (the key is accessed more frequently in the code and being in the first struct position allows it to be looked-up without a struct offset).

* Don't INCREF and DECREF dummy objects.  Only one reference needs to be held.  See http://bugs.python.org/issue18797

* Reduce the cost of hash collisions by inspecting nearby dict entries for matches prior to moving on to other probes elsewhere in memory.  See http://bugs.python.org/issue18771

* Make the previous improvement more effective by using aligned memory allocations for the dict tables.  See http://bugs.python.org/issue18835

Collectively, these optimizations can substantially improve dictionary performance.

----------
components: Interpreter Core
messages: 196706
nosy: haypo, pitrou, rhettinger, tim.peters
priority: low
severity: normal
status: open
title: Apply the setobject optimizations to dictionaries
type: performance
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  1 07:20:42 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 01 Sep 2013 05:20:42 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1378012842.08.0.366626921397.issue18882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Uploaded new patch.

> - the doc addition needs a "versionadded" tag
Fixed.

> - "The main thread is the thread that the OS creates to run application.": I would rephrase this "In normal conditions, the main thread is the thread from which the Python interpreter was started".
Fixed.

> - in the tests:
> +        self.assertEqual(data, "Thread-1\nTrue\nTrue\n")
> 
> Hmm, how do you know it will be called "Thread-1"?
> I would give a specific name to the Thread, so as to make the test deterministic.
In this test main thread after forking is always first thread created by python. That's why it always is called 'Thread-1'. 

> +        self.assertEqual(rc, 0)
> 
> You don't need this, it is already ensured by assert_python_ok().
Fixed.

> - in threading.py, why doesn't _exitfunc() reuse the _main_thread global variable, instead of taking it as a parameter?
Fixed.

----------
Added file: http://bugs.python.org/file31544/issue18882-4.diff

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

From report at bugs.python.org  Sun Sep  1 07:36:19 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 05:36:19 +0000
Subject: [issue18826] reversed() requires a sequence - Could work on any
 iterator?
In-Reply-To: <1377371302.25.0.787358043575.issue18826@psf.upfronthosting.co.za>
Message-ID: <1378013779.63.0.0569211770556.issue18826@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry, Guido rejected this idea a long time ago.  We do have the __reversed__ hook so you can add reverse iteration to your own classes where it makes sense.

Doing it in the general case is more problematic.  Some data sources such as generators can't be run backwards so they would have to be run to exhaustion and saved in memory to support reversed iteration.  If a user wants this behavior, it is trivial to achieve it by running reversed(list(it)).  The user is in for unhappiness though if the underlying iterator is infinite or huge ;-)

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sun Sep  1 07:38:28 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 05:38:28 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378013908.09.0.209567580788.issue18844@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for the overall idea.  I'll take a detailed look at the patch when I get a chance.

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

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

From report at bugs.python.org  Sun Sep  1 07:39:38 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 01 Sep 2013 05:39:38 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1378013978.95.0.644565457663.issue18898@psf.upfronthosting.co.za>


Eric Snow added the comment:

+1 This is worth trying.

----------
nosy: +Mark.Shannon, eric.snow

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

From report at bugs.python.org  Sun Sep  1 07:43:42 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 05:43:42 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378014222.58.0.103201321318.issue18844@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The sticking point is going to be that we don't want to recompute the cumulative weights for every call to weighted_choice.

So there should probably be two functions:

  cw = make_cumulate_weights(weight_list) 
  x = choice(choice_list, cw)

This is similar to what was done with string.maketrans() and str.translate().

----------

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

From report at bugs.python.org  Sun Sep  1 07:50:01 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sun, 01 Sep 2013 05:50:01 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378014601.69.0.815913693015.issue18844@psf.upfronthosting.co.za>


Changes by Westley Mart?nez <anikom15 at gmail.com>:


----------
nosy: +anikom15

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

From report at bugs.python.org  Sun Sep  1 08:23:52 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 06:23:52 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
In-Reply-To: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>
Message-ID: <1378016632.94.0.122274155572.issue18821@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  1 08:30:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 06:30:04 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
 chain_iterable.
In-Reply-To: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>
Message-ID: <1378017004.31.0.033917997867.issue18752@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  1 08:41:01 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 06:41:01 +0000
Subject: [issue18313] In itertools recipes repeatfunc() defines a non-keyword
 argument as keyword
In-Reply-To: <1372309261.95.0.7034101172.issue18313@psf.upfronthosting.co.za>
Message-ID: <1378017661.11.0.849139587691.issue18313@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger

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

From report at bugs.python.org  Sun Sep  1 08:46:52 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 06:46:52 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378018012.89.0.0306353775512.issue18726@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

-1 Once the positional arguments are in the wild, you can't take them away without breaking a lot of code. 

This code was available as a third-party module prior to inclusion in Python and had many happy users.  If the positional arguments had been a sticking point, it would have been known long ago.

The time to express these concerns is when a module is being added.  Afterwards, the API churn just isn't worth it.  We don't want to create more obstacles to upgrading or converting from Python 2.

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

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

From report at bugs.python.org  Sun Sep  1 09:28:06 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 01 Sep 2013 07:28:06 +0000
Subject: [issue18893] invalid exception handling in Lib/ctypes/macholib/dyld.py
In-Reply-To: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>
Message-ID: <1378020486.14.0.371555618034.issue18893@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Sep  1 09:30:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Sep 2013 07:30:38 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1378020638.92.0.121235505145.issue18835@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> Please don't FUD this one to death.  Aligned memory access is
> sometimes important and we currently have no straight-forward
> way to achieve it.

I guess that a simple way to cut the discussion short would be to have a first implementation, and run some benchmarks to measure the benefits.

I can certainly see the benefit of cacheline-aligned data structures in multithreaded code (to avoid false sharing/cacheline bouncing): I'm really curious to see how much this would benefit in a single-threaded workload.

----------
nosy: +neologix

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

From report at bugs.python.org  Sun Sep  1 09:37:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Sep 2013 07:37:02 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1377975532.11.0.266254760256.issue12304@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZBijT2rcx7RHkhJm8FXT6ka8LggJ7AG2zjJwhbtTBedg@mail.gmail.com>


STINNER Victor added the comment:

> Why do you not provide a structure to decode the bytes? I thought relying
on ctypes in the stdlib was not advised...

We should expose it. The ctypes was just a poof of concept.

----------

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

From report at bugs.python.org  Sun Sep  1 10:22:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Sep 2013 08:22:51 +0000
Subject: [issue18571] Implementation of the PEP 446: non-inheritable file
 descriptors
In-Reply-To: <1374940021.73.0.887568879163.issue18571@psf.upfronthosting.co.za>
Message-ID: <3cSS966CHKzRjV@mail.python.org>


Roundup Robot added the comment:

New changeset c27527dce71e by Victor Stinner in branch 'default':
Issue #18571: Merge duplicate test code
http://hg.python.org/cpython/rev/c27527dce71e

----------

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

From report at bugs.python.org  Sun Sep  1 10:43:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 08:43:40 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378025020.92.0.734177884165.issue18844@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> A more efficient approach for many use-cases would do the precomputation once, returning some kind of 'distribution' object from which samples can be generated.

I like the idea about adding a family of distribution generators. They should check input parameters and make a precomputation and then generate infinite sequence of specially distributed random numbers.

----------

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

From report at bugs.python.org  Sun Sep  1 10:44:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 08:44:49 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378025089.16.0.406266596731.issue18726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> We don't want to create more obstacles to upgrading or converting from Python 2.

But these obstacles already exists.

The 10th parameter of dump() is "encoding" in Python 2 and simplejson, and "default" in Python 3.

The 12th parameter of dump() is "use_decimal" simplejson, and "sort_keys" in Python 2.

The 2nd parameter of load() is "encoding" in Python 2 and simplejson, and "cls" in Python 3.

Due to the fact that most arguments are boolean or accepts None some shifting of positional arguments can left unnoticed long time and causes subtle bugs when upgrading from Python 2 to Python 3 or switching between stdlib json module and simplejson.

Proposed change doesn't break any code at first stage, it just adds deprecation warning about using dangerous non-portable feature. We can defer forbidding positional parameters until Python 2 will gone and simplejson will be changed to keyword-only parameters too.

----------

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

From report at bugs.python.org  Sun Sep  1 11:45:54 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 01 Sep 2013 09:45:54 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1378028754.23.0.965745148045.issue18553@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

None that I know of.

----------

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

From report at bugs.python.org  Sun Sep  1 14:39:11 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 01 Sep 2013 12:39:11 +0000
Subject: [issue18750] '' % [1] doesn't fail
In-Reply-To: <1376586656.31.0.488715338617.issue18750@psf.upfronthosting.co.za>
Message-ID: <1378039151.45.0.993754256163.issue18750@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Ok. Close as won't fix.
Please reopen if needed.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Sep  1 14:49:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Sep 2013 12:49:58 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1378039798.4.0.304270087215.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New patch (version 2):

- an hash table entry can now contain the data directly instead of a pointer to the data
- _tracemalloc._get_stats() copies the hash table to not have to lock the hash table too long, which will be especially useful for TRACE_RAW_MALLOC
- Add get_object_trace() function which returns a namedtuple
- get_process_memory() returns a namedtuple
- DisplayGarbage class has been removed: the PEP 442 has been implemented, it is no more interesting to trace uncollectable objects because they became very rare. If you still want to do that, get_object_trace() is available


TODO:

- TRACE_RAW_MALLOC define is still disabled because it introduces a deadlock when PyMem_RawMalloc() is called indirectly by Py_NewInterpreter()
- minor pending FIXME in the code
- review the high level API: add an helper to build a diff between two snapshots and drop colors (not portable)?


test_capi deadlock with TRACE_RAW_MALLOC:

    test_subinterps (test.test_capi.SubinterpreterTest) ... ^C
    Program received signal SIGINT, Interrupt.
    0xb7fdd424 in __kernel_vsyscall ()
    (gdb) where
    ...
    #2  0x081abc1c in PyCOND_TIMEDWAIT (cond=0x83470e0, mut=0x8347110, us=5000) at Python/condvar.h:103
    #3  0x081ac55c in take_gil (tstate=0x8349c78) at Python/ceval_gil.h:224
    #4  0x081ad0a9 in PyEval_RestoreThread (tstate=0x8349c78) at Python/ceval.c:443
    #5  0x081f08e3 in PyGILState_Ensure () at Python/pystate.c:786
    #6  0x0808df1b in trace_get_filename (trace=0x84c26b8, gil_held=0) at ./Modules/_tracemalloc.c:555
    #7  0x0808e314 in trace_log_alloc (ptr=0x84c9f18, size=52, gil_held=0) at ./Modules/_tracemalloc.c:698
    #8  0x0808e449 in trace_malloc (ctx=0x8342890, size=52, gil_held=0) at ./Modules/_tracemalloc.c:744
    #9  0x0808e5b8 in trace_raw_malloc (ctx=0x8342890, size=52) at ./Modules/_tracemalloc.c:811
    #10 0x0805d32a in PyMem_RawMalloc (size=52) at Objects/obmalloc.c:256
    #11 0x081eeb79 in PyInterpreterState_New () at Python/pystate.c:63
    #12 0x08060c8b in Py_NewInterpreter () at Python/pythonrun.c:700
    #13 0xb74d4b90 in run_in_subinterp ()
    #14 0x080e9e7a in PyCFunction_Call ()
    ...

----------
Added file: http://bugs.python.org/file31545/tracemalloc-2.patch

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

From report at bugs.python.org  Sun Sep  1 14:56:26 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 01 Sep 2013 12:56:26 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1378040186.49.0.400539522566.issue18885@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy: +arigo

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

From report at bugs.python.org  Sun Sep  1 15:13:05 2013
From: report at bugs.python.org (koobs)
Date: Sun, 01 Sep 2013 13:13:05 +0000
Subject: [issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
In-Reply-To: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za>
Message-ID: <1378041185.53.0.971598533695.issue6299@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

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

From report at bugs.python.org  Sun Sep  1 16:37:04 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 14:37:04 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378046224.47.0.370545684575.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

[Raymond Hettinger]
> The sticking point is going to be that we don't want to recompute the 
> cumulative weights for every call to weighted_choice.

> So there should probably be two functions:

>  cw = make_cumulate_weights(weight_list) 
>  x = choice(choice_list, cw)

That's pretty much how I broke things up when I decided to test out optimization with lru_cache.  That version of the patch is now attached.

[Serhiy Storchaka]
> I like the idea about adding a family of distribution generators. 
> They should check input parameters and make a precomputation and then > generate infinite sequence of specially distributed random numbers.

Would these distribution generators be implemented internally (see attached patch) or publicly exposed?

----------
Added file: http://bugs.python.org/file31546/weighted_choice_v2.diff

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

From report at bugs.python.org  Sun Sep  1 16:45:49 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 14:45:49 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378046749.88.0.786766733508.issue18844@psf.upfronthosting.co.za>


Changes by Madison May <madison.may at students.olin.edu>:


Removed file: http://bugs.python.org/file31546/weighted_choice_v2.diff

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

From report at bugs.python.org  Sun Sep  1 16:47:16 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 14:47:16 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378046836.21.0.861872554146.issue18844@psf.upfronthosting.co.za>


Changes by Madison May <madison.may at students.olin.edu>:


Added file: http://bugs.python.org/file31547/weighted_choice_v2.diff

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

From report at bugs.python.org  Sun Sep  1 19:12:18 2013
From: report at bugs.python.org (Meador Inge)
Date: Sun, 01 Sep 2013 17:12:18 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <1378055538.01.0.63727431623.issue16826@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
assignee:  -> meador.inge
stage: patch review -> commit review

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

From report at bugs.python.org  Sun Sep  1 19:15:43 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 17:15:43 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378055743.1.0.609382309527.issue18889@psf.upfronthosting.co.za>


Tim Peters added the comment:

Suggest caution here.  test_sax fails the same way for me too (Windows Vista), under both the released 3.3.2 and a Python built from the current hg default branch.

However, these files (test.xml and test.xml.out) have not changed since the Python 2.7 line - the \r\n line endings have _always_ been there, and test_sax works fine under (e.g.) Python 2.7.5 on Windows.

So it's not that the files have changed, it must be that Python is behaving differently.

Unfortunately, I don't know anything about what test_sax is trying to do.  I do see that under 2.7, test_sax does

xml_test_out = open(TEST_XMLFILE_OUT).read()

but 3.3 does

with open(TEST_XMLFILE_OUT, 'rb') as f:
    xml_test_out = f.read()

That is, 2.7 opens the file for reading in text mode, but 3.3 opens it in binary mode.  That makes a big difference for text files under Windows.

It's also disturbing that the Windows buildbots don't fail.  There is no change in "environment" that should affect the bytes seen when a file is read - and the buildbots "should be" seeing, byte for byte, the same files developers and users see.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Sun Sep  1 19:34:52 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 01 Sep 2013 17:34:52 +0000
Subject: [issue18899] make pystone.py Py3 compatible in benchmark suite
Message-ID: <1378056891.98.0.165106942337.issue18899@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

diff --git a/performance/pystone.py b/performance/pystone.py
--- a/performance/pystone.py
+++ b/performance/pystone.py
@@ -59,9 +59,9 @@
 
 def main(loops=LOOPS):
     benchtime, stones = pystones(loops)
-    print "Pystone(%s) time for %d passes = %g" % \
-          (__version__, loops, benchtime)
-    print "This machine benchmarks at %g pystones/second" % stones
+    print("Pystone(%s) time for %d passes = %g" %
+          (__version__, loops, benchtime))
+    print("This machine benchmarks at %g pystones/second" % stones)
 
 
 def pystones(loops=LOOPS):
@@ -72,7 +72,7 @@
 Char1Glob = '\0'
 Char2Glob = '\0'
 Array1Glob = [0]*51
-Array2Glob = map(lambda x: x[:], [Array1Glob]*51)
+Array2Glob = list(map(lambda x: x[:], [Array1Glob]*51))
 PtrGlb = None
 PtrGlbNext = None

----------
components: Benchmarks
messages: 196723
nosy: scoder
priority: normal
severity: normal
status: open
title: make pystone.py Py3 compatible in benchmark suite
type: behavior

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

From report at bugs.python.org  Sun Sep  1 19:43:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Sep 2013 17:43:20 +0000
Subject: [issue18899] make pystone.py Py3 compatible in benchmark suite
In-Reply-To: <1378056891.98.0.165106942337.issue18899@psf.upfronthosting.co.za>
Message-ID: <1378057400.13.0.95147652986.issue18899@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Oh, pystone... I didn't know we had included that particular horror in the benchmark suite :-)

----------
nosy: +brett.cannon, pitrou
stage:  -> patch review
versions: +3rd party

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

From report at bugs.python.org  Sun Sep  1 19:48:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Sep 2013 17:48:36 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1378057716.36.0.0989504113104.issue18553@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Are there tests for this?

Not sure what you mean: there are several tests using isatty() in test suite.

Regardless, there is no #ifdef around the isatty() definition in posixmodule.c, so I can only assume it exists on all platforms.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sun Sep  1 20:04:21 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 18:04:21 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378058661.05.0.254563335495.issue18889@psf.upfronthosting.co.za>


Tim Peters added the comment:

Seeing as Python 3 _does_ open these files in binary mode, I fiddled my local .hgeol to mark the test files as BIN (then deleted the test data directory and did an "hg revert" on the directory).  Then test_sax passes.  

I don't know whether that's the proper fix, but it works ;-)

----------
Added file: http://bugs.python.org/file31548/eol-patch.txt

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

From report at bugs.python.org  Sun Sep  1 20:49:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 18:49:29 +0000
Subject: [issue18900] Add the random.distrib module
Message-ID: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In some functions in the random module checking input arguments and precomputation takes a considerable portion of time. Here is a sample implementation of new random.distrib module which provides alternative faster interface to generating of random distributed values. It contains generators which generates values with same distributions as functions with same name in the random module.

Benchmark results:

                                random distrib
random()                         0.061   0.055  1.12
randrange(0, 100, 5)             1.494   0.620  2.41
randint(1, 100)                  1.283   0.551  2.33
uniform(-10.0, 10.0)             0.332   0.121  2.73
triangular(0.0, 10.0, 6.0)       0.661   0.317  2.09
gauss(5.0, 2.0)                  0.707   0.280  2.53
normalvariate(5.0, 2.0)          0.867   0.553  1.57
lognormvariate(5.0, 2.0)         1.078   0.640  1.68
expovariate(0.1,)                0.508   0.293  1.73
vonmisesvariate(1.0, 1.0)        1.201   0.671  1.79
gammavariate(0.35, 1.45)         1.117   0.508  2.20
betavariate(2.71828, 3.14159)    2.868   1.776  1.61
paretovariate(5.0,)              0.493   0.238  2.07
weibullvariate(1.0, 3.0)         0.670   0.402  1.67
choice([0, 1, 2, 3, 4, 5, 6...   0.887   0.594  1.49

Distrib functions are 1.5-2.8 times faster than random functions. Weighted choice() function (see issue18844) can be even dozens times faster (depends on size of the input).

In additional some random generators (i.e. gauss()) looks simpler when implemented as generators. distrib.gauss() is twice faster than distrib.normalvariate() (both generates numbers with same distribution) and I think some other generators can be implemented more efficient in generator style.

----------
components: Library (Lib)
files: distrib.py
messages: 196727
nosy: mark.dickinson, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add the random.distrib module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31549/distrib.py

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

From report at bugs.python.org  Sun Sep  1 20:51:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 18:51:05 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378061465.76.0.46631268803.issue18900@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file31550/distrib_bench.py

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

From report at bugs.python.org  Sun Sep  1 21:16:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 19:16:37 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378062997.36.0.538625707694.issue18844@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Would these distribution generators be implemented internally (see attached patch) or publicly exposed?

See issue18900. Even if this proposition will be rejected I think we should publicly expose weighted choice_generator(). A generator or a builder which returns function are only ways how efficiently implement this feature. Use lru_cache isn't good because several choice generators can be used in a program and because it left large data in a cache long time after it was used.

----------

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

From report at bugs.python.org  Sun Sep  1 21:20:23 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 01 Sep 2013 19:20:23 +0000
Subject: [issue18901] sunau.getparams should return a namedtuple
Message-ID: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

This is similar to what was done for issue17818 and issue17487 and will gain for all the three audio libraries, aifc, wave and sunau a similar API. Patch and tests attached.

----------
components: Library (Lib)
files: sunau.patch
keywords: patch
messages: 196729
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: sunau.getparams should return a namedtuple
versions: Python 3.4
Added file: http://bugs.python.org/file31551/sunau.patch

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

From report at bugs.python.org  Sun Sep  1 21:28:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 19:28:37 +0000
Subject: [issue18105] ElementTree writes invalid files when UTF-16 encoding is
 specified
In-Reply-To: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za>
Message-ID: <1378063717.16.0.522061256553.issue18105@psf.upfronthosting.co.za>


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


----------
nosy: +scoder

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

From report at bugs.python.org  Sun Sep  1 21:44:51 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Sep 2013 19:44:51 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378064691.28.0.712947233782.issue18889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Two things have happened with Python: we switched bytes from 'text or binary' to 'binary (or text)' in 3.0. We switched from svn to hg in 3.2. When did test_sax start failing? I have no idea. Until recently, there were much worse problems with the test suite on desktop windows; it sometimes quit before getting to 'sax'.

Email and its tests (which had the same eol issue) were heavily revised in 3.3; I do not know if the test that failed in 3.3 failed earlier or not. Another failing email test was added in 3.4.

David, Antoine: Tim questions/challenges the solution pushed in #12037.

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

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

From report at bugs.python.org  Sun Sep  1 21:47:51 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 19:47:51 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378064871.27.0.734456572423.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

> Use lru_cache isn't good because several choice generators can be used in a program and because it left large data in a cache long time after it was used.

Yeah, I just did a quick search of the stdlib and only found one instance of lru_cache in use -- another sign that lru_cache is a bad choice.

----------

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

From report at bugs.python.org  Sun Sep  1 21:58:26 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 19:58:26 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378065506.6.0.202046518314.issue18900@psf.upfronthosting.co.za>


Madison May added the comment:

I like the core idea of a family of random generators, but it feels like a new module that's nearly identical to random introduces a lot of repeated code.

Perhaps adding an additional optional arg ('generator=False', for example) to these functions in the random module would be a bit simpler.

----------
nosy: +madison.may

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

From report at bugs.python.org  Sun Sep  1 22:04:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Sep 2013 20:04:42 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378065882.22.0.903689437573.issue18889@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Marking the files as "binary" (really "don't touch") in .hgeol sounds reasonable to me.

----------

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

From report at bugs.python.org  Sun Sep  1 22:16:51 2013
From: report at bugs.python.org (Jon Foster)
Date: Sun, 01 Sep 2013 20:16:51 +0000
Subject: [issue16531] Allow IPNetwork to take a tuple
In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za>
Message-ID: <1378066611.77.0.654627411847.issue16531@psf.upfronthosting.co.za>


Changes by Jon Foster <jongfoster at users.sourceforge.net>:


----------
nosy: +jongfoster

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

From report at bugs.python.org  Sun Sep  1 22:26:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 20:26:50 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378067210.58.0.672124691419.issue18889@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Nit 2: why? The test passes as is.

Currently test.xml and test.xml.out contain only ascii characters. But this can be changed in future. Actually I had added non-ascii characters to other test data and this had exposed some bugs in test suite.

> When did test_sax start failing? I have no idea.

I guess it becomes after my commit in issue1470548 a half year ago.

All proposed fixes are good enough. Feel free to commit what you prefers.

----------

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

From report at bugs.python.org  Sun Sep  1 22:33:03 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 20:33:03 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378067583.03.0.617252322799.issue18889@psf.upfronthosting.co.za>


Tim Peters added the comment:

test_email still passed on Windows under 3.2.5 (but test_sax failed).  test_email and test_sax both fail under 3.3.2.

I'll just push the change to .hgeol - minimally invasive, fixes the immediate problem, and it appears these "really are" binary files.

----------

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

From report at bugs.python.org  Sun Sep  1 22:47:03 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 01 Sep 2013 20:47:03 +0000
Subject: [issue18105] ElementTree writes invalid files when UTF-16 encoding is
 specified
In-Reply-To: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za>
Message-ID: <1378068423.68.0.798635355226.issue18105@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I can well imagine that the serialiser is broken for this in Py2.x, given that the API accepts byte strings and stores them as such. The fix might be as simple as decoding byte strings in the serialiser before writing them out. Involves a pretty high performance regression, though (and ET's serialiser is known to be rather slow anyway).

Not sure if the current behaviour should be changed in 2.x.

In any case, it's a duplicate of the other ticket, which was *not* fixed for 2.7.

----------

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

From report at bugs.python.org  Sun Sep  1 22:53:17 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Sep 2013 20:53:17 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378068797.65.0.878552915788.issue18889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Having the files be the same on all systems seems the right solution. Changing .hgeol should do that, at least for the repository. Let's hope the Windows .msi installer leave line endings alone. I should install the a,b,c releases just to run the test suite with them.

Side note: just above the quoted context in .hgeol is
Lib/email/test/data/msg_26.txt = BIN
which does not exist now.
I suspect it should be removed as the obsolete old version of
Lib/test/test_email/data/msg_26.txt = BIN
which is in the quoted context.

----------

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

From report at bugs.python.org  Sun Sep  1 23:00:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Sep 2013 21:00:28 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378069228.6.0.316861859442.issue18900@psf.upfronthosting.co.za>


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


----------
nosy: +tim.peters

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

From report at bugs.python.org  Sun Sep  1 23:02:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Sep 2013 21:02:15 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <3cSn1M26SJzQkJ@mail.python.org>


Roundup Robot added the comment:

New changeset 8efcf3c823f9 by Tim Peters in branch '3.3':
Fix issue 18889: test_sax: multiple failures on Windows desktop.
http://hg.python.org/cpython/rev/8efcf3c823f9

New changeset 25211a22228b by Tim Peters in branch 'default':
Merge fix from 3.3 into default.
http://hg.python.org/cpython/rev/25211a22228b

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

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

From report at bugs.python.org  Sun Sep  1 23:03:11 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 21:03:11 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378069391.34.0.506399777283.issue18889@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Sep  1 23:06:53 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 01 Sep 2013 21:06:53 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378069613.25.0.657149747788.issue18889@psf.upfronthosting.co.za>


Tim Peters added the comment:

Terry, yes, the installer won't change line endings.  I think - we'll find out for sure next time a release is cut - LOL ;-)

Agreed that Lib/email/test/data/msg_26.txt is probably obsolete.  Fix it, if you like!  It's helpful to get rid of obsolete cruft.

----------

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

From report at bugs.python.org  Sun Sep  1 23:10:53 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Sun, 01 Sep 2013 21:10:53 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1378069853.77.0.597127130619.issue13107@psf.upfronthosting.co.za>


Elazar Gershuni added the comment:

I think in such case it is reasonable to fail silently, since the information will not be readable anyway.
Is a patch like the attached acceptable? (Sorry, I am new here)

results:

>>> import os, argparse; p = argparse.ArgumentParser(prog='PROG')
>>> os.environ['COLUMNS'] = '0'
>>> print(p.format_help())
usage: PROG
       
       [-h]

optional arguments:
  -h, --help  

>>>

----------
keywords: +patch
nosy: +elazar
Added file: http://bugs.python.org/file31552/fixargparse.patch

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

From report at bugs.python.org  Sun Sep  1 23:17:48 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 21:17:48 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378070268.2.0.353615818635.issue18844@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I like the idea about adding a family of distribution generators

Let's stay focused on the OP's feature request for a weighted version of choice().

For the most part, it's not a good idea to "just add" a family of anything to the standard library.  We wait for user requests and use cases to guide the design and error on the side of less, rather than more.  This helps avoid bloat.   Also, it would be a good idea to start something like this as a third-party to module to let it iterate and mature before deciding whether there was sufficient user uptake to warrant inclusion in the standard library.

For the current request, we should also do some research on existing solutions in other languages.  This isn't new territory.  What do R, SciPy, Fortran, Matlab or other statistical packages already do?  Their experiences can be used to inform our design.  Alan Kay's big criticism of Python developers is that they have a strong propensity invent from scratch rather than taking advantage of the mountain of work done by the developers who came before them.

----------

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

From report at bugs.python.org  Mon Sep  2 00:01:49 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 01 Sep 2013 22:01:49 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1378072909.11.0.879016555693.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

I'd rather not propagate more options all the way through, especially as this is some thing that should be decided by the test framework and is unlikely to be something you want to turn on and off per test run (which is what command line options are for). Frameworks that want to disable this behaviour should use a TestSuite that overrides _removeAtIndex.

----------

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

From report at bugs.python.org  Mon Sep  2 00:15:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Sep 2013 22:15:30 +0000
Subject: [issue18889] test_sax: multiple failures on Windows desktop
In-Reply-To: <1377912811.58.0.0769335003135.issue18889@psf.upfronthosting.co.za>
Message-ID: <1378073730.52.0.174471576548.issue18889@psf.upfronthosting.co.za>


R. David Murray added the comment:

For test_email, the fix was correct because the *test* didn't care about what line ending the source file had.  I can't speak for sax.

----------

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

From report at bugs.python.org  Mon Sep  2 00:24:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 22:24:41 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378074281.69.0.93294526141.issue18900@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Of course if this idea will be accepted we can turn current functions in the random module into wrappers around generators from the distrib module.

E.g.:

    def triangular(self, *args, **kwargs):
        return next(triangular(*args, random=self, **kwargs))

----------

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

From report at bugs.python.org  Mon Sep  2 00:28:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 22:28:41 +0000
Subject: [issue18901] sunau.getparams should return a namedtuple
In-Reply-To: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>
Message-ID: <1378074521.79.0.262651350495.issue18901@psf.upfronthosting.co.za>


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


----------
nosy: +r.david.murray
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Mon Sep  2 00:33:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Sep 2013 22:33:45 +0000
Subject: [issue18105] ElementTree writes invalid files when UTF-16 encoding is
 specified
In-Reply-To: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za>
Message-ID: <1378074825.21.0.669153714566.issue18105@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Due to the fact that such bug was not fixed even in 3.2 where it was more ease I doubt that it worth to fix in 2.7.

----------

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

From report at bugs.python.org  Mon Sep  2 00:35:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Sep 2013 22:35:18 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1378074918.09.0.433811495942.issue9709@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This warning still appears on buildbots running with warnings turned on.

----------
nosy: +terry.reedy
versions: +Python 3.4 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Sep  2 00:46:47 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Sep 2013 22:46:47 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378075607.76.0.797232009781.issue18726@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, please resist the urge to engage in API churn.  We've had zero user requests to abandon the current API.  I'm not a fan of the current positional arguments, but changing it isn't really worth it (creating disruption with nearly zero benefit, no new functionality and possibly slowing down the calls in module where people seem to really care about speed).

Bob, would you please weigh-in on this one.  You have the best appreciation for the needs of the established user base.

----------
assignee: rhettinger -> bob.ippolito
priority: normal -> low

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

From report at bugs.python.org  Mon Sep  2 00:50:35 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Sep 2013 22:50:35 +0000
Subject: [issue12420] distutils tests fail if PATH is not defined
In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za>
Message-ID: <1378075835.26.0.838947780944.issue12420@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I just ran into this issue (same I believe) running the test suite with installed, versus repository, python on win7, but get a different traceback.

Traceback (most recent call last):
 ...\lib\distutils\tests\test_build_ext.py"
   line 156, in test_optional_extension # or
   line 316, in test_get_outputs
    cmd.run)  # should raise an error
 ...\lib\unittest\case.py", line 570, in assertRaises
    return context.handle('assertRaises', callableObj, args, kwargs)
 ...\lib\unittest\case.py", line 135, in handle
    callable_obj(*args, **kwargs)
 ...\lib\distutils\command\build_ext.py", line 354, in run
    self.build_extensions()
 ...\lib\distutils\command\build_ext.py", line 463, in build_extensions
    self.build_extension(ext)
 ...\lib\distutils\command\build_ext.py", line 518, in build_extension
    depends=ext.depends)
 ...\lib\distutils\msvc9compiler.py", line 460, in compile
    self.initialize()
 ...\lib\distutils\msvc9compiler.py", line 371, in initialize
    vc_env = query_vcvarsall(VERSION, plat_spec)
 ...\lib\distutils\msvc9compiler.py", line 287, in query_vcvarsall
    raise ValueError(str(list(result.keys())))
ValueError: ['path']

I agree with  ?ric that the test should be skipped if it cannot go on.
Wrapping
        self.assertRaises((UnknownFileError, CompileError),
                          cmd.run)  # should raise an error
and
        cmd.run()
with
try:...except ValueError: <skip> would fix this issue on Windows. So would skipping if sys.platform == 'win32' and '+' not in sys.version (repository builds have a '+' and the test currently work for them).  However, neither solution would work on *nix, which seems to have a completely different failure path to the same end result.

Are distutils and test_distutils maintained at all? msvc9compiler.py (2005) says it also works with vc10 (2008, used for 2.7) but makes no mention of vc11 (2010, used for 3.3,3.4).

Nick, what do you think we should do with this? I think that when python is installed and working as well as we expect, the test suite should pass, so any failures indicate a problem with the particular installation. I think this is especially important on Windows, with newbies who do not know distutils from, say, itertools.

----------
nosy: +ncoghlan, terry.reedy
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Mon Sep  2 01:06:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Sep 2013 23:06:59 +0000
Subject: [issue18870] eval() uses latin-1 to decode str
In-Reply-To: <1377713902.12.0.966249722349.issue18870@psf.upfronthosting.co.za>
Message-ID: <3cSqnH19Jqz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset 869cbcabb934 by Benjamin Peterson in branch '2.7':
document that various functions that parse from source will interpret things as latin-1 (closes #18870)
http://hg.python.org/cpython/rev/869cbcabb934

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Sep  2 01:08:54 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 23:08:54 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378076934.77.0.274572144087.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

> What do R, SciPy, Fortran, Matlab or other statistical packages already do? 

Numpy avoids recalculating the cumulative distribution by introducing a 'size' argument to numpy.random.choice().  The cumulative distribution is calculated once, then 'size' random choices are generated and returned.

Their overall implementation is quite similar to the method suggested in the python docs.  

>>> choices, weights = zip(*weighted_choices)
>>> cumdist = list(itertools.accumulate(weights))
>>> x = random.random() * cumdist[-1]
>>> choices[bisect.bisect(cumdist, x)]

The addition of a 'size' argument to random.choice() has already been discussed (and rejected) in Issue18414, but this was on the grounds that the standard idiom for generating a list of random choices ([random.choice(seq) for i in range(k)]) is obvious and efficient.

----------

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

From report at bugs.python.org  Mon Sep  2 01:10:55 2013
From: report at bugs.python.org (Bob Ippolito)
Date: Sun, 01 Sep 2013 23:10:55 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378077055.75.0.229497923438.issue18726@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

I tend to agree with Raymond here. While I also don't like the positional arguments, I don't think the benefit of API churn them is high enough to remove them. Other than this issue, I have not seen any requests for this change.

I have seen problems because there are positional arguments, but only when people are subclassing these classes. Allowing for subclasses was never a good idea, and is actively discouraged in current simplejson documentation. The dumps default/loads object_hook functionality is sufficient and doesn't have the fragile base class problem. This functionality is is fully compatible with all versions of the library that are in use, back to v1.8 in March 2008, including Python 2.6's json library which IIRC is based on v1.9.

----------
assignee: bob.ippolito -> rhettinger

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

From report at bugs.python.org  Mon Sep  2 01:20:41 2013
From: report at bugs.python.org (Madison May)
Date: Sun, 01 Sep 2013 23:20:41 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378077641.81.0.107078633482.issue18900@psf.upfronthosting.co.za>


Madison May added the comment:

> ...we can turn current functions in the random module into wrappers 
> around generators from the distrib module.

Makes sense.

In light of Raymond's comments on code bloat in issue18844, perhaps this module could be added to PyPi to see whether or not there's interest in this kind of functionality?

----------

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

From report at bugs.python.org  Mon Sep  2 01:39:22 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 01 Sep 2013 23:39:22 +0000
Subject: [issue18795] pstats - allow stats sorting by cumulative time per call
 and total time per call
In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za>
Message-ID: <1378078762.31.0.414825238045.issue18795@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

I'd change cumulativepercall and totalpercall to cumpercall and percall (and/or intpercall) but that's a detail, this patch works for me.

Data structure affected by this patch is produced and consumed internally by the sort method so it looks like nothing changes from the point of view of client code.

----------
nosy: +jstasiak

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

From report at bugs.python.org  Mon Sep  2 01:41:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Sep 2013 23:41:05 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1378078865.56.0.0500020932009.issue18730@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep  2 01:45:20 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 01 Sep 2013 23:45:20 +0000
Subject: [issue18105] ElementTree writes invalid files when UTF-16 encoding is
 specified
In-Reply-To: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za>
Message-ID: <1378079120.13.0.902197310837.issue18105@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

What Serhiy said.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Sep  2 01:48:52 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 01 Sep 2013 23:48:52 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <1378079332.42.0.910924003488.issue18745@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

lgtm

----------

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

From report at bugs.python.org  Mon Sep  2 01:50:25 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 01 Sep 2013 23:50:25 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1378079425.83.0.475793840049.issue18850@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Can this be transformed into a new issue that succinctly summarizes what the new requested feature is, and why it's useful?

----------

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

From report at bugs.python.org  Mon Sep  2 01:51:19 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 01 Sep 2013 23:51:19 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1378079479.97.0.381770024869.issue18693@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Do we have enough evidence to open a new bug vs. help() ?

----------

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

From report at bugs.python.org  Mon Sep  2 02:03:41 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 00:03:41 +0000
Subject: [issue18902] Make ET event handling more modular to allow custom
 targets for the non-blocking parser
Message-ID: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

As issue #17741 shows in detail, there's a number of implementation problems in the current ET that make a fully non-blocking parser more difficult to implement than it should be.

The main problem is that XMLParser._setevents relies on internal implementation details of the default TreeBuilder to do some of its tasks.

This has to be decoupled from implementation details completely. An XMLParser already has a non-blocking input side (feed/close) and a callback "push" API to the target. The API has to be fully expanded to include start-ns/end-ns and any other events that are required to allow custom tree builders as targets. This would make it possible to layer XMLPullParser on top of the stock XMLParser coupled with a special target that collects "events" from the callback calls.

----------
components: Library (Lib)
messages: 196758
nosy: eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: Make ET event handling more modular to allow custom targets for the non-blocking parser
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep  2 02:05:25 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 00:05:25 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1378080325.77.0.263192697631.issue17741@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm closing this issue as fixed because the feature was implemented. As discussed, opened a new issue (#18902) to discuss re-designing some parts of the current code that would allow a nicer implementation of this feature. Anyone interested in the subject - feel free to subscribe yourself there.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Sep  2 02:29:05 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 02 Sep 2013 00:29:05 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1378079479.97.0.381770024869.issue18693@psf.upfronthosting.co.za>
Message-ID: <5223DBD1.6030503@stoneleaf.us>


Ethan Furman added the comment:

I've done some more investigation today but I can't tell if the issue is solely in help or if it's some wierd 
interaction between help and _EnumMeta.

----------

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

From report at bugs.python.org  Mon Sep  2 02:31:23 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 02 Sep 2013 00:31:23 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378081883.53.0.574671494759.issue18844@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

Honestly, I think adding weights to any of the random functions are trivial enough to implement as is.  Just because something becomes a common task does not mean it ought to be added to the stdlib.

Anyway, from a user point of view, I think it'd be useful to be able to send a sequence to a function that'll weight the sequence for use by random.

----------

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

From report at bugs.python.org  Mon Sep  2 02:39:55 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 00:39:55 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <5223DBD1.6030503@stoneleaf.us>
Message-ID: <CAF-Rda95q2GVsngCnXjioej72PX0HqMzEVorSv0bgr3mm1P2Aw@mail.gmail.com>


Eli Bendersky added the comment:

On Sun, Sep 1, 2013 at 5:29 PM, Ethan Furman <report at bugs.python.org> wrote:

>
> Ethan Furman added the comment:
>
> I've done some more investigation today but I can't tell if the issue is
> solely in help or if it's some wierd
> interaction between help and _EnumMeta.
>

So you can't reproduce it with other classes that have a custom __dir__ ?

----------

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

From report at bugs.python.org  Mon Sep  2 03:04:02 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 02 Sep 2013 01:04:02 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <CAF-Rda95q2GVsngCnXjioej72PX0HqMzEVorSv0bgr3mm1P2Aw@mail.gmail.com>
Message-ID: <5223E403.3050008@stoneleaf.us>


Ethan Furman added the comment:

Nope, not yet.  And even a simple dummy metaclass with a custom __dir__ worked fine.

----------

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

From report at bugs.python.org  Mon Sep  2 03:22:26 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 02 Sep 2013 01:22:26 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <5223E403.3050008@stoneleaf.us>
Message-ID: <5223E853.5070401@stoneleaf.us>


Ethan Furman added the comment:

What I know for sure:

   1) if something is added to dir() that does not live in __dict__, help() breaks.

   2) if a certain something or some things are removed from dir(), help() breaks.  I'm not yet certain which somethings 
apply here.

----------

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

From report at bugs.python.org  Mon Sep  2 03:33:35 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 02 Sep 2013 01:33:35 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
Message-ID: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>


New submission from Westley Mart?nez:

Hi, I'm not sure if this would be considered a bug or a feature request, but IDLE's file-completion is case-sensitive in Windows (e.g. if I have a file named ABBA and I type in 'abb' + tab, ABBA won't pop up.  Since Windows files systems are not case-sensitive, it might make sense for the file-completion to disregard case as well.  I'm not sure if this behaviour is preferred, however, so I'll leave that up for discussion.

I tested the behaviour on 3.3 and 3.4; I assume it's the same for other versions as well.

----------
components: IDLE, Windows
messages: 196765
nosy: anikom15
priority: normal
severity: normal
status: open
title: IDLE file-completion is case-sensitive in Windows
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Sep  2 03:41:01 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 02 Sep 2013 01:41:01 +0000
Subject: [issue18902] Make ET event handling more modular to allow custom
 targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1378086061.92.0.631052597997.issue18902@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

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

From report at bugs.python.org  Mon Sep  2 04:43:45 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 02 Sep 2013 02:43:45 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1378089824.99.0.159184868115.issue11798@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Ok. Let's close issue.

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

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

From report at bugs.python.org  Mon Sep  2 05:00:51 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 02 Sep 2013 03:00:51 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378090851.87.0.850160515374.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

Just ran across a great blog post on the topic of weighted random generation from Eli Bendersky for anyone interested:
http://eli.thegreenplace.net/2010/01/22/weighted-random-generation-in-python/

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Mon Sep  2 05:39:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Sep 2013 03:39:34 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
Message-ID: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/test/test_os.py in class FDInheritanceTests, we have an unnecessary test, which is test_set_inheritable. What test_set_inheritable tests is already being covered by test_get_inheritable.

Also, I think test_get_inheritable should be renamed to test_set_inheritable.

Please, see the patch to see what I mean.

----------
components: Tests
files: remove_unnecessary_test_fd_inheritable.patch
keywords: patch
messages: 196768
nosy: haypo, vajrasky
priority: normal
severity: normal
status: open
title: Unnecessary test in file descriptor inheritance test
versions: Python 3.4
Added file: http://bugs.python.org/file31553/remove_unnecessary_test_fd_inheritable.patch

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

From report at bugs.python.org  Mon Sep  2 05:51:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Sep 2013 03:51:59 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <1378093919.77.0.0429356719749.issue18745@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

To test the infinity, negative infinity, and NaN (Not a Number), you named the test as test_weird_floats. So implicitely, you admitted that they are floats but just weird. Yet, you named the sample data test class as NotNum. Implicitely, you were saying they are not numbers. This is contradictory.

In my personal opinion, I disagree slightly with the naming because infinity and negative infinity are numbers. Why not name it WeirdNum (or SpecialNum) to make it more mathematically correct and consistent with the test naming?

----------

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

From report at bugs.python.org  Mon Sep  2 05:52:38 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 02 Sep 2013 03:52:38 +0000
Subject: [issue18902] Make ET event handling more modular to allow custom
 targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1378093958.12.0.617457708693.issue18902@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Mon Sep  2 05:57:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 02 Sep 2013 03:57:52 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1378093919.77.0.0429356719749.issue18745@psf.upfronthosting.co.za>
Message-ID: <52240CC2.7080907@stoneleaf.us>


Ethan Furman added the comment:

>From my layman's perspective they are all not numbers -- you can't add 5 to any of them and get a number back that is 5 
more than you started with.

By I have no problem with your proposed name -- I'll make the change.

----------

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

From report at bugs.python.org  Mon Sep  2 06:51:51 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 02 Sep 2013 04:51:51 +0000
Subject: [issue10984] argparse add_mutually_exclusive_group should accept
 existing arguments to register conflicts
In-Reply-To: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za>
Message-ID: <1378097511.44.0.143934936566.issue10984@psf.upfronthosting.co.za>


paul j3 added the comment:

A possible further tweak is, in take_action(), test for conflicts before adding the action to 'seen_non_default_actions'

            if argument_values is not action.default:
                #seen_non_default_actions.add(action)
                for conflict_action in action_conflicts.get(action, []):
                    if conflict_action in seen_non_default_actions:
                       ...
                seen_non_default_actions.add(action)

This does not cause problems with any existing tests, but makes it possible to add an action twice to a group.  Why do that?  To prevent an action from occurring more than once.  For some actions like 'count' and 'append' repeated use is expected, but for others it isn't expected, and may sometimes be a nuisance (the last occurrence is the one that sticks). 

An example use would be:

    parser = argparse.ArgumentParser(prog="PROG",
        formatter_class=argparse.MultiGroupHelpFormatter)
    action = parser.add_argument('--arg', help='use this argument only once')
    group1 = parser.add_mutually_exclusive_group(action, action)
    args  = parser.parse_args()

calling this with:

    python3 test_once.py --arg test --arg next

would produce this error message:

    usage: PROG [-h] [--arg ARG | --arg ARG]
    PROG: error: argument --arg: not allowed with argument --arg

The usage and error message aren't as clear as they might be if this feature was added 'from scratch'.  But for a minor change like this, that may be an acceptable price.

----------

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

From report at bugs.python.org  Mon Sep  2 08:05:04 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 02 Sep 2013 06:05:04 +0000
Subject: [issue18893] invalid exception handling in Lib/ctypes/macholib/dyld.py
In-Reply-To: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>
Message-ID: <1378101904.08.0.594263358251.issue18893@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Your analysis looks correct to me, that is "raise e" is supposed to raise the exception caught by the first try block.

----------

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

From report at bugs.python.org  Mon Sep  2 08:43:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Sep 2013 06:43:15 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <1378104195.45.0.531361179435.issue18904@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep  2 10:15:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Sep 2013 08:15:23 +0000
Subject: [issue18745] Test enum in test_json is ignorant of infinity value
In-Reply-To: <1376553540.47.0.197538167938.issue18745@psf.upfronthosting.co.za>
Message-ID: <3cT3y21mMhzNH3@mail.python.org>


Roundup Robot added the comment:

New changeset 50e583f20d78 by Ethan Furman in branch 'default':
Close #18745: Improve enum tests in test_json for infinities and NaN.
http://hg.python.org/cpython/rev/50e583f20d78

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Sep  2 10:24:24 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 02 Sep 2013 08:24:24 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1378110264.53.0.800408145829.issue9709@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Is the distutils freeze still in place? If not, I'll commit initfunc2.patch.

----------

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

From report at bugs.python.org  Mon Sep  2 10:59:39 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Sep 2013 08:59:39 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1378112379.28.0.42114264148.issue18828@psf.upfronthosting.co.za>


Berker Peksag added the comment:

How about adding a codecs.register like public API for 3.4+?

    import urllib.parse

    urllib.parse.schemes.register('redis', 'rtmp')

or:

    urllib.parse.urljoin('redis://localhost:6379/0', '/1', scheme='redis')

or just:

    urllib.parse.schemes.extend(['redis', 'rtmp'])

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Mon Sep  2 11:47:16 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Mon, 02 Sep 2013 09:47:16 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes
 inside	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1378115236.01.0.742362989416.issue18709@psf.upfronthosting.co.za>


Mat?j Stuchl?k added the comment:

Doing 'valgrind --suppressions=valgrind-python.supp ./python Lib/tests/regrtest.py test_ssl.py' I'm getting

==11944== LEAK SUMMARY:
==11944==    definitely lost: 32 bytes in 1 blocks
==11944==    indirectly lost: 392 bytes in 16 blocks
==11944==      possibly lost: 27,008 bytes in 58 blocks
==11944==    still reachable: 4,267,092 bytes in 4,124 blocks
==11944==         suppressed: 32 bytes in 1 blocks

and as far as I can tell the leak is introduced by this patch, I can't seem to figure out what could be causing it though.

----------
nosy: +sYnfo

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

From report at bugs.python.org  Mon Sep  2 12:26:14 2013
From: report at bugs.python.org (koobs)
Date: Mon, 02 Sep 2013 10:26:14 +0000
Subject: [issue15018] Incomplete Python LDFLAGS and CPPFLAGS used for
 extension modules on posix
In-Reply-To: <1338987103.32.0.200789346526.issue15018@psf.upfronthosting.co.za>
Message-ID: <1378117574.83.0.380840277473.issue15018@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

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

From report at bugs.python.org  Mon Sep  2 12:51:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Sep 2013 10:51:30 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes
 inside	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1378119090.24.0.712236634974.issue18709@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I can't reproduce the memory leak. valgrind's output doesn't show suspicious memory leaks.

./configure --with-pydebug --config-cache
valgrind --suppressions=Misc/valgrind-python.supp ./python Lib/test/test_ssl.py

Python 3.4 tip
--------------

==26085== HEAP SUMMARY:
==26085==     in use at exit: 1,286,703 bytes in 3,778 blocks
==26085==   total heap usage: 210,241 allocs, 206,463 frees, 62,923,839 bytes allocated
==26085== 
==26085== LEAK SUMMARY:
==26085==    definitely lost: 0 bytes in 0 blocks
==26085==    indirectly lost: 0 bytes in 0 blocks
==26085==      possibly lost: 1,148,038 bytes in 555 blocks
==26085==    still reachable: 138,665 bytes in 3,223 blocks
==26085==         suppressed: 0 bytes in 0 blocks


Python 3.4.0a1 (without patch)
------------------------------
==32513== HEAP SUMMARY:
==32513==     in use at exit: 1,708,298 bytes in 4,120 blocks
==32513==   total heap usage: 237,965 allocs, 233,845 frees, 94,637,130 bytes allocated
==32513== 
==32513== LEAK SUMMARY:
==32513==    definitely lost: 0 bytes in 0 blocks
==32513==    indirectly lost: 0 bytes in 0 blocks
==32513==      possibly lost: 1,568,077 bytes in 893 blocks
==32513==    still reachable: 140,221 bytes in 3,227 blocks
==32513==         suppressed: 0 bytes in 0 blocks
==32513== Rerun with --leak-check=full to see details of leaked memory


Python 2.7 tip
--------------

==3184== HEAP SUMMARY:
==3184==     in use at exit: 6,411,895 bytes in 4,757 blocks
==3184==   total heap usage: 16,245 allocs, 11,488 frees, 32,948,412 bytes allocated
==3184== 
==3184== LEAK SUMMARY:
==3184==    definitely lost: 0 bytes in 0 blocks
==3184==    indirectly lost: 0 bytes in 0 blocks
==3184==      possibly lost: 1,823,596 bytes in 1,505 blocks
==3184==    still reachable: 4,588,299 bytes in 3,252 blocks
==3184==         suppressed: 0 bytes in 0 blocks

----------

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

From report at bugs.python.org  Mon Sep  2 13:12:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 11:12:08 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378120328.36.0.643457007354.issue18900@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> In light of Raymond's comments on code bloat in issue18844, perhaps this module could be added to PyPi to see whether or not there's interest in this kind of functionality?

Agree. At first look there are no module which provides such features on PyPI. On the second hand NumpPy provides efficient C-implemented functions which are 2-10 times faster than proposed pure Python iterators. Due to this fact I withdraw my proposition. Anyone who need a performance in random generation with specific distribution can use NumPy.

----------
resolution:  -> rejected
status: open -> pending

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

From report at bugs.python.org  Mon Sep  2 13:38:34 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Mon, 02 Sep 2013 11:38:34 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes
 inside	subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1378121914.32.0.936574305817.issue18709@psf.upfronthosting.co.za>


Mat?j Stuchl?k added the comment:

Oh, I only checked the particular commit that fixed this issue in 2.6 (50803d881a92). I am not getting any leaks in 2.6 tip either, so I guess it was fixed somewhere along the way.

Sorry for the confusion!

----------

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

From report at bugs.python.org  Mon Sep  2 13:55:06 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 02 Sep 2013 11:55:06 +0000
Subject: [issue18550] internal_setblocking() doesn't check return value of
 fcntl()
In-Reply-To: <1374694779.19.0.0902694218162.issue18550@psf.upfronthosting.co.za>
Message-ID: <1378122906.03.0.74819483434.issue18550@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

oops. This should be the right patch.

----------
Added file: http://bugs.python.org/file31554/issue-18550.txt

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

From report at bugs.python.org  Mon Sep  2 14:34:51 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 02 Sep 2013 12:34:51 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1378125291.92.0.697638281354.issue18693@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

That help() is confused by __dir__ is documented in #16938. 

AFAIK help is fairly fragile in its expectations of the attributes present on classes and the correspondence between dir(cls) and list(cls.__dict__), and that is something that could be fixed in pydoc and/or inspect.

----------

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

From report at bugs.python.org  Mon Sep  2 16:45:06 2013
From: report at bugs.python.org (Sigmund Augdal)
Date: Mon, 02 Sep 2013 14:45:06 +0000
Subject: [issue15310] urllib: Support for multiple WWW-Authenticate headers
 and/or multiple challenges per header
In-Reply-To: <1341873649.53.0.673715238265.issue15310@psf.upfronthosting.co.za>
Message-ID: <1378133106.18.0.63798160071.issue15310@psf.upfronthosting.co.za>


Sigmund Augdal added the comment:

I'm also affected by this. Could someone please apply the patch or provide some reason why it could not be applied?

----------
nosy: +Sigmund.Augdal

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

From report at bugs.python.org  Mon Sep  2 16:46:00 2013
From: report at bugs.python.org (Sigmund Augdal)
Date: Mon, 02 Sep 2013 14:46:00 +0000
Subject: [issue13323] urllib2 does not correctly handle
 multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1378133160.54.0.043166474804.issue13323@psf.upfronthosting.co.za>


Sigmund Augdal added the comment:

Can someone please apply this patch or provide a reason why it should not be applied?

----------
nosy: +Sigmund.Augdal

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

From report at bugs.python.org  Mon Sep  2 17:31:51 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 02 Sep 2013 15:31:51 +0000
Subject: [issue13323] urllib2 does not correctly handle
 multiple	www-authenticate headers in an HTTP response
In-Reply-To: <1320249966.17.0.892468926199.issue13323@psf.upfronthosting.co.za>
Message-ID: <1378135911.3.0.247946587641.issue13323@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Sigmund: Sorry for the delay. I shall act on this.

----------

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

From report at bugs.python.org  Mon Sep  2 17:34:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 15:34:08 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1378136048.08.0.601314131306.issue12892@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which combines both Kang-Hao's patches, synchronized with tip, fixed and optimized.

Unfortunately even optimized this patch slowdown encoding/decoding some data. Here are some benchmark results (benchmarking tools are here: https://bitbucket.org/storchaka/cpython-stuff/src/default/bench).

3.3          3.4          3.4
             unpatched    patched

969 (+12%)   978 (+11%)   1087   encode  utf-16le  'A'*10000
2453 (-62%)  2356 (-61%)  923    encode  utf-16le  '\u0100'*10000
222 (+12%)   224 (+11%)   249    encode  utf-16le    '\U00010000'+'\u0100'*9999
784 (+6%)    791 (+5%)    831    encode  utf-16be  'A'*10000
750 (-4%)    752 (-4%)    719    encode  utf-16be  '\u0100'*10000
233 (+2%)    235 (+1%)    238    encode  utf-16be    '\U00010000'+'\u0100'*9999

531 (-7%)    545 (-9%)    494    encode  utf-32le  'A'*10000
383 (-38%)   385 (-38%)   239    encode  utf-32le  '\u0100'*10000
324 (-24%)   325 (-25%)   245    encode  utf-32le    '\U00010000'+'\u0100'*9999
544 (-10%)   545 (-10%)   492    encode  utf-32be  'A'*10000
384 (-38%)   384 (-38%)   239    encode  utf-32be  '\u0100'*10000
325 (-25%)   325 (-25%)   245    encode  utf-32be    '\U00010000'+'\u0100'*9999

682 (+5%)    679 (+5%)    715    decode  utf-16le  'A'*10000
607 (+1%)    610 (+1%)    614    decode  utf-16le  '\u0100'*10000
550 (+1%)    554 (+0%)    556    decode  utf-16le    '\U00010000'+'\u0100'*9999
609 (+0%)    600 (+2%)    610    decode  utf-16be  'A'*10000
464 (+1%)    466 (+1%)    470    decode  utf-16be  '\u0100'*10000
432 (+1%)    431 (+1%)    435    decode  utf-16be    '\U00010000'+'\u0100'*9999

103 (+272%)  374 (+2%)    383    decode  utf-32le  'A'*10000
91 (+264%)   390 (-15%)   331    decode  utf-32le  '\u0100'*10000
90 (+257%)   393 (-18%)   321    decode  utf-32le    '\U00010000'+'\u0100'*9999
103 (+269%)  393 (-3%)    380    decode  utf-32be  'A'*10000
91 (+263%)   406 (-19%)   330    decode  utf-32be  '\u0100'*10000
90 (+257%)   393 (-18%)   321    decode  utf-32be    '\U00010000'+'\u0100'*9999

Performance of utf-16 decoding is not changed. utf-16 encoder is 2.5 times slowed for UCS2 data (it was just memcpy) but still 3+ times faster than 2.7 and 3.2 (issue15026). Due to additional optimization it now even slightly faster for some other data. There is a patch for speed up UTF-32 encoding (issue15027), it should help to compensate it's performance degradation. UTF-32 decoder already 3-4 times faster than in 3.3 (issue14625).

I don't see performance objection against this patch.

----------
Added file: http://bugs.python.org/file31555/utf_16_32_surrogates_2.patch

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

From report at bugs.python.org  Mon Sep  2 17:41:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 15:41:48 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1378136508.52.0.977856056658.issue18818@psf.upfronthosting.co.za>


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


----------
keywords: +needs review

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

From report at bugs.python.org  Mon Sep  2 17:43:32 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Sep 2013 15:43:32 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1378136612.73.0.442880256104.issue9709@psf.upfronthosting.co.za>


?ric Araujo added the comment:

The feature freeze was lifted at PyCon 2013.  This patch can be committed in the default branch.  Could you add a test?

----------
assignee: tarek -> eric.araujo
versions:  -3rd party, Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Sep  2 17:44:22 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Sep 2013 15:44:22 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1378136662.02.0.754581918009.issue9709@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Ignore my comment about a test, you already replied to that :)  Please commit.

----------
assignee: eric.araujo -> skrah
stage: needs patch -> commit review

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

From report at bugs.python.org  Mon Sep  2 17:45:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 15:45:31 +0000
Subject: [issue8821] Range check on unicode repr
In-Reply-To: <1274847113.25.0.171149609237.issue8821@psf.upfronthosting.co.za>
Message-ID: <1378136731.84.0.330082769788.issue8821@psf.upfronthosting.co.za>


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


----------
resolution:  -> works for me
stage:  -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Mon Sep  2 17:53:23 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 02 Sep 2013 15:53:23 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1378136048.08.0.601314131306.issue12892@psf.upfronthosting.co.za>
Message-ID: <5224B471.3080809@egenix.com>


Marc-Andre Lemburg added the comment:

You should be able to squeeze out some extra cycles by
avoiding the bit calculations using a simple range check
for ch >= 0xd800:

+# if STRINGLIB_MAX_CHAR >= 0xd800
+            if (((ch1 ^ 0xd800) &
+                 (ch1 ^ 0xd800) &
+                 (ch1 ^ 0xd800) &
+                 (ch1 ^ 0xd800) & 0xf800) == 0)
+                break;
+# endif

----------

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

From report at bugs.python.org  Mon Sep  2 18:49:20 2013
From: report at bugs.python.org (Wieland Hoffmann)
Date: Mon, 02 Sep 2013 16:49:20 +0000
Subject: [issue18905] pydoc -p 0 says the server is available at localhost:0
Message-ID: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>


New submission from Wieland Hoffmann:

In Python 3 one can use `pydoc -p 0` to start a pydoc HTTP server on an arbitrary unused port. This works (somewhat) in Python 2 as well, except that pydoc doesn't tell you which port it's listening on. Applying the attached patch makes pydoc print the correct port.

----------
components: Library (Lib)
files: pydoc-port.patch
keywords: patch
messages: 196789
nosy: Wieland.Hoffmann
priority: normal
severity: normal
status: open
title: pydoc -p 0 says the server is available at localhost:0
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31556/pydoc-port.patch

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

From report at bugs.python.org  Mon Sep  2 18:56:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 16:56:35 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1378140995.91.0.779939407113.issue12892@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I were blind. Thank you Marc-Andre. Here is corrected patch. Unfortunately it 1.4-1.5 times slower on UTF-16 encoding UCS2 strings than previous wrong patch.

----------
Added file: http://bugs.python.org/file31557/utf_16_32_surrogates_3.patch

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

From report at bugs.python.org  Mon Sep  2 18:57:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 16:57:15 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1378141035.68.0.0830213175293.issue12892@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file31555/utf_16_32_surrogates_2.patch

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

From report at bugs.python.org  Mon Sep  2 19:12:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 17:12:09 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378141929.96.0.0950220523813.issue18726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But what you will do with discrepancies between Python 2, Python 3 and simplejson?

----------

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

From report at bugs.python.org  Mon Sep  2 19:15:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Sep 2013 17:15:19 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378142119.82.0.250597419281.issue18726@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I have not seen any requests for this change.

That's probably because either people have not realized that their code might be buggy, or because they have not realized that keyword-only args might be a solution to this problem (or maybe they did but didn't bother suggesting it).

----------

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

From report at bugs.python.org  Mon Sep  2 19:17:17 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 17:17:17 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
Message-ID: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

There were numerous discussions and issues in the past about the cross-test dependencies that sometimes exist because some tests need to muck with import caches (both on the Python and C level). Some examples:

http://mail.python.org/pipermail/python-dev/2013-January/123409.html
http://mail.python.org/pipermail/python-dev/2013-August/127766.html

Issue #15651 is an example of a hack that has to stay in the code to allow tests to pass. Other things are also difficult - such as simulating situations where some optional modules don't exist (like pyexpat).

----

I suggest to add a capability to regrtest that will allow certain tests to request always being run inside a subprocess. Most of the infrastructure is already in place, since this is what regrtest uses to run with -jN today.

An alternative would be to add some test.support utility to help with this, but then test execution would not be uniform between -j1 and -jN and also some things would be difficult to track, such as -R executions (currently all -R runs of a single test have to be within a single process for the refcount tracking to work).

----------
assignee: eli.bendersky
components: Tests
messages: 196793
nosy: eli.bendersky, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Create a way to always run tests in subprocesses within regrtest
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep  2 19:21:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Sep 2013 17:21:19 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1378142479.47.0.792238802021.issue18906@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep  2 19:39:09 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 02 Sep 2013 17:39:09 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1378143549.26.0.450902911774.issue18828@psf.upfronthosting.co.za>


Madison May added the comment:

If nothing else, we should document the work around for this issue.

>>> import urllib.parse
>>> urllib.parse.uses_relative.append('redis')
>>> urllib.parse.uses_netloc.append('redis')
>>> urllib.parse.urljoin('redis://localhost:6379/0', '/1')
'redis://localhost:6379/1'

----------

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

From report at bugs.python.org  Mon Sep  2 19:39:47 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 02 Sep 2013 17:39:47 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378143587.37.0.631680907393.issue16938@psf.upfronthosting.co.za>


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


----------
nosy: +eli.bendersky, ethan.furman

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

From report at bugs.python.org  Mon Sep  2 19:49:32 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 02 Sep 2013 17:49:32 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1378144172.84.0.0880179764335.issue18828@psf.upfronthosting.co.za>


Madison May added the comment:

>How about adding a codecs.register like public API for 3.4+?

A codecs style register function seems like an excellent solution to me.

----------

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

From report at bugs.python.org  Mon Sep  2 19:51:00 2013
From: report at bugs.python.org (Dmi Baranov)
Date: Mon, 02 Sep 2013 17:51:00 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1378144260.23.0.0245098955445.issue18553@psf.upfronthosting.co.za>


Dmi Baranov added the comment:

isatty is a part of of POSIX sub-system at Windows > 5.x (AKA 2000) [1] (file handling equivalents [2]). I think, we need to remove availability note here.

[1] http://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
[2] http://msdn.microsoft.com/en-us/library/kdfaxaay.aspx

----------
nosy: +dmi.baranov

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

From report at bugs.python.org  Mon Sep  2 19:54:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 17:54:40 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1378144480.97.0.675453251339.issue18850@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Isn't this a duplicate of issue5166?

----------

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

From report at bugs.python.org  Mon Sep  2 20:03:19 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 02 Sep 2013 18:03:19 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1378140995.91.0.779939407113.issue12892@psf.upfronthosting.co.za>
Message-ID: <5224D2E5.2020204@egenix.com>


Marc-Andre Lemburg added the comment:

On 02.09.2013 18:56, Serhiy Storchaka wrote:
> 
> Oh, I were blind. Thank you Marc-Andre. Here is corrected patch. Unfortunately it 1.4-1.5 times slower on UTF-16 encoding UCS2 strings than previous wrong patch.

I think it would be faster to do this in two steps:

1. check the ranges of the input

2. do a memcpy() if there are no lone surrogates

Part 1 can be further optimized by adding a simple range
check (ch >= 0xd800).

----------

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

From report at bugs.python.org  Mon Sep  2 20:11:06 2013
From: report at bugs.python.org (Bob Ippolito)
Date: Mon, 02 Sep 2013 18:11:06 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378145466.38.0.724538672895.issue18726@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

Other than when subclassing (which is actively discouraged), I haven't seen anyone try and use positional args for these APIs. I simply don't think this is an issue in practice. If you go far enough back in simplejson history, these module-global functions were actually keyword-only.

----------

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

From report at bugs.python.org  Mon Sep  2 20:18:51 2013
From: report at bugs.python.org (John Nagle)
Date: Mon, 02 Sep 2013 18:18:51 +0000
Subject: [issue18907] urllib2.open FTP open times out at 20 secs despite
 timeout parameter
Message-ID: <1378145931.18.0.826598432393.issue18907@psf.upfronthosting.co.za>


New submission from John Nagle:

urllib2.open for an FTP url does not obey the timeout parameter.

Attached test program times out on FTP open after 21 seconds, even though the specified timeout is 60 seconds.  Timing is consistent; times have ranged from 21.03 to 21.05 seconds. Python documentation (http://docs.python.org/2/library/urllib2.html) says "The optional timeout parameter specifies a timeout in seconds for blocking operations like the connection attempt (if not specified, the global default timeout setting will be used). This actually only works for HTTP, HTTPS and FTP connections."  The documentation for Python 3 reads the same.

Open of ftp://ftp.sec.gov/edgar/daily-index failed after 21.05 seconds: <urlopen error ftp error: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond>

This was on Windows 7, but the same result is observed on Linux.  

(The FTP server at the U.S. Securities and Exchange Commission is now imposing a 20-second connection delay during busy periods.  This is causing our Python code that retrieves new SEC filings to fail.  It may be necessary to run the program at different times of the day to reproduce the problem.)

----------
components: Library (Lib)
files: edgartimeouttest.py
messages: 196800
nosy: nagle
priority: normal
severity: normal
status: open
title: urllib2.open FTP open times out at 20 secs despite timeout parameter
versions: Python 2.7
Added file: http://bugs.python.org/file31558/edgartimeouttest.py

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

From report at bugs.python.org  Mon Sep  2 20:26:41 2013
From: report at bugs.python.org (John Nagle)
Date: Mon, 02 Sep 2013 18:26:41 +0000
Subject: [issue18907] urllib2.open FTP open times out at 20 secs despite
 timeout parameter
In-Reply-To: <1378145931.18.0.826598432393.issue18907@psf.upfronthosting.co.za>
Message-ID: <1378146401.9.0.0509787330634.issue18907@psf.upfronthosting.co.za>


John Nagle added the comment:

Reproduced problem in Python 3.3 (Win32). Error message there is:

Open of ftp://ftp.sec.gov/edgar/daily-index failed after 21.08 seconds: <urlopen error ftp error: TimeoutError(10060, 'A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond', None, 10060)>

So this is broken in both Python 2.7 and Python 3.3.

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file31559/edgartimeouttest3.py

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

From report at bugs.python.org  Mon Sep  2 20:33:01 2013
From: report at bugs.python.org (Dmi Baranov)
Date: Mon, 02 Sep 2013 18:33:01 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1378146781.72.0.937434516261.issue13107@psf.upfronthosting.co.za>


Dmi Baranov added the comment:

I think "ugly look is better than silence" here. Elazar, can you touch a optparse too (with some tests - test.support.EnvironmentVarGuard context manager will be helpful here)?

----------
nosy: +dmi.baranov

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

From report at bugs.python.org  Mon Sep  2 22:31:05 2013
From: report at bugs.python.org (Zsolt Cserna)
Date: Mon, 02 Sep 2013 20:31:05 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378153865.05.0.336542655763.issue18808@psf.upfronthosting.co.za>


Changes by Zsolt Cserna <zsolt.cserna at morganstanley.com>:


----------
nosy: +csernazs

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

From report at bugs.python.org  Mon Sep  2 22:38:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 20:38:41 +0000
Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates
In-Reply-To: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za>
Message-ID: <1378154321.62.0.0750635374754.issue12892@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, it isn't faster. I tested this variant, it is 1.5x slower.

And simple range checking actually is slower.

----------

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

From report at bugs.python.org  Mon Sep  2 22:47:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 20:47:41 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1378154861.45.0.961179622286.issue13107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I think "ugly look is better than silence" here.

Agree. We have two possibilities:

1. Decrease an indentation. There is a lot of blank spaces below option's names.

2. Set some minimal width (10 or 20 characters) and let lines wrap out.

For better look we should use both methods.

----------

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

From report at bugs.python.org  Mon Sep  2 22:49:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Sep 2013 20:49:33 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378154973.63.0.579126270403.issue18726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If no one uses positional arguments then converting parameters to keyword-only will not break any code.

----------

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

From report at bugs.python.org  Mon Sep  2 22:57:11 2013
From: report at bugs.python.org (Bob Ippolito)
Date: Mon, 02 Sep 2013 20:57:11 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1378155431.19.0.638151761288.issue18726@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

My evidence is only anecdotal. I haven't actively searched for code that uses json/simplejson to try and find cases that are using positional arguments.

One way to test this assumption would be to release a version of simplejson that deprecates using positional arguments and see if anyone notices. If you feel strongly about it, submit a pull request, and I'll review it (although my availability is spotty for the next two months due to travel).

----------

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

From report at bugs.python.org  Mon Sep  2 23:01:44 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 02 Sep 2013 21:01:44 +0000
Subject: [issue18893] invalid exception handling in Lib/ctypes/macholib/dyld.py
In-Reply-To: <1377946586.23.0.205823706154.issue18893@psf.upfronthosting.co.za>
Message-ID: <1378155704.41.0.758824664051.issue18893@psf.upfronthosting.co.za>


Madison May added the comment:

Seems like a simple fix -- patch attached.

----------
keywords: +patch
nosy: +madison.may
Added file: http://bugs.python.org/file31560/issue18893.diff

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

From report at bugs.python.org  Mon Sep  2 23:19:25 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:19:25 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1378156765.31.0.49357344714.issue18850@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

As Serhiy points out, this is a duplicate of #5166

----------
superseder:  -> ElementTree and minidom don't prevent creation of not well-formed XML

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

From report at bugs.python.org  Mon Sep  2 23:19:38 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:19:38 +0000
Subject: [issue18850] xml.etree.ElementTree accepts control chars.
In-Reply-To: <1377597051.46.0.147871481267.issue18850@psf.upfronthosting.co.za>
Message-ID: <1378156778.88.0.719694777876.issue18850@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Sep  2 23:19:54 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:19:54 +0000
Subject: [issue5166] ElementTree and minidom don't prevent creation of not
 well-formed XML
In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za>
Message-ID: <1378156794.01.0.131949178889.issue5166@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Mon Sep  2 23:30:21 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 02 Sep 2013 21:30:21 +0000
Subject: [issue18907] urllib2.open FTP open times out at 20 secs despite
 timeout parameter
In-Reply-To: <1378145931.18.0.826598432393.issue18907@psf.upfronthosting.co.za>
Message-ID: <1378157421.04.0.569194222707.issue18907@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Actually, I think urllib (actually ftplib) handles the timeout correctly.

Here's the result on my Linux box (replacing the server with localhost, with a firewall rule to drop packets to ftp port):

$ ./python ~/edgartimeouttest3.py 
Open of ftp://localhost/daily-index failed after 60.09 seconds: <urlopen error ftp error: timeout('timed out',)>

And indeed, here's what strace shows:

$ strace -ttT ./python ~/edgartimeouttest3.py 
23:15:46.953116 connect(3, {sa_family=AF_INET, sin_port=htons(21), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000066>
23:15:46.953257 poll([{fd=3, events=POLLOUT}], 1, 60000) = 0 (Timeout) <60.011497>

See, we - correctly - pass 60s to poll()/select().

Now, I think I know what's going on in your case.
It's likely that your TCP/IP stack settings have shorter timeouts than mine, so the kernel reports a timeout on the socket *before the timeout expires*:

If I reduce the SYN retries limit (on Linux):
# sysctl net.ipv4.tcp_syn_retries=1
net.ipv4.tcp_syn_retries = 1

I now get:
$ ./python ~/edgartimeouttest3.py 
Open of ftp://localhost/daily-index failed after 3.03 seconds: <urlopen error ftp error: TimeoutError(110, 'Connection timed out')>

3s timeout, and yet, we still pass 60 seconds to poll():

23:19:43.756823 connect(3, {sa_family=AF_INET, sin_port=htons(21), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000099>
23:19:43.757034 poll([{fd=3, events=POLLOUT}], 1, 60000) = 1 ([{fd=3, revents=POLLOUT|POLLERR|POLLHUP}]) <3.003306>

In short, the kernel reports a timeout on the socket because it reached the maximum number of retries for SYN packets.

And actually, you can check that the timeouts are correctly processed by passing a smaller value: if it's smaller than the TCP/IP retries limit, you'll get exactly the expected timeout.

So I think it's not a Python bug, but rather an issue with your TCP/IP stack settings.

On Linux, can you try to increase the following sysctls:
#?sysctl net.ipv4.tcp_syn_retries=7
# net.ipv4.tcp_retries1=7

And see if this solves your problem?

(BTW, are you "the" John Nagle?)

----------
nosy: +neologix

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

From report at bugs.python.org  Mon Sep  2 23:43:01 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:43:01 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1378158181.84.0.493033868957.issue18906@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

A question that comes up is how should a module signal to regrtest that it needs to be run in a subprocess?

The most natural approach is to have a special attribute set in the module's global dict (for example: __REGRTEST_SUBPROCESS__ = True); however, there's a slight problem with this approach - regrtest has to import the module to see this attribute, and the module may do some work in its top-level code (commonly, imports) that already needs to be done within a subprocess.

One solution is to use a different approach, such as a separate file alongside the test file (i.e. test_foo.regrtest_subprocess alongside test_foo.py). This is quite ugly but "safe".

A different solution is to require modules that want to be executed in a subprocess to not do any top-level work; modules can already define a custom test_main function that regrtest discovers - we can require for this feature to work that modules do all their work through this function, rather than in the global scope.

----------
stage: needs patch -> 
type: enhancement -> 

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

From report at bugs.python.org  Mon Sep  2 23:48:27 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 Sep 2013 21:48:27 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378158181.84.0.493033868957.issue18906@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fMZ9n518zhOLFLY6ce29+hiQ57wuPqU71cN0MoJ+4qkw@mail.gmail.com>


Nick Coghlan added the comment:

An easier hack is likely just a new "always run in subprocess" container
with submodule names in regrtest.py. It's not elegant, but it will work.

----------

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

From report at bugs.python.org  Mon Sep  2 23:50:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 02 Sep 2013 21:50:36 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <CADiSq7fMZ9n518zhOLFLY6ce29+hiQ57wuPqU71cN0MoJ+4qkw@mail.gmail.com>
Message-ID: <CADiSq7fC1rNsiE1EdJ_nxK5iMR425MCWAoO78QdVyGsQArqmSg@mail.gmail.com>


Nick Coghlan added the comment:

Although the "well, don't do that then" alternative also sounds reasonable,
and better localises the information about how the test should run.

----------

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

From report at bugs.python.org  Mon Sep  2 23:52:53 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:52:53 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <CADiSq7fMZ9n518zhOLFLY6ce29+hiQ57wuPqU71cN0MoJ+4qkw@mail.gmail.com>
Message-ID: <CAF-Rda9Xxwx2M7p0w_vm7N-u-B4pMrd7ZzN4C1kRG=JHGLRQqw@mail.gmail.com>


Eli Bendersky added the comment:

> An easier hack is likely just a new "always run in subprocess" container
> with submodule names in regrtest.py. It's not elegant, but it will work.
>

True, that's also an option. I had it in mind in the beginning, but it's
too hacky for my tastes :-) Not doing state-changing stuff in the global
scope is a good practice anyway, so the restriction should be too horrible.

Do we have some sort of conventions of outside-discoverable module
attributes (like the __REGRTEST_SUBPROCESS__ proposed above)? I.e. in terms
of naming, type, expected values?

----------

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

From report at bugs.python.org  Mon Sep  2 23:54:31 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:54:31 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1378158871.11.0.451186875459.issue18906@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep  2 23:54:46 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 21:54:46 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1378158886.96.0.213132040174.issue18906@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

> An easier hack is likely just a new "always run in subprocess" container
> with submodule names in regrtest.py. It's not elegant, but it will work.
>

True, that's also an option. I had it in mind in the beginning, but it's
too hacky for my tastes :-) Not doing state-changing stuff in the global
scope is a good practice anyway, so the restriction should not be too horrible.

Do we have some sort of conventions of outside-discoverable module
attributes (like the __REGRTEST_SUBPROCESS__ proposed above)? I.e. in terms
of naming, type, expected values?

----------

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

From report at bugs.python.org  Mon Sep  2 23:57:12 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 02 Sep 2013 21:57:12 +0000
Subject: [issue17930] Search not needed in combinations_with_replacement
In-Reply-To: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za>
Message-ID: <1378159032.0.0.738097917435.issue17930@psf.upfronthosting.co.za>


Tim Peters added the comment:

I'm closing this.  While it makes a big difference for a cwr coded in Python, it turn out to be minor in C.  The extra complications (more state to remember and update across next() invocations) isn't worth the minor speedup in C.

----------
resolution:  -> rejected
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Sep  3 00:40:00 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 22:40:00 +0000
Subject: [issue18908] Enum docs: sections leak out
Message-ID: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

Inner sections "leak" out from enum to the general datatypes index:
http://docs.python.org/3.4/library/datatypes.html

(sections 8.14 - 8.17)

----------
assignee: docs at python
components: Documentation
messages: 196816
nosy: docs at python, elazar
priority: normal
severity: normal
status: open
title: Enum docs: sections leak out

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

From report at bugs.python.org  Tue Sep  3 00:40:42 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 22:40:42 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378161642.89.0.516548991134.issue18908@psf.upfronthosting.co.za>


Elazar Gershuni added the comment:

here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file31561/enumcontain.patch

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

From report at bugs.python.org  Tue Sep  3 00:47:26 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 22:47:26 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378162046.89.0.987087409947.issue18908@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky, ethan.furman

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

From report at bugs.python.org  Tue Sep  3 00:47:41 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Sep 2013 22:47:41 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378162061.11.0.176148996733.issue18908@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.4

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

From report at bugs.python.org  Tue Sep  3 00:53:42 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 22:53:42 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378162422.6.0.770384453554.issue18908@psf.upfronthosting.co.za>


Changes by Elazar Gershuni <elazarg at gmail.com>:


Added file: http://bugs.python.org/file31562/enumindent.patch

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

From report at bugs.python.org  Tue Sep  3 01:47:48 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 23:47:48 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378165668.3.0.848720298603.issue18908@psf.upfronthosting.co.za>


Changes by Elazar Gershuni <elazarg at gmail.com>:


Added file: http://bugs.python.org/file31563/enumplusminor.patch

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

From report at bugs.python.org  Tue Sep  3 01:53:10 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 23:53:10 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378165990.96.0.118710686226.issue18908@psf.upfronthosting.co.za>


Changes by Elazar Gershuni <elazarg at gmail.com>:


Removed file: http://bugs.python.org/file31563/enumplusminor.patch

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

From report at bugs.python.org  Tue Sep  3 01:53:44 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Mon, 02 Sep 2013 23:53:44 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <1378166024.06.0.222911477571.issue18908@psf.upfronthosting.co.za>


Changes by Elazar Gershuni <elazarg at gmail.com>:


Added file: http://bugs.python.org/file31564/enumplusminor.patch

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

From report at bugs.python.org  Tue Sep  3 03:01:44 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Tue, 03 Sep 2013 01:01:44 +0000
Subject: [issue17862] itertools.chunks(iterable, size, fill=None)
In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za>
Message-ID: <1378170104.41.0.724576141353.issue17862@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

I'm just gonna leave my implementation of chunk function (not sure about the name yet) here, it's basically what itertools.chunks from the previous patch is but it works for arbitrary iterables + few tests and documentation. The last chunk is currently truncated if there are not enough elements to fill it completely.

----------
nosy: +jstasiak
Added file: http://bugs.python.org/file31565/itertools.chunk.patch

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

From report at bugs.python.org  Tue Sep  3 03:25:03 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 03 Sep 2013 01:25:03 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
Message-ID: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>


New submission from Christoph Gohlke:

Using 64 bit CPython 2.6.6, 2.7.5, 3.2.5 or 3.3.2, numpy 1.7.1 and matplotlib 1.3.0 on Windows 8 64 bit, the following script segfaults most of the times: 

```
# allocate ~4GB fragmented data
import numpy
a = [numpy.zeros(2**i, 'uint8') for i in range(1, 31)]
b = [numpy.zeros(131072, 'float64') for i in range(2048)]

# plot using TkAgg
import matplotlib
matplotlib.use('TkAgg')
from matplotlib import pyplot
pyplot.plot()
pyplot.show()
```

```
Fatal Python error: Segmentation fault

Current thread 0x00036c5c:
  File "X:\Python33\lib\site-packages\matplotlib\backends\tkagg.py", line 17 in blit
  File "X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 349 in draw
  File "X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 276 in resize
  File "X:\Python33\lib\tkinter\__init__.py", line 1475 in __call__
  File "X:\Python33\lib\tkinter\__init__.py", line 965 in update
  File "X:\Python33\lib\site-packages\matplotlib\backends\backend_tkagg.py", line 574 in show
  File "X:\Python33\lib\site-packages\matplotlib\backend_bases.py", line 87 in __call__
  File "X:\Python33\lib\site-packages\matplotlib\pyplot.py", line 145 in show
  File "tk_crash_win-amd64.py", line 14 in <module>
```

The pointer returned by Python's _tkinter.tkapp.interpaddr() is often wrong because the 64 bit pointer is cast to 32 bit long and returned as PyInt. Instead, the pointer should be cast to Py_ssize_t and returned as PyLong on win-amd64.

The following patches for win-amd64-py2.7.5 and win-amd64-py3.3.2 fix the issue:

```
--- a/Modules/_tkinter.c        Sun Sep 01 19:06:35 2013 -0400
+++ b/Modules/_tkinter.c        Mon Sep 02 17:44:53 2013 -0700
@@ -2814,7 +2814,7 @@
     if (!PyArg_ParseTuple(args, ":interpaddr"))
         return NULL;

-    return PyInt_FromLong((long)Tkapp_Interp(self));
+    return PyInt_FromSsize_t((Py_ssize_t)Tkapp_Interp(self));
 }
```

```
--- a/Modules/_tkinter.c        Sun Sep 01 19:03:41 2013 -0400
+++ b/Modules/_tkinter.c        Mon Sep 02 17:44:02 2013 -0700
@@ -2688,7 +2688,7 @@
     if (!PyArg_ParseTuple(args, ":interpaddr"))
         return NULL;

-    return PyLong_FromLong((long)Tkapp_Interp(self));
+    return PyLong_FromSsize_t((Py_ssize_t)Tkapp_Interp(self));
 }
```

Updated _tkinter.pyd files are available at <http://www.lfd.uci.edu/~cgohlke/pythonlibs/#_tkinter>.

----------
messages: 196819
nosy: cgohlke
priority: normal
severity: normal
status: open
title: Segfaults on win-amd64 due to corrupt pointer to Tkapp_Interp
type: crash
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep  3 03:28:13 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 03 Sep 2013 01:28:13 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378171693.34.0.461003235021.issue18909@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


Added file: http://bugs.python.org/file31566/tkapp_interpaddr_crash_win-amd64.py

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

From report at bugs.python.org  Tue Sep  3 03:28:29 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 03 Sep 2013 01:28:29 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378171709.75.0.773856421248.issue18909@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31567/fix_tkapp_interpaddr-win-amd64-py2.7.diff

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

From report at bugs.python.org  Tue Sep  3 03:28:49 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 03 Sep 2013 01:28:49 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378171729.11.0.941787735876.issue18909@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


Added file: http://bugs.python.org/file31568/fix_tkapp_interpaddr-win-amd64-py3.3.diff

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

From report at bugs.python.org  Tue Sep  3 03:56:46 2013
From: report at bugs.python.org (Phil Webster)
Date: Tue, 03 Sep 2013 01:56:46 +0000
Subject: [issue18910] IDLE: Unit test for textView.py
Message-ID: <1378173406.38.0.908315708817.issue18910@psf.upfronthosting.co.za>


New submission from Phil Webster:

Started writing the tests for textView.py.

----------
components: IDLE
files: test_textview.patch
keywords: patch
messages: 196820
nosy: JayKrish, Todd.Rovito, philwebster, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Unit test for textView.py
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31569/test_textview.patch

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

From report at bugs.python.org  Tue Sep  3 05:30:23 2013
From: report at bugs.python.org (Mikhail Traskin)
Date: Tue, 03 Sep 2013 03:30:23 +0000
Subject: [issue18219] csv.DictWriter is slow when writing files with large
 number of columns
In-Reply-To: <1371273159.09.0.766674685212.issue18219@psf.upfronthosting.co.za>
Message-ID: <1378179023.14.0.519254687534.issue18219@psf.upfronthosting.co.za>


Mikhail Traskin added the comment:

Peter, thank you for letting me know that views work with list, I was not aware of this. This is indeed the best solution and it also keeps the DictWriter interface unchanged.

Terry, attached patch contains the DictWriter change and a test case in test_csv.py.

----------
Added file: http://bugs.python.org/file31570/csvdictwriter.v4.patch

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

From report at bugs.python.org  Tue Sep  3 05:53:40 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 03 Sep 2013 03:53:40 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1378180420.44.0.544394139286.issue18553@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Agree

----------
nosy: +asvetlov

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

From report at bugs.python.org  Tue Sep  3 05:59:24 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Tue, 03 Sep 2013 03:59:24 +0000
Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not
 match IDNA prefix
In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za>
Message-ID: <1378180764.48.0.487437798903.issue17997@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

So, is this a security issue?  I've been wondering if I should apply the attached patch to the backports-ssl_match_hostname module on pypi.  I was hoping there'd be some information here as to whether this will be going into the stdlib in the future.

Thus far, ssl_match_hostname has just been a backport of the match_hostname function but if this is a security problem, I could press for us to diverge from the python3 stdlib.  It would be easier to make the case if this is seen as a critical problem that will need to be fixed even if the current patch might not be the eventual fix.

----------
nosy: +a.badger

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

From report at bugs.python.org  Tue Sep  3 07:36:59 2013
From: report at bugs.python.org (Brian Vanderburg)
Date: Tue, 03 Sep 2013 05:36:59 +0000
Subject: [issue18911] minidom does not encode correctly when calling
 Document.writexml
Message-ID: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>


New submission from Brian Vanderburg:

When I have unicode data to save, it seems that it does not save correctly, giving an encode error. I know this exists on 2.7 and from checking the code in xml/dom/minidom.py it looks like it does in 3.2 as well.

The method call that seem to be problematic is doc.writexml(open(filename, "wb"), "", "  ", "utf-8")

Currently I found this to work: doc.writexml(codecs.open(filename, "w", "utf-8"), "", "  ", "utf-8")

It seems like this should be handled by the writexml method since it already has the specified encoding.

----------
components: XML
messages: 196824
nosy: brianvanderburg2
priority: normal
severity: normal
status: open
title: minidom does not encode correctly when calling Document.writexml
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  3 09:37:53 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Tue, 03 Sep 2013 07:37:53 +0000
Subject: [issue18891] Master patch for content manager addtion to email
 package.
In-Reply-To: <1377918603.72.0.362957249668.issue18891@psf.upfronthosting.co.za>
Message-ID: <1378193873.32.0.512757291377.issue18891@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

I'm thinking this may be overengineering, but I may as well post it and find out for sure. :-)  Is it worth encapsulating MIME types?  They're "really" pairs as far as mail handling applications are concerned, but they have a string representation.  So

MacPorts 16:29$ python3.3
Python 3.3.2 (default, May 21 2013, 11:48:51) 
>>> from collections import namedtuple
>>> class MIMEType(namedtuple('MIMETYPE', 'type subtype')):
...  def __str__(self):
...   return "{0}/{1}".format(self.type, self.subtype)
... 
>>> mt = MIMEType('text', 'plain')
>>> str(mt)
'text/plain'
>>> t, s = mt
>>> print('type =', t, 'subtype =', s)
type = text subtype = plain
>>> 

Obviously there needs to be a constructor that handles the 'type/sub' represention.

----------
nosy: +sjt

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

From report at bugs.python.org  Tue Sep  3 10:08:26 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Tue, 03 Sep 2013 08:08:26 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
Message-ID: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>


New submission from Jeroen Van Goey:

The sample code in the itertools.count documentation should be indented by 4 spaces.

For 2.7.4: lines 3429 till 3432 in http://hg.python.org/releasing/2.7.4/file/026ee0057e2d/Modules/itertoolsmodule.c#l3429

For 3.4.0a1: lines 3981 till 3984 in http://hg.python.org/releasing/py3.4.0a1/file/edc668a667ad/Modules/itertoolsmodule.c#l3981

Also, the example code uses the arguments 'firstval' and 'step' whereas the documentation of the function itself uses the arguments 'start' and 'step'. Maybe better be consistent and use as first argument 'start' in both cases?

----------
assignee: docs at python
components: Documentation
hgrepos: 207
messages: 196826
nosy: docs at python, jeroen-vangoey
priority: normal
severity: normal
status: open
title: Intendation issue in example code in itertools.count documentation
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Sep  3 10:08:49 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Tue, 03 Sep 2013 08:08:49 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <1378195729.06.0.628336464664.issue18912@psf.upfronthosting.co.za>


Changes by Jeroen Van Goey <jeroen.vangoey at gmail.com>:


----------
hgrepos:  -207

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

From report at bugs.python.org  Tue Sep  3 10:31:54 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Tue, 03 Sep 2013 08:31:54 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <1378197114.27.0.934653540395.issue18912@psf.upfronthosting.co.za>


Jeroen Van Goey added the comment:

Patch for Python 2.7.4 attached

----------
keywords: +patch
Added file: http://bugs.python.org/file31571/2.7itertoolsmodule.c.patch

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

From report at bugs.python.org  Tue Sep  3 10:32:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Sep 2013 08:32:12 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377995771.98.0.681989822972.issue18835@psf.upfronthosting.co.za>
Message-ID: <2036852373.33037416.1378197125681.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> We don't have to align EVERY data structure.  But I do have immediate
> beneficial use cases for set tables and for data blocks in deque
> objects.

Can you explain what the use cases are, and post some benchmarking code?

Also, what would be the strategy? Would you align every set/deque, or only
the bigger ones?

----------

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

From report at bugs.python.org  Tue Sep  3 10:32:30 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Tue, 03 Sep 2013 08:32:30 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <1378197150.21.0.398833796019.issue18912@psf.upfronthosting.co.za>


Jeroen Van Goey added the comment:

Patch for Python 3.4.0a1 attached

----------
Added file: http://bugs.python.org/file31572/3.4itertoolsmodule.c.patch

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

From report at bugs.python.org  Tue Sep  3 10:52:50 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Tue, 03 Sep 2013 08:52:50 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378198370.02.0.0343227394282.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31518/fix_for_27.patch

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

From report at bugs.python.org  Tue Sep  3 10:55:25 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Tue, 03 Sep 2013 08:55:25 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378198525.16.0.908428658553.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31573/temp_dir_exists_retry_27.patch

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

From report at bugs.python.org  Tue Sep  3 11:21:13 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 03 Sep 2013 09:21:13 +0000
Subject: [issue18902] Make ET event handling more modular to allow custom
 targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1378200073.67.0.663559356339.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> This would make it possible to layer XMLPullParser on top of the stock XMLParser coupled with a special target that collects "events" from the callback calls.

Given that we have an XMLPullParser now, I think we should not clutter the API with more classes that do not add anything more than making other classes redundant. So, -1 on adding a special target that collects events. Anyone who wants to use that feature can just use the XMLPullParser.

In the Python implementation of that parser, custom targets can already be allowed right now. Only the C implementation prevents it currently (AFAICT) as it has its own built-in TreeBuilder target.

Therefore, +1 for the general cleanup to properly allow arbitrary targets as backend.

Also, +1 for allowing start-ns and end-ns event callbacks on parser targets, although that's a different feature entirely.

----------
nosy: +scoder

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

From report at bugs.python.org  Tue Sep  3 11:22:31 2013
From: report at bugs.python.org (Jan-Wijbrand Kolman)
Date: Tue, 03 Sep 2013 09:22:31 +0000
Subject: [issue18851] subprocess's Popen closes stdout/stderr filedescriptors
 used in another thread when Popen errors
In-Reply-To: <1377605215.82.0.119537279776.issue18851@psf.upfronthosting.co.za>
Message-ID: <1378200151.97.0.265618534676.issue18851@psf.upfronthosting.co.za>


Jan-Wijbrand Kolman added the comment:

Thanks you for the swift followup!

----------

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

From report at bugs.python.org  Tue Sep  3 11:23:09 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 03 Sep 2013 09:23:09 +0000
Subject: [issue18902] Make ElementTree event handling more modular to allow
 custom targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1378200189.09.0.773322829905.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

(fixing subject to properly hit bug filters)

----------
title: Make ET event handling more modular to allow custom targets for the non-blocking parser -> Make ElementTree event handling more modular to allow custom targets for the non-blocking parser

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

From report at bugs.python.org  Tue Sep  3 11:27:23 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Tue, 03 Sep 2013 09:27:23 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378200443.96.0.813433573331.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31574/temp_dir_exists_retry_33_34.patch

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

From report at bugs.python.org  Tue Sep  3 11:32:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 09:32:01 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1378200721.76.0.432578428028.issue18906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The most natural approach is to have a special attribute set in the module's global dict (for example: __REGRTEST_SUBPROCESS__ = True); however, there's a slight problem with this approach - regrtest has to import the module to see this attribute, and the module may do some work in its top-level code (commonly, imports) that already needs to be done within a subprocess.

The main regrtest process can run auxilary child process which imports all test modules and says main process which of them have __REGRTEST_SUBPROCESS__=True.

It will be even better if the main process runs child process for testing all tests so when any test crashes it is possible to report this and respawn child process to continue testing other tests.

----------

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

From report at bugs.python.org  Tue Sep  3 11:40:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Sep 2013 09:40:10 +0000
Subject: [issue18835] Add aligned memory variants to the suite of PyMem
 functions/macros
In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za>
Message-ID: <1378201210.34.0.596240804666.issue18835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Linux provides the following functions:

int posix_memalign(void **memptr, size_t alignment, size_t size);
void *valloc(size_t size);  # obsolete
void *memalign(size_t boundary, size_t size);  # obsolete

Windows provides the following functions:

void* _aligned_malloc(size_t size,  size_t alignment);
void _aligned_free(void *memblock);

_aligned_malloc() has a warning: "Using free is illegal."

Do all platform provide at least a function to allocate aligned memory? Windows, Mac OS X, FreeBSD, old operating systems, etc.? If no, how should we handle these operating systems? Refuse to start Python? Disable some optimizations? How should we check in the source code (ex: setobject.c) than aligned allocations are not supported? An #ifdef?

***

Because of the Windows API, wee need at least two functions:

void* PyMem_MallocAligned(size_t size, size_t alignment);
void PyMem_FreeAligned(void *ptr);

The GIL must be held when callling these functions.


Windows provides also a "realloc" function:

void* _aligned_realloc(void *memblock, size_t size,  size_t alignment);

If the OS does not provide a realloc function, we can reimplement it (malloc, memcpy, free).

void* PyMem_ReallocAligned(void *ptr, size_t size, size_t alignment);

***

For the PEP 445: the new API is different than the PyMemAllocator structure because malloc and realloc functions have an extra "alignment" parameter. We can drop the parameter if the allocator has always the size alignment, but each object may require a different aligment?

----------

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

From report at bugs.python.org  Tue Sep  3 12:02:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 10:02:55 +0000
Subject: [issue17862] itertools.chunks(iterable, size, fill=None)
In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za>
Message-ID: <1378202575.19.0.461559678753.issue17862@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We should distinguish between at least two different functions. One generates slices of input sequence (it is especially useful for strings and bytes objects), and other groups items from arbitrary iterator into tuples. They have different applications.

----------

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

From report at bugs.python.org  Tue Sep  3 12:24:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 10:24:14 +0000
Subject: [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1378203854.9.0.509881025674.issue18911@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On Python 3 you should not only open file in text mode with specified encoding, but also specify the "xmlcharrefreplace" error handler.

    doc.writexml(open(filename, "w", encoding="utf-8", errors="xmlcharrefreplace"), "", "  ", "utf-8")

I can suggest only one solution -- explicitly document this behavior.

Perhaps we also should add a special module level function for writing DOM tree to binary file. Low-level writexml() should not be used directly.

----------
nosy: +eli.bendersky, scoder, serhiy.storchaka
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Sep  3 12:51:10 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 03 Sep 2013 10:51:10 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <1378205470.5.0.876010009681.issue18912@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From report at bugs.python.org  Tue Sep  3 13:46:41 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Tue, 03 Sep 2013 11:46:41 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
Message-ID: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>


New submission from Mat?j Stuchl?k:

Doing 'valgrind --suppressions=Misc/valgrind-python.supp ./python Lib/tests/test_ssl.py' I'm getting:

==322== LEAK SUMMARY:
==322==    definitely lost: 32 bytes in 1 blocks
==322==    indirectly lost: 392 bytes in 16 blocks
==322==      possibly lost: 1,617,191 bytes in 1,052 blocks
==322==    still reachable: 4,068,239 bytes in 3,201 blocks
==322==         suppressed: 0 bytes in 0 blocks


I managed to reduce that to a shorter reproducer:

"""
import os
import ssl

NULLBYTECERT = os.path.join(os.path.dirname(__file__) or os.curdir, "nullbytecert.pem")
p = ssl._ssl._test_decode_cert(NULLBYTECERT)
"""

where NULLBYTECERT is the cert introduced in issue18709.

Python 2.7 does not leak like this, and the PySSL_test_decode_certificate function looks the same there as in Python 2.6, so I assume it's something else that does the actual leaking.

----------
components: Extension Modules
messages: 196837
nosy: sYnfo
priority: normal
severity: normal
status: open
title: ssl._ssl._test_decode_cert seems to leak memory with certain certificates in Python 2.6
type: resource usage
versions: Python 2.6

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

From report at bugs.python.org  Tue Sep  3 15:32:04 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 03 Sep 2013 13:32:04 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378215124.09.0.174952667897.issue18849@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The fix looks good to me, in general. Could you create a test that goes along?

My only (minor) doubt is whether this should be generalized, in two dimensions:

1. PermissionError is mapped from both EACCES and EPERM. So to make the 2.7 patch equivalent with 3.x, EPERM should also be checked. That said, Windows documents it doesn't really use EPERM (http://msdn.microsoft.com/en-us/library/5814770t.aspx).
2. Should this be restricted to Windows? Could there be other platforms that exhibit the same behavior? On the other hand, say on Linux, EACCES should not happen in a temp dir and so it's good to re-raise it. 

For (2) I don't think doing anything is necessary at this point - the added test may help because it can fail for some strange platform at some point and then the solution should be obvious. As for (1), adding EPERM into the condition probably can't hurt and it will make Python 2.7 behave more consistently with 3.x in case of some undocumented Windows behavior.

----------
nosy: +eli.bendersky
stage: needs patch -> patch review

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

From report at bugs.python.org  Tue Sep  3 15:34:02 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 03 Sep 2013 13:34:02 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378215242.02.0.131373790918.issue18913@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

To ensure it's a real memory leak: do the figures increase when the code is called in a loop?
I would not consider a single-time malloc (stored in some static variable) to be a leak.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Tue Sep  3 15:35:51 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 03 Sep 2013 13:35:51 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <1378215351.38.0.199554593774.issue18912@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

LGTM, thanks

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Tue Sep  3 15:39:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Sep 2013 13:39:27 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <3cTq5V1P41z7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 8e174ee0575a by Eli Bendersky in branch '3.3':
Issue #18912: Fix indentation in docstring
http://hg.python.org/cpython/rev/8e174ee0575a

New changeset 31ef590a0d2f by Eli Bendersky in branch 'default':
Issue #18912: Fix indentation in docstring
http://hg.python.org/cpython/rev/31ef590a0d2f

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

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

From report at bugs.python.org  Tue Sep  3 15:41:48 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Tue, 03 Sep 2013 13:41:48 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378215708.02.0.443344690263.issue18913@psf.upfronthosting.co.za>


Mat?j Stuchl?k added the comment:

That's a good idea:

NULLBYTECERT = os.path.join(os.path.dirname(__file__) or os.curdir, "nullbytecert.pem")
for i in xrange(100):
    p = ssl._ssl._test_decode_cert(NULLBYTECERT)

gives

==1647== LEAK SUMMARY:
==1647==    definitely lost: 3,200 bytes in 100 blocks
==1647==    indirectly lost: 39,200 bytes in 1,600 blocks
==1647==      possibly lost: 591,285 bytes in 545 blocks
==1647==    still reachable: 1,955,652 bytes in 3,136 blocks
==1647==         suppressed: 0 bytes in 0 blocks

so yes, they do increase.

----------

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

From report at bugs.python.org  Tue Sep  3 15:42:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Sep 2013 13:42:30 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <3cTq911DQ2z7Lkh@mail.python.org>


Roundup Robot added the comment:

New changeset a559cda6a498 by Eli Bendersky in branch '2.7':
Close #18912: Fix indentation in docstring
http://hg.python.org/cpython/rev/a559cda6a498

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Sep  3 15:47:17 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 03 Sep 2013 13:47:17 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378200721.76.0.432578428028.issue18906@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8Sd4EXTVVyHydH9VoRDf_ugfdHK3FwctVz7Jr36rm=sQ@mail.gmail.com>


Eli Bendersky added the comment:

On Tue, Sep 3, 2013 at 2:32 AM, Serhiy Storchaka <report at bugs.python.org>wrote:

>
> Serhiy Storchaka added the comment:
>
> > The most natural approach is to have a special attribute set in the
> module's global dict (for example: __REGRTEST_SUBPROCESS__ = True);
> however, there's a slight problem with this approach - regrtest has to
> import the module to see this attribute, and the module may do some work in
> its top-level code (commonly, imports) that already needs to be done within
> a subprocess.
>
> The main regrtest process can run auxilary child process which imports all
> test modules and says main process which of them have
> __REGRTEST_SUBPROCESS__=True.
>
> It will be even better if the main process runs child process for testing
> all tests so when any test crashes it is possible to report this and
> respawn child process to continue testing other tests.
>

Well, if we go *that* way, my initial proposal would be to just always run
every test in a subprocess. Kind of what happens today with -jN, just also
for -j1. Since most people, and I assume bots, run -jN anyway, they already
see each test executed in a subprocess. Some folks didn't feel good about
it because the stress testing "all in one process" provides is apparently
desired.

Your proposal complicates the flow significantly, IMHO. I'd just run each
test in its own subprocess and be done with it.

----------

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

From report at bugs.python.org  Tue Sep  3 15:59:27 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Sep 2013 13:59:27 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378216767.77.0.871525650263.issue18913@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Could you possibly check this in Python 2.7, 3.2 and 3.3?. Python 2.6 is open ONLY for security fixes, if any.

----------
nosy: +jcea

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

From report at bugs.python.org  Tue Sep  3 16:03:14 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Tue, 03 Sep 2013 14:03:14 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378216994.58.0.629583994686.issue18913@psf.upfronthosting.co.za>


Mat?j Stuchl?k added the comment:

Ah, that is unfortunate. I did check it for 2.7 and 3.4, neither of those leak, I can check it for the rest tomorrow, but I imagine it'll be the same story.

----------

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

From report at bugs.python.org  Tue Sep  3 16:04:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Sep 2013 14:04:30 +0000
Subject: [issue18891] Master patch for content manager addtion to email
 package.
In-Reply-To: <1377918603.72.0.362957249668.issue18891@psf.upfronthosting.co.za>
Message-ID: <1378217070.93.0.157793457052.issue18891@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's an interesting thought.  It bothered me to be handling them as pure strings when writing the code.  It just felt wrong somehow :)

----------

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

From report at bugs.python.org  Tue Sep  3 16:47:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 14:47:34 +0000
Subject: [issue5202] wave.py cannot write wave files into a shell pipeline
In-Reply-To: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
Message-ID: <1378219654.4.0.0187322327808.issue5202@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is corrected patch (it uses relative seek()) with a lot of tests.

----------

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

From report at bugs.python.org  Tue Sep  3 17:10:48 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 03 Sep 2013 15:10:48 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378221048.96.0.8308683552.issue18913@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

http://hg.python.org/cpython/rev/c4bbda2d4c49 looks relevant.

----------

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

From report at bugs.python.org  Tue Sep  3 17:48:32 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Tue, 03 Sep 2013 15:48:32 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378223312.17.0.360571444133.issue18913@psf.upfronthosting.co.za>


Mat?j Stuchl?k added the comment:

Potentially interesting part of the valgrind output:

==21685== 42,400 (3,200 direct, 39,200 indirect) bytes in 100 blocks are definitely lost in loss record 909 of 914
==21685==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==21685==    by 0x331B06315F: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1e)
==21685==    by 0x331B0CD4EE: sk_new (in /usr/lib64/libcrypto.so.1.0.1e)
==21685==    by 0x331B0F2E42: ??? (in /usr/lib64/libcrypto.so.1.0.1e)
==21685==    by 0x331B0F2F7B: ??? (in /usr/lib64/libcrypto.so.1.0.1e)
==21685==    by 0x331B0F2884: ASN1_item_ex_d2i (in /usr/lib64/libcrypto.so.1.0.1e)
==21685==    by 0x331B0F3103: ASN1_item_d2i (in /usr/lib64/libcrypto.so.1.0.1e)
==21685==    by 0xB431892: _decode_certificate (_ssl.c:710)
==21685==    by 0xB431E57: PySSL_test_decode_certificate (_ssl.c:1025)
==21685==    by 0x49D187: PyEval_EvalFrameEx (ceval.c:3750)
==21685==    by 0x497A01: PyEval_EvalCodeEx (ceval.c:3000)
==21685==    by 0x497B41: PyEval_EvalCode (ceval.c:541)

_ssl.c:710 snippet:

(...)
 p = ext->value->data;
  if (method->it)
>     names = (GENERAL_NAMES*) (ASN1_item_d2i(NULL, &p, ext->value->length, ASN1_ITEM_ptr(method->it)));
  else
      names = (GENERAL_NAMES*) (method->d2i(NULL, &p, ext->value->length));
(...)

----------

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

From report at bugs.python.org  Tue Sep  3 18:07:27 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 03 Sep 2013 16:07:27 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378224447.37.0.423282003054.issue18913@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Ah, http://hg.python.org/cpython/rev/80d491aaeed2/ as well then.

----------

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

From report at bugs.python.org  Tue Sep  3 18:20:17 2013
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Tue, 03 Sep 2013 16:20:17 +0000
Subject: [issue18913] ssl._ssl._test_decode_cert seems to leak memory with
 certain certificates in Python 2.6
In-Reply-To: <1378208801.81.0.941164435803.issue18913@psf.upfronthosting.co.za>
Message-ID: <1378225217.78.0.117420327529.issue18913@psf.upfronthosting.co.za>


Mat?j Stuchl?k added the comment:

That seems to be it, no more leaking! Good job!

----------

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

From report at bugs.python.org  Tue Sep  3 18:35:01 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Sep 2013 16:35:01 +0000
Subject: [issue16662] load_tests not invoked in package/__init__.py
In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za>
Message-ID: <1378226101.76.0.102614036697.issue16662@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I took a stab at the doc changes, attached here and including Barry's patch.

----------
components: +Library (Lib)
type:  -> enhancement
versions: +Python 3.4
Added file: http://bugs.python.org/file31575/16662_with_doc.diff

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

From report at bugs.python.org  Tue Sep  3 18:56:45 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 03 Sep 2013 16:56:45 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1378227405.14.0.0404100039834.issue18906@psf.upfronthosting.co.za>


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


----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Sep  3 19:00:12 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 03 Sep 2013 17:00:12 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1378227612.74.0.439934154546.issue18709@psf.upfronthosting.co.za>


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


----------
title: SSL module fails to handle NULL bytes inside	subjectAltNames general names (CVE-2013-4238) -> SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

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

From report at bugs.python.org  Tue Sep  3 19:30:20 2013
From: report at bugs.python.org (Brian Mingus)
Date: Tue, 03 Sep 2013 17:30:20 +0000
Subject: [issue18914] Python docs link to terrible outsi
Message-ID: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>


New submission from Brian Mingus:

The python documentation links to an outside website for info and examples on http basic auth. This documentation is terrible and confusing. The link should be removed, and user's should be advised to use the Requests library.


# this example is from http://www.voidspace.org.uk/python/articles/authentication.shtml
# which is linked to by the official python docs http://docs.python.org/2/howto/urllib2.html

import urllib2
 
theurl = 'http://www.someserver.com/toplevelurl/somepage.htm'
username = 'johnny'
password = 'XXXXXX'
# a great password
 
passman = urllib2.HTTPPasswordMgrWithDefaultRealm()
# this creates a password manager
passman.add_password(None, theurl, username, password)
# because we have put None at the start it will always
# use this username/password combination for  urls
# for which `theurl` is a super-url
 
authhandler = urllib2.HTTPBasicAuthHandler(passman)
# create the AuthHandler
 
opener = urllib2.build_opener(authhandler)
 
urllib2.install_opener(opener)
# All calls to urllib2.urlopen will now use our handler
# Make sure not to include the protocol in with the URL, or
# HTTPPasswordMgrWithDefaultRealm will be very confused.
# You must (of course) use it when fetching the page though.
 
pagehandle = urllib2.urlopen(theurl)
# authentication is now handled automatically for us

----------
assignee: docs at python
components: Documentation
messages: 196854
nosy: docs at python, mingus
priority: normal
severity: normal
status: open
title: Python docs link to terrible outsi
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  3 20:16:41 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Sep 2013 18:16:41 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378232201.14.0.913769312868.issue18914@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +michael.foord
title: Python docs link to terrible outsi -> Confusing documentation in the urllib2 HOWTO

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

From report at bugs.python.org  Tue Sep  3 20:25:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Sep 2013 18:25:52 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378232752.76.0.0503584599837.issue16938@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I wonder if it would be better to have inspect.classify_class_attrs be improved instead?

----------

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

From report at bugs.python.org  Tue Sep  3 20:32:28 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:32:28 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1378233148.38.0.56718013089.issue18747@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
nosy: +larry
priority: normal -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:32:45 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:32:45 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1378233165.01.0.987062091312.issue16043@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:33:16 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:33:16 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1378233196.28.0.0895096749971.issue16042@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:34:02 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:34:02 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1378233242.0.0.165835656692.issue16040@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
nosy: +barry
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:34:33 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:34:33 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1378233273.07.0.328700985689.issue16039@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
nosy: +barry
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:34:57 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:34:57 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1378233297.91.0.428868890554.issue16038@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
nosy: +barry
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:35:18 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:35:18 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1378233318.84.0.848069902213.issue16037@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

blocker for 2.6.9

----------
priority: critical -> release blocker

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

From report at bugs.python.org  Tue Sep  3 20:54:17 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Sep 2013 18:54:17 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1378234457.06.0.824803120844.issue16201@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Here's an updated patch with new tests.

It passes the regression test, and yields noticable performance improvements for IPv6:
before:
$ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'hello'" "s.sendto(DATA, ('127.0.0.1', 4242)) "
10000 loops, best of 3: 28 usec per loop
$ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM); DATA = b'hello'" "s.sendto(DATA, ('::1', 4242)) "
10000 loops, best of 3: 59.1 usec per loop
after:
$ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); DATA = b'hello'" "s.sendto(DATA, ('127.0.0.1', 4242)) "
10000 loops, best of 3: 24.8 usec per loop
$ ./python -m timeit -s "import socket; s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM); DATA = b'hello'" "s.sendto(DATA, ('::1', 4242)) "
10000 loops, best of 3: 26.7 usec per loop

Note that the tests aren't as good as I'd like them to, because apparently some systems (e.g. Solaris) have broken gethostbyaddr()...
But it's cleaner, more robust and more efficient.

----------
Added file: http://bugs.python.org/file31576/parse_inet-1.diff

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

From report at bugs.python.org  Tue Sep  3 20:59:56 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 03 Sep 2013 18:59:56 +0000
Subject: [issue18891] Master patch for content manager addtion to email
 package.
In-Reply-To: <1378193873.32.0.512757291377.issue18891@psf.upfronthosting.co.za>
Message-ID: <20130903145953.7229303f@anarchist>


Barry A. Warsaw added the comment:

On Sep 03, 2013, at 07:37 AM, Stephen J. Turnbull wrote:

>I'm thinking this may be overengineering, but I may as well post it and find
>out for sure. :-) Is it worth encapsulating MIME types?  They're "really"
>pairs as far as mail handling applications are concerned, but they have a
>string representation.

Neat idea.

----------

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

From report at bugs.python.org  Tue Sep  3 21:00:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Sep 2013 19:00:37 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378234837.7.0.878643370531.issue18914@psf.upfronthosting.co.za>


R. David Murray added the comment:

Suggesting using a 3rd party library in order to explain how to use the python standard library to do something isn't going to work.

Would you like to propose an alternate article or an improvement to the howto, using only stdlib facilities?

(Note that the external web page linked to is that of an active Python core contributor.)

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

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

From report at bugs.python.org  Tue Sep  3 21:02:28 2013
From: report at bugs.python.org (Brian Mingus)
Date: Tue, 03 Sep 2013 19:02:28 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378234948.5.0.446808276805.issue18914@psf.upfronthosting.co.za>


Brian Mingus added the comment:

The documentation is confusing. Consider this comment:

# All calls to urllib2.urlopen will now use our handler
# Make sure not to include the protocol in with the URL, or
# HTTPPasswordMgrWithDefaultRealm will be very confused.
# You must (of course) use it when fetching the page though.

In the actual code he provides, he uses the protocol. Furthermore, before showing a simple way to use the libary, he shows a godawfully complex way. 

Either the documentation should made beautiful and comprehensible, or it should not be linked to.

----------

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

From report at bugs.python.org  Tue Sep  3 21:12:02 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Sep 2013 19:12:02 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378235522.75.0.660769489432.issue18914@psf.upfronthosting.co.za>


R. David Murray added the comment:

The article is *explaining* basic auth, thus the pedegogy of the presentation, and why it is a "see also" and not part of the docs proper.

I'll admit I don't understand the first part of that comment, since the second part says you do have to put the protocol in the URL, which is what the example does.

As I said, would you care to propose a replacement?

----------

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

From report at bugs.python.org  Tue Sep  3 21:14:09 2013
From: report at bugs.python.org (Brian Mingus)
Date: Tue, 03 Sep 2013 19:14:09 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378235649.21.0.151055603693.issue18914@psf.upfronthosting.co.za>


Brian Mingus added the comment:

Yes - this link was a waste of my time. It would have been better if it had not been there. I propose to replace it with nothing.

----------

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

From report at bugs.python.org  Tue Sep  3 22:29:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:29:19 +0000
Subject: [issue17487] wave.Wave_read.getparams should be more user friendly
In-Reply-To: <1363726749.83.0.981836859976.issue17487@psf.upfronthosting.co.za>
Message-ID: <1378240159.18.0.269917688154.issue17487@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage: committed/rejected -> patch review

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

From report at bugs.python.org  Tue Sep  3 22:29:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:29:39 +0000
Subject: [issue18901] sunau.getparams should return a namedtuple
In-Reply-To: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>
Message-ID: <1378240179.95.0.0319192656724.issue18901@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Tue Sep  3 22:30:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:30:01 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1378240201.59.0.38594751195.issue18878@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  3 22:31:09 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 03 Sep 2013 20:31:09 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378240269.17.0.894554641257.issue18914@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

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

From report at bugs.python.org  Tue Sep  3 22:37:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:37:55 +0000
Subject: [issue8934] aifc should use str instead of bytes (wave,
 sunau compatibility)
In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za>
Message-ID: <1378240675.56.0.623769996993.issue8934@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I afraid we can't just change comptype to string. We can allow setcomptype() accept strings and convert them to bytes, but we can't change the type of getcomptype()'s result.

----------

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

From report at bugs.python.org  Tue Sep  3 22:47:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:47:49 +0000
Subject: [issue8311] wave module sets data subchunk size incorrectly when
 writing wav file
In-Reply-To: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>
Message-ID: <1378241269.55.0.291269877398.issue8311@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  3 22:49:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:49:15 +0000
Subject: [issue11126] Wave.py does not always write proper length in header
In-Reply-To: <1296864048.5.0.627671615909.issue11126@psf.upfronthosting.co.za>
Message-ID: <1378241355.64.0.642367135069.issue11126@psf.upfronthosting.co.za>


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


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Tue Sep  3 22:56:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 20:56:34 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1378241794.56.0.832043763752.issue18878@psf.upfronthosting.co.za>


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


----------
nosy: +Claudiu.Popa

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

From report at bugs.python.org  Tue Sep  3 23:43:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Sep 2013 21:43:37 +0000
Subject: [issue17487] wave.Wave_read.getparams should be more user friendly
In-Reply-To: <1363726749.83.0.981836859976.issue17487@psf.upfronthosting.co.za>
Message-ID: <3cV1r92Pz1z7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset a14ec46de0a4 by Serhiy Storchaka in branch 'default':
Issue #17487: The result of the wave getparams method now is pickleable again.
http://hg.python.org/cpython/rev/a14ec46de0a4

----------

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

From report at bugs.python.org  Tue Sep  3 23:43:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Sep 2013 21:43:38 +0000
Subject: [issue18901] sunau.getparams should return a namedtuple
In-Reply-To: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>
Message-ID: <3cV1rB0fB5z7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 99d26f32aed3 by Serhiy Storchaka in branch 'default':
Issue #18901: The sunau getparams method now returns a namedtuple rather than
http://hg.python.org/cpython/rev/99d26f32aed3

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

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

From report at bugs.python.org  Wed Sep  4 00:04:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 22:04:36 +0000
Subject: [issue18901] sunau.getparams should return a namedtuple
In-Reply-To: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>
Message-ID: <1378245876.94.0.62583101368.issue18901@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Claudiu for your contribution.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  4 00:06:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 22:06:15 +0000
Subject: [issue17487] wave.Wave_read.getparams should be more user friendly
In-Reply-To: <1363726749.83.0.981836859976.issue17487@psf.upfronthosting.co.za>
Message-ID: <1378245975.17.0.741074834822.issue17487@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Claudiu. I have changed _Wave_params to _wave_params for consistency with issue17818 and issue18901.

----------
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  4 00:08:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 22:08:03 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1378246083.87.0.785637048613.issue18878@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file31577/sunau_context_manager.patch

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

From report at bugs.python.org  Wed Sep  4 00:08:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 22:08:39 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1378246119.17.0.0124605191101.issue18878@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file31512/sunau_context_manager.patch

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

From report at bugs.python.org  Wed Sep  4 00:09:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 22:09:45 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1378246185.89.0.445158672926.issue18878@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I will commit it tomorrow if there are no objections.

----------

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

From report at bugs.python.org  Wed Sep  4 00:37:30 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 03 Sep 2013 22:37:30 +0000
Subject: [issue18914] Confusing documentation in the urllib2 HOWTO
In-Reply-To: <1378229420.77.0.30621022035.issue18914@psf.upfronthosting.co.za>
Message-ID: <1378247850.85.0.0369825293616.issue18914@psf.upfronthosting.co.za>


Michael Foord added the comment:

As David explained, the linked article *explains* basic auth as well as showing how to use the standard library support. I think the article is still of some value, it has certainly been useful to many people.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  4 00:49:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Sep 2013 22:49:38 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <3cV3JL04qNz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 934e650abc4d by Meador Inge in branch '3.3':
Issue #16826: Don't check for PYTHONCASEOK when using -E.
http://hg.python.org/cpython/rev/934e650abc4d

New changeset ba850a78cbbc by Meador Inge in branch 'default':
Issue #16826: Don't check for PYTHONCASEOK when using -E.
http://hg.python.org/cpython/rev/ba850a78cbbc

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

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

From report at bugs.python.org  Wed Sep  4 00:49:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Sep 2013 22:49:58 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378248598.82.0.392041619422.issue18909@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is PyLong_FromVoidPtr() for such cases.

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

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

From report at bugs.python.org  Wed Sep  4 00:50:30 2013
From: report at bugs.python.org (Meador Inge)
Date: Tue, 03 Sep 2013 22:50:30 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <1378248630.66.0.695616908369.issue16826@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  4 01:15:19 2013
From: report at bugs.python.org (mpb)
Date: Tue, 03 Sep 2013 23:15:19 +0000
Subject: [issue18915] ssl.wrap_socket,
 pass in certfile and keyfile as PEM strings
Message-ID: <1378250119.17.0.25988823326.issue18915@psf.upfronthosting.co.za>


New submission from mpb:

It would be nice to be able to pass ssl.wrap_socket the key and certificate as PEM encoded strings, rather than as paths to files.

Similarly for SSLContext.load_cert_chain.

----------
components: Library (Lib)
messages: 196878
nosy: mpb
priority: normal
severity: normal
status: open
title: ssl.wrap_socket, pass in certfile and keyfile as PEM strings
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 01:15:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Sep 2013 23:15:32 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1378250132.41.0.963708223817.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, another TODO: drop the (optional) dependency to psutil. Implement get_process_memory() in C (in the _tracemalloc module).

----------

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

From report at bugs.python.org  Wed Sep  4 01:45:12 2013
From: report at bugs.python.org (Meador Inge)
Date: Tue, 03 Sep 2013 23:45:12 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <1378251912.05.0.105461717254.issue16826@psf.upfronthosting.co.za>


Meador Inge added the comment:

My last commit caused some buildbot failures (http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.3/builds/1069).  I am investigating.

----------

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

From report at bugs.python.org  Wed Sep  4 02:39:05 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Sep 2013 00:39:05 +0000
Subject: [issue18916] Various out-of-date Lock text in 3.2+
Message-ID: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za>


New submission from Tim Peters:

Here under 3.3.2:

"""
>>> from threading import Lock
>>> help(Lock)
Help on built-in function allocate_lock in module _thread:

allocate_lock(...)
    allocate_lock() -> lock object
    (allocate() is an obsolete synonym)
    
    Create a new lock object.  See help(LockType) for information about locks.
"""

But there is no relevant LockType anymore.  The type is now:

"""
>>> type(Lock())
<class '_thread.lock'>
"""

The docs should probably say "help(type(Lock())" instead of "help(LockType)" now.  So let's try that:

"""
>>> help(type(Lock()))
Help on class lock in module _thread:

class lock(builtins.object)
 |  A lock object is a synchronization primitive.  To create a lock,
 |  call the PyThread_allocate_lock() function.
"""

That's a problem:  PyThread_allocate_lock() is a C function, not available (under that name) to Python code.  A Python user should probably stick to threading.Lock().

Skipping most other output:

"""
...
 |  acquire(...)
 |      acquire([wait]) -> bool
 |      (acquire_lock() is an obsolete synonym)
 |      
 |      Lock the lock.  Without argument, this blocks if the lock is already
 |      locked (even by the same thread), waiting for another thread to release
 |      the lock, and return True once the lock is acquired.
 |      With an argument, this will only block if the argument is true,
 |      and the return value reflects whether the lock is acquired.
 |      The blocking operation is interruptible.
...
"""

That's not the right signature for acquire anymore.  Should be

acquire(blocking=True, timeout=-1) 

which is what the threading module docs say.  That is, the docs are up-to-date, but the help strings in the code aren't.  Since 3.2 is the first version introducing the timeout option, that's the earliest version I selected on this report.

I'm going to leave this for someone who wants an easy patch exercise - you're welcome ;-)

----------
components: Interpreter Core
keywords: easy
messages: 196881
nosy: tim.peters
priority: low
severity: normal
stage: needs patch
status: open
title: Various out-of-date Lock text in 3.2+
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/issue18916>
_______________________________________

From report at bugs.python.org  Wed Sep  4 02:49:05 2013
From: report at bugs.python.org (Alan Cristhian)
Date: Wed, 04 Sep 2013 00:49:05 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1378255745.48.0.726403123196.issue18898@psf.upfronthosting.co.za>


Changes by Alan Cristhian <alan.cristh at gmail.com>:


----------
nosy: +Alan.Cristhian

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

From report at bugs.python.org  Wed Sep  4 02:54:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 00:54:58 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <3cV64x3t0Jz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 7801ef4a4ce3 by Meador Inge in branch '3.3':
Issue #16826: Revert fix while Windows issues are being worked out.
http://hg.python.org/cpython/rev/7801ef4a4ce3

New changeset a1282b67b4cf by Meador Inge in branch 'default':
Issue #16826: Revert fix while Windows issues are being worked out.
http://hg.python.org/cpython/rev/a1282b67b4cf

----------

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

From report at bugs.python.org  Wed Sep  4 03:46:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Sep 2013 01:46:40 +0000
Subject: [issue18916] Various out-of-date Lock text in 3.2+
In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za>
Message-ID: <1378259200.46.0.422304992019.issue18916@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks.  I suspect someone will indeed latch on to this soon enough.

We use the 'versions' to track what version we are going to fix the bug in.  So I've removed 3.2, since that only gets security fixes, and 3.5, since that doesn't exist yet.  (If we don't fix this for 3.4, we will change the versions next time we visit the issue.)

----------
nosy: +r.david.murray
versions:  -Python 3.2, Python 3.5

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

From report at bugs.python.org  Wed Sep  4 04:29:09 2013
From: report at bugs.python.org (Manuke)
Date: Wed, 04 Sep 2013 02:29:09 +0000
Subject: [issue15875] tarfile may not make @LongLink for non-ascii character
In-Reply-To: <1346981062.61.0.534239636824.issue15875@psf.upfronthosting.co.za>
Message-ID: <1378261749.44.0.597346752025.issue15875@psf.upfronthosting.co.za>


Changes by Manuke <manuke.skylark at gmail.com>:


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

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

From report at bugs.python.org  Wed Sep  4 05:00:22 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 04 Sep 2013 03:00:22 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1378263622.12.0.515186604639.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

*ping*

----------

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

From report at bugs.python.org  Wed Sep  4 05:54:24 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 04 Sep 2013 03:54:24 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378266864.33.0.630334944711.issue18909@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Is PyLong_FromVoidPtr compatible to PyInt_FromLong on 32 bit Python 2.7? It looks like PyLong_FromVoidPtr returns a PyLong when the address is > 2**31, while PyInt_FromLong returns a PyInt? Not sure it matters. PyLong_FromVoidPtr is certainly cleaner.

----------

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

From report at bugs.python.org  Wed Sep  4 05:59:43 2013
From: report at bugs.python.org (Nick)
Date: Wed, 04 Sep 2013 03:59:43 +0000
Subject: [issue18917] python won't display greek characters in apache under
 windows
Message-ID: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>


New submission from Nick:

I've set up apache on Windows 7 and I'm running python with cgi.

I have a script that contains this:
#!C:\Python34\python.exe
print ("Content-Type: text/html; charset=utf-8\n")
print ("??????")

Pretty simple, right? When I'm opening the page to my browser in stead of "??????" I get weird ??? symbols (when the browser is set on UTF-8) If I set my browser to ISO-8859-7 I will get the normal greek letters.

"sys.stdout.encoding" will display "cp1253" instead of "utf-8" as it probably should.

scripts with only english characters will work totally fine. the problems seems to be on non-english characters. it displays them as ISO-8859-7.

this doesn't seem to be an apache or windows issue as PHP and Lua will run just fine and all the scripts will display greek characters in my browser. the problem occurs only with python.

----------
messages: 196886
nosy: nickl1
priority: normal
severity: normal
status: open
title: python won't display greek characters in apache under windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 06:01:23 2013
From: report at bugs.python.org (Nick)
Date: Wed, 04 Sep 2013 04:01:23 +0000
Subject: [issue18917] python won't display greek characters in apache under
 windows
In-Reply-To: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>
Message-ID: <1378267283.0.0.904103225714.issue18917@psf.upfronthosting.co.za>


Changes by Nick <lowdx1 at yahoo.com>:


----------
components: +Unicode, Windows
nosy: +ezio.melotti

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

From report at bugs.python.org  Wed Sep  4 06:01:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 04:01:25 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <3cVBD46ldsz7LkW@mail.python.org>


Roundup Robot added the comment:

New changeset 96e55a1a0de7 by Andrew Svetlov in branch 'default':
Issue #18882: Add threading.main_thread() function.
http://hg.python.org/cpython/rev/96e55a1a0de7

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

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

From report at bugs.python.org  Wed Sep  4 06:08:19 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 04 Sep 2013 04:08:19 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1378267699.65.0.317827629596.issue18882@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  4 06:40:20 2013
From: report at bugs.python.org (bussau)
Date: Wed, 04 Sep 2013 04:40:20 +0000
Subject: [issue18918] help('FILES') finds no documentation
Message-ID: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>


New submission from bussau:

Calling for help() about the topic 'FILES' returns 

no documentation found for 'FILES'
------------------------------

Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> help('topics')

Here is a list of available topics.  Enter any topic name to get more help.

ASSERTION           DEBUGGING           LITERALS            SEQUENCEMETHODS2
ASSIGNMENT          DELETION            LOOPING             SEQUENCES
ATTRIBUTEMETHODS    DICTIONARIES        MAPPINGMETHODS      SHIFTING
ATTRIBUTES          DICTIONARYLITERALS  MAPPINGS            SLICINGS
AUGMENTEDASSIGNMENT DYNAMICFEATURES     METHODS             SPECIALATTRIBUTES
BACKQUOTES          ELLIPSIS            MODULES             SPECIALIDENTIFIERS
BASICMETHODS        EXCEPTIONS          NAMESPACES          SPECIALMETHODS
BINARY              EXECUTION           NONE                STRINGMETHODS
BITWISE             EXPRESSIONS         NUMBERMETHODS       STRINGS
BOOLEAN             FILES               NUMBERS             SUBSCRIPTS
CALLABLEMETHODS     FLOAT               OBJECTS             TRACEBACKS
CALLS               FORMATTING          OPERATORS           TRUTHVALUE
CLASSES             FRAMEOBJECTS        PACKAGES            TUPLELITERALS
CODEOBJECTS         FRAMES              POWER               TUPLES
COERCIONS           FUNCTIONS           PRECEDENCE          TYPEOBJECTS
COMPARISON          IDENTIFIERS         PRINTING            TYPES
COMPLEX             IMPORTING           PRIVATENAMES        UNARY
CONDITIONAL         INTEGER             RETURNING           UNICODE
CONTEXTMANAGERS     LISTLITERALS        SCOPING             
CONVERSIONS         LISTS               SEQUENCEMETHODS1    

>>> help('FILES')
no documentation found for 'FILES'

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

best regards
stephan

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 196888
nosy: docs at python, st.sempert at gmail.com
priority: normal
severity: normal
status: open
title: help('FILES') finds no documentation
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  4 07:45:41 2013
From: report at bugs.python.org (Daniel Farina)
Date: Wed, 04 Sep 2013 05:45:41 +0000
Subject: [issue14903] dictobject infinite loop while importing socket
In-Reply-To: <1337890784.99.0.00556765207687.issue14903@psf.upfronthosting.co.za>
Message-ID: <1378273541.68.0.042758024362.issue14903@psf.upfronthosting.co.za>


Daniel Farina added the comment:

I've confirmed this in a non-gevent program (actually a very trivial one, I can include the source if anyone asks), in 'initposix'.  This is on a quiet system, so OOM is not a very likely explanation.  Perhaps signal handling?


#0  0x000000000054662d in ?? ()
#1  0x000000000054d12e in ?? ()
#2  0x00000000005209e9 in PyDict_SetItem ()
#3  0x00000000004430cd in ?? ()
#4  0x0000000000456fcc in initposix ()
#5  0x0000000000456d2b in ?? ()
#6  0x000000000055fd03 in ?? ()
#7  0x00000000005600cb in ?? ()
#8  0x00000000004a0893 in ?? ()
#9  0x0000000000560964 in ?? ()
#10 0x0000000000553eab in ?? ()
#11 0x00000000004bf2a6 in PyObject_Call ()
#12 0x00000000004bf5a6 in PyEval_CallObjectWithKeywords ()
#13 0x000000000046870b in PyEval_EvalFrameEx ()
#14 0x000000000057bd02 in PyEval_EvalCodeEx ()
#15 0x000000000057cda8 in PyImport_ExecCodeModuleEx ()
#16 0x000000000055f6d1 in ?? ()
#17 0x00000000005600cb in ?? ()
#18 0x00000000004a0893 in ?? ()
#19 0x0000000000560964 in ?? ()
#20 0x0000000000553eab in ?? ()
#21 0x00000000004bf2a6 in PyObject_Call ()
#22 0x00000000004bf5a6 in PyEval_CallObjectWithKeywords ()
#23 0x000000000046870b in PyEval_EvalFrameEx ()
#24 0x000000000057bd02 in PyEval_EvalCodeEx ()
#25 0x000000000057cda8 in PyImport_ExecCodeModuleEx ()
#26 0x000000000055f6d1 in ?? ()
#27 0x00000000005600cb in ?? ()
#28 0x00000000004a0893 in ?? ()
#29 0x0000000000560964 in ?? ()
#30 0x0000000000553eab in ?? ()
#31 0x00000000004bf2a6 in PyObject_Call ()
#32 0x00000000004943c5 in PyObject_CallFunction ()
#33 0x000000000054dfbe in PyImport_Import ()
#34 0x000000000050df4d in ?? ()
#35 0x0000000000511ae2 in ?? ()
#36 0x0000000000512764 in Py_Main ()
#37 0x00007f88142bc76d in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#38 0x000000000041ba51 in _start ()

----------

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

From report at bugs.python.org  Wed Sep  4 07:49:15 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 04 Sep 2013 05:49:15 +0000
Subject: [issue18918] help('FILES') finds no documentation
In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>
Message-ID: <1378273755.45.0.188603960504.issue18918@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

I am able to reproduce on Python 3.3 as well.

----------
components:  -Interpreter Core
nosy: +Ramchandra Apte
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Sep  4 07:49:54 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 04 Sep 2013 05:49:54 +0000
Subject: [issue14903] dictobject infinite loop while importing socket
In-Reply-To: <1337890784.99.0.00556765207687.issue14903@psf.upfronthosting.co.za>
Message-ID: <1378273794.01.0.742042665619.issue14903@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

If you could supply the source that'd be great.

----------
nosy: +alex

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

From report at bugs.python.org  Wed Sep  4 08:12:05 2013
From: report at bugs.python.org (Daniel Farina)
Date: Wed, 04 Sep 2013 06:12:05 +0000
Subject: [issue14903] dictobject infinite loop while importing socket
In-Reply-To: <1337890784.99.0.00556765207687.issue14903@psf.upfronthosting.co.za>
Message-ID: <1378275125.45.0.717032008066.issue14903@psf.upfronthosting.co.za>


Daniel Farina added the comment:

Attached.  The program's function is to take a base64 encoded string and arguments as input and then to materialize this program on disk and run it with its arguments.

Notably, this one contains no socket interaction at all, unlike the other examples, which narrows the cause quite a bit.  It is run via 'ssh'.  Like the other case, it's during module dictionary set-up.

----------
Added file: http://bugs.python.org/file31578/offender.py

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

From report at bugs.python.org  Wed Sep  4 08:17:07 2013
From: report at bugs.python.org (Daniel Farina)
Date: Wed, 04 Sep 2013 06:17:07 +0000
Subject: [issue14903] dictobject infinite loop in module set-up
In-Reply-To: <1337890784.99.0.00556765207687.issue14903@psf.upfronthosting.co.za>
Message-ID: <1378275427.01.0.399674453658.issue14903@psf.upfronthosting.co.za>


Daniel Farina added the comment:

altered title now that it's been seen in init_posix.

----------
title: dictobject infinite loop while importing socket -> dictobject infinite loop in module set-up

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

From report at bugs.python.org  Wed Sep  4 08:26:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 06:26:23 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1378275983.81.0.895685169003.issue18882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't think you saw my review, but could you add a docstring to the main_thread() function? Thanks!

----------

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

From report at bugs.python.org  Wed Sep  4 08:37:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 06:37:12 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378276632.89.0.385862354094.issue18909@psf.upfronthosting.co.za>


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


----------
priority: normal -> high
stage:  -> patch review
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Wed Sep  4 09:31:41 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Sep 2013 07:31:41 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1378279901.02.0.908389076719.issue12704@psf.upfronthosting.co.za>


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


----------
nosy: +pje
versions:  -Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Sep  4 09:36:02 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 04 Sep 2013 07:36:02 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1377858406.03.0.871625066732.issue18882@psf.upfronthosting.co.za>
Message-ID: <1378280162.39.0.492305255033.issue18882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

I did not received review email, sorry.
Docstring is added.
BTW 'threading' module has almost no docstrings, that's why I've added only docs at first.
Do you think docstrings should be added to all public functions?
Thanks.

----------

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

From report at bugs.python.org  Wed Sep  4 10:24:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 08:24:44 +0000
Subject: [issue18882] Add threading.main_thread() function
In-Reply-To: <1378280162.39.0.492305255033.issue18882@psf.upfronthosting.co.za>
Message-ID: <1113509780.35752935.1378283078905.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> BTW 'threading' module has almost no docstrings, that's why I've
> added only docs at first.
> Do you think docstrings should be added to all public functions?

Well, probably, although that's another issue :)

----------

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

From report at bugs.python.org  Wed Sep  4 10:58:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 08:58:04 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1378285084.96.0.497387748547.issue16201@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Perhaps you could add tests for the broadcast special cases?

----------

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

From report at bugs.python.org  Wed Sep  4 10:58:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 08:58:14 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1378285094.12.0.461570699206.issue16201@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Wed Sep  4 11:30:48 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 04 Sep 2013 09:30:48 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378287048.77.0.960814478482.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31579/temp_dir_exists_retry_test_33_34.patch

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

From report at bugs.python.org  Wed Sep  4 11:31:08 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 04 Sep 2013 09:31:08 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378287068.51.0.676970748814.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31580/temp_dir_exists_retry_test_27.patch

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

From report at bugs.python.org  Wed Sep  4 12:19:58 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 04 Sep 2013 10:19:58 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1378289998.42.0.455954252753.issue16037@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Reworded TooMuch to TooMany and made a patch for 2.6 too (2.7 didn't apply cleanly there)

----------
Added file: http://bugs.python.org/file31581/issue16037_py26.patch

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

From report at bugs.python.org  Wed Sep  4 12:20:03 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 04 Sep 2013 10:20:03 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1378290003.44.0.219469785438.issue16037@psf.upfronthosting.co.za>


Changes by Jyrki Pulliainen <jyrki at dywypi.org>:


Added file: http://bugs.python.org/file31582/issue16037_py27_v2.patch

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

From report at bugs.python.org  Wed Sep  4 12:20:07 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Wed, 04 Sep 2013 10:20:07 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1378290007.3.0.180276021551.issue16037@psf.upfronthosting.co.za>


Changes by Jyrki Pulliainen <jyrki at dywypi.org>:


Added file: http://bugs.python.org/file31583/issue16037_py32_v2.patch

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

From report at bugs.python.org  Wed Sep  4 12:59:54 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 04 Sep 2013 10:59:54 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378292394.09.0.985622765948.issue18849@psf.upfronthosting.co.za>


Vlad Shcherbina added the comment:

1. I agree that consistency between 2.7 and 3.* have some value, but maybe it's better to take less permissive approach in 3.* instead and only retry when exception is PermissionError _and_ errno is EACCES?

2. Currently it's being reraised unless platform.name == 'nt'. Also, I added a test, so if there are problems on other platforms, they will surface (I myself only tried it on linux and windows 7 though).

----------

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

From report at bugs.python.org  Wed Sep  4 13:11:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 11:11:51 +0000
Subject: [issue18919] Unify audio modules tests
Message-ID: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Three audio modules, aifc, sunau and wave, have similar interfaces and poor tests. The proposed patch introduces new file Lib/test/audiotests.py with common audio tests.

New testing exposes some bugs and discrepancy between different audio modules. For example aifc uses bytes for compression type and name, while sunau and wave use strings (issue8934). aifc closes underlied file object on close(), while sunau and wave don't. wave rounds a framerate, while aifc and sunau truncate it. Different modules have different behaviors when process framedata with length which is not divisible by frame size.

----------
assignee: serhiy.storchaka
components: Tests
files: audiotests.patch
keywords: patch
messages: 196900
nosy: Claudiu.Popa, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Unify audio modules tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31584/audiotests.patch

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

From report at bugs.python.org  Wed Sep  4 13:16:31 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 04 Sep 2013 11:16:31 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1378293391.76.0.937535634617.issue18919@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

I love this idea! I was thinking while working on sunau/aifc/wave patches that we can do more than this, unify the entire audio modules,
getting rid of Aifc_write/read and Wave_write/read was in fact my first desire.
 One way that I thought about was to provide an abc and each module would implement that interface.
That way we could create new modules for audio operations for other formats as well. If this sounds like a good idea, I could try to provide a patch for this.

----------

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

From report at bugs.python.org  Wed Sep  4 13:30:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 11:30:36 +0000
Subject: [issue18901] sunau.getparams should return a namedtuple
In-Reply-To: <1378063223.81.0.0712073256156.issue18901@psf.upfronthosting.co.za>
Message-ID: <3cVNBM3fr0z7Llj@mail.python.org>


Roundup Robot added the comment:

New changeset 61ca4732399b by Serhiy Storchaka in branch 'default':
Issues #18901, #18919: Fix a typo in the _sunau_params name.
http://hg.python.org/cpython/rev/61ca4732399b

----------

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

From report at bugs.python.org  Wed Sep  4 13:30:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 11:30:36 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <3cVNBN1nv1z7LmF@mail.python.org>


Roundup Robot added the comment:

New changeset 61ca4732399b by Serhiy Storchaka in branch 'default':
Issues #18901, #18919: Fix a typo in the _sunau_params name.
http://hg.python.org/cpython/rev/61ca4732399b

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

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

From report at bugs.python.org  Wed Sep  4 13:32:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 11:32:06 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1378294326.07.0.560128543211.issue18919@psf.upfronthosting.co.za>


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


----------
dependencies: +Add support of the 'with' statement to sunau.open.

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

From report at bugs.python.org  Wed Sep  4 14:13:18 2013
From: report at bugs.python.org (Nick)
Date: Wed, 04 Sep 2013 12:13:18 +0000
Subject: [issue18917] python won't display greek characters in apache under
 windows
In-Reply-To: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>
Message-ID: <1378296798.49.0.89660279242.issue18917@psf.upfronthosting.co.za>


Nick added the comment:

Turns out adding "SetEnv PYTHONIOENCODING utf-8" to the end of apache's httpd.conf file fixed the problem for me.

----------

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

From report at bugs.python.org  Wed Sep  4 14:25:57 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 04 Sep 2013 12:25:57 +0000
Subject: [issue18615] sndhdr.whathdr could return a namedtuple
In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za>
Message-ID: <1378297557.34.0.488516480751.issue18615@psf.upfronthosting.co.za>


Changes by Claudiu.Popa <pcmanticore at gmail.com>:


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

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

From report at bugs.python.org  Wed Sep  4 14:30:47 2013
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 04 Sep 2013 12:30:47 +0000
Subject: [issue18920] argparse module version action
Message-ID: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

Hi,
I just noticed that version output generated via the
**'version' action** of the **argparse** module
is routed to stderr. I'd expect regular output to go to stdout instead.
The current behavior also seems inconsistent to me because --help
prints to stdout.
Best,
Wolfgang

----------
messages: 196905
nosy: wolma
priority: normal
severity: normal
status: open
title: argparse module version action
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep  4 14:59:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 12:59:50 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378299590.64.0.179948568966.issue18849@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Re (1) let's leave it as it is, now. I don't think it really matters.

I left some comments in Rietveld.

----------

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

From report at bugs.python.org  Wed Sep  4 15:03:48 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:03:48 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1378299828.64.0.605084555396.issue12704@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Why guess... did you try it in the code?

Trying has another goal - it would be nice to have a short code sample here demonstrating what's happening. The paragraph you're quoting seems obscure to me, with or without the fix.

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Wed Sep  4 15:13:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 13:13:14 +0000
Subject: [issue18615] sndhdr.whathdr could return a namedtuple
In-Reply-To: <1375370275.79.0.808837089288.issue18615@psf.upfronthosting.co.za>
Message-ID: <1378300394.71.0.332087515499.issue18615@psf.upfronthosting.co.za>


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


----------
nosy: +r.david.murray
stage:  -> patch review

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

From report at bugs.python.org  Wed Sep  4 15:17:59 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:17:59 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378300679.83.0.346756162676.issue18920@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Yes, it seems like an oversight to me. Printing --version to stdout is more customary (Python itself does it, and most other tools do too).

A question comes up about backwards compatibility. I would definitely not change it in 2.x - it's just not worth it. As for 3.x, should this go into 3.3 too or just 3.4?

----------
nosy: +bethard, eli.bendersky, serhiy.storchaka
versions: +Python 3.4 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep  4 15:24:21 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:24:21 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1378301061.17.0.237290871161.issue18898@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm still interested in seeing benchmarks that show where this actually improves things and by how much. Also, whether any regressions occur and how serious they are.

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Wed Sep  4 15:26:47 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 13:26:47 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378301207.52.0.672185270845.issue18920@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Only on 3.4.
Python prints the version on stdout since 3.4 -- before it used stderr:
3.3$ ./python -V 2> /dev/null
3.3$ ./python -V > /dev/null
Python 3.3.2+

3.4$ ./python -V 2> /dev/null
Python 3.4.0a1+
3.4$ ./python -V > /dev/null

This might also explain why argparse uses stderr (other modules/scripts in the stdlib might do the same too).

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

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

From report at bugs.python.org  Wed Sep  4 15:34:23 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:34:23 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378301207.52.0.672185270845.issue18920@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-LoeJUveS3GNaNyYQbfd1dMSiDP6sv+93qhKPGYrWwrw@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Sep 4, 2013 at 6:26 AM, Ezio Melotti <report at bugs.python.org> wrote:

>
> Ezio Melotti added the comment:
>
> Only on 3.4.
> Python prints the version on stdout since 3.4 -- before it used stderr:
> 3.3$ ./python -V 2> /dev/null
> 3.3$ ./python -V > /dev/null
> Python 3.3.2+
>
> 3.4$ ./python -V 2> /dev/null
> Python 3.4.0a1+
> 3.4$ ./python -V > /dev/null
>
> This might also explain why argparse uses stderr (other modules/scripts in
> the stdlib might do the same too).
>

Ah, right. On 3.4 Python's main.c uses printf for --version; on earlier
versions it's fprintf(stderr...)

I guess it's a no-brainer then; 3.4 has to be changed, but not earlier
versions. I'll whip up a quick patch.

----------

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

From report at bugs.python.org  Wed Sep  4 15:36:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:36:11 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378301771.28.0.355674538222.issue18920@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The Python executable change is from #18338

----------

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

From report at bugs.python.org  Wed Sep  4 15:38:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 13:38:19 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1378301899.48.0.652847433269.issue18898@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  4 15:40:00 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 13:40:00 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1378302000.24.0.157110150739.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Found it!

It was a combination of __objclass__ not being defined on the enum mmebers, and the metatype not being searched in the __mro__ by inspect.  Thanks, Ronald, for the necessary clues.

Patch attached.

I'm not sure if I have the method wowser showing up in the correct dir().  Thoughts?

----------
keywords: +patch
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file31585/issue18693.stoneleaf.01.patch

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

From report at bugs.python.org  Wed Sep  4 15:43:54 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 13:43:54 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378302234.36.0.0255506282829.issue16938@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Issue18693 has a patch to `inspect` so that classify_class_attrs will also look in the metaclass.  If that is accepted I think PyDoc is okay as is.

----------

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

From report at bugs.python.org  Wed Sep  4 15:48:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 13:48:28 +0000
Subject: [issue8311] wave module sets data subchunk size incorrectly when
 writing wav file
In-Reply-To: <1270388213.12.0.14457017538.issue8311@psf.upfronthosting.co.za>
Message-ID: <1378302508.44.0.180507143703.issue8311@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It's because you write an array of integers while writeframes() expects a bytes object.

Here is a test.

----------
keywords: +patch
stage: test needed -> needs patch
versions: +Python 2.7, Python 3.3, Python 3.4 -Python 2.6
Added file: http://bugs.python.org/file31586/wave_test_write_array.patch

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

From report at bugs.python.org  Wed Sep  4 15:49:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:49:32 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378302572.24.0.0242902781691.issue18920@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Patch attached

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31587/issue18920.1.patch

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

From report at bugs.python.org  Wed Sep  4 15:51:39 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 13:51:39 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1378302699.3.0.0260318223317.issue18693@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Great, Ethan.

I'd say the inspect fix has to be reviewed and committed separately. Maybe #16938 is the right place to post the patch for it. Once that's in, we can review/commit the enum parts.

----------

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

From report at bugs.python.org  Wed Sep  4 16:03:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 14:03:43 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378303423.25.0.426418842539.issue18920@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> This might also explain why argparse uses stderr (other modules/scripts in the stdlib might do the same too).

Lib/trace.py, Tools/pynche/Main.py, and Tools/i18n/pygettext.py write to the stdout.

Lib/smtpd.py and Tools/i18n/msgfmt.py write to the stderr.

The optparse module also writes to the stdout.

----------

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

From report at bugs.python.org  Wed Sep  4 16:13:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 14:13:10 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378303990.26.0.0614344174364.issue18920@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You misplace Misc/NEWS entry in wrong section -- "What's New in Python 3.4.0 Alpha 1".

I think this change (as change of issue18338) worths the mentioning in Doc/whatsnew/3.4.rst.

Did you run all test suite? This change can affect other tests.

----------

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

From report at bugs.python.org  Wed Sep  4 16:27:30 2013
From: report at bugs.python.org (Steven Murdoch)
Date: Wed, 04 Sep 2013 14:27:30 +0000
Subject: [issue18921] In imaplib,
 cached capabilities may be out of date after login
Message-ID: <1378304850.85.0.68028293284.issue18921@psf.upfronthosting.co.za>


New submission from Steven Murdoch:

When an IMAP server is behind a proxy, the proxy's capabilities may differ from that of the actual IMAP server. However, in Python imaplib, the client will ignore any updates to available capabilities in the response to the LOGIN command (see rfc3501, section 6.2.3). As a result, imaplib will incorrectly assume that certain features are not available (including the IDLE patch in issue 11245, and as implemented in getmail 4.43.0). imaplib should refresh its capability list either based on the result of the login command or by explicitly sending a CAPABILITY command following login.

----------
components: Library (Lib)
messages: 196920
nosy: sjmurdoch
priority: normal
severity: normal
status: open
title: In imaplib, cached capabilities may be out of date after login
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep  4 16:28:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 14:28:55 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378304935.92.0.16177319048.issue18909@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed, for less surprise we should use PyInt_FromSsize_t() on Python 2.7.

----------

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

From report at bugs.python.org  Wed Sep  4 16:49:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 14:49:28 +0000
Subject: [issue18922] Output versions of scripts to stdout
Message-ID: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The Lib/smtpd.py and Tools/i18n/msgfmt.py scripts write their version strings to stderr. It should be changed to stdout for consistency with most common practice. See also issue18338 and issue18920.

----------
components: Demos and Tools, Library (Lib)
keywords: easy
messages: 196922
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Output versions of scripts to stdout
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 17:07:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 15:07:42 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377982884.97.0.741244299739.issue18808@psf.upfronthosting.co.za>
Message-ID: <426932132.36686992.1378307256182.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> What I still don't understand:  the new lock is an internal
> implementation detail.  How would it gain a weakref with a callback?
>  Users aren't going to mess with this lock, and if you want to stop
> Python maintainers from giving it a weakref with a callback, simply
> say they shouldn't do that (in the code comments) - you could even
> add code verifying it doesn't have any weakrefs outstanding
> (although that would likely be a waste of time and code:  no
> maintainer is going to _want_ to make a weakref to it, let alone a
> weakref with a callback).

Well... perhaps I'm being too perfectionist, but I don't want Python
to be crashable merely by manipulating a Thread object's private
attributes.
If I add some check code, it will quickly become more complicated than
the current weakref version, which works by design :-)

> My concern is the bulk and obscurity of this code, all to plug such a
> minor hole.  I call it "minor" because it's been reported once in
> the history of the project, and Tamas wormed around it with a
> 1-liner (added a sleep).

Yeah, the overall concern is a bit obscure, but still: right now, if
you use threads inside a subinterpreter, your code can work or crash
depending on subtle timing conditions (where "crash" doesn't even mean
"raise an exception" but "abort the whole process"). So I think it's
worth trying to fix, even though the complication can look a bit
disproportionate.

----------

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

From report at bugs.python.org  Wed Sep  4 17:08:54 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 15:08:54 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1378302699.3.0.0260318223317.issue18693@psf.upfronthosting.co.za>
Message-ID: <52274D07.4080705@stoneleaf.us>


Ethan Furman added the comment:

help() won't really be fixed with the inspect patch.  If no objections within a few hours I'll open a new issue for it.

----------

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

From report at bugs.python.org  Wed Sep  4 17:17:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Sep 2013 15:17:11 +0000
Subject: [issue18921] In imaplib,
 cached capabilities may be out of date after login
In-Reply-To: <1378304850.85.0.68028293284.issue18921@psf.upfronthosting.co.za>
Message-ID: <1378307831.7.0.824148980901.issue18921@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree that this would be a good idea, but it is not a bug in the current implementation.  The only place imaplib itself uses the cached capabilities is *before* login, in the starttls method, and there it refreshes it after starttls succeeds.

Although it isn't documented any more than the 'capabilities' attribute is (and therefor neither are part of the public API currently), you can call the capability command yourself if you need the refreshed capabilities in your own code.

Good catch on the bug in the IDLE patch, though.

----------
nosy: +r.david.murray
stage:  -> needs patch
type: behavior -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

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

From report at bugs.python.org  Wed Sep  4 17:18:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Sep 2013 15:18:59 +0000
Subject: [issue11245] Implementation of IMAP IDLE in imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1378307939.72.0.402348881657.issue11245@psf.upfronthosting.co.za>


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


----------
dependencies: +In imaplib, cached capabilities may be out of date after login

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

From report at bugs.python.org  Wed Sep  4 18:23:02 2013
From: report at bugs.python.org (Erik Bray)
Date: Wed, 04 Sep 2013 16:23:02 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1378311782.32.0.543492640781.issue18876@psf.upfronthosting.co.za>


Changes by Erik Bray <erik.m.bray at gmail.com>:


Added file: http://bugs.python.org/file31588/issue_18876_patch_2.diff

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

From report at bugs.python.org  Wed Sep  4 19:05:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 17:05:45 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <3cVWd50nwwz7LnZ@mail.python.org>


Roundup Robot added the comment:

New changeset e4d45315c38c by Charles-Fran?ois Natali in branch 'default':
Issue #16853: Add new selectors module.
http://hg.python.org/cpython/rev/e4d45315c38c

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

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

From report at bugs.python.org  Wed Sep  4 19:31:21 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 04 Sep 2013 17:31:21 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1378315881.45.0.104125913278.issue16038@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I'm attaching a slightly different patch including new tests and which uses a 'maxline' class attribute (as opposed to a global var).
Christian if that's OK with you I will wait a while and then make a commit for all Python versions.

----------
Added file: http://bugs.python.org/file31589/ftplib_maxline.patch

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

From report at bugs.python.org  Wed Sep  4 19:38:34 2013
From: report at bugs.python.org (Meador Inge)
Date: Wed, 04 Sep 2013 17:38:34 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <1378316314.73.0.109916883978.issue16826@psf.upfronthosting.co.za>


Meador Inge added the comment:

Reopening to rework test cases.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

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

From report at bugs.python.org  Wed Sep  4 19:47:08 2013
From: report at bugs.python.org (Li Wah Teng)
Date: Wed, 04 Sep 2013 17:47:08 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
 VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1378316828.12.0.720979263897.issue7511@psf.upfronthosting.co.za>


Li Wah Teng added the comment:

About the "'KEY_BASE' is not defined" error in Steve Dower's diff, I was able to fix it by adding the following line before the KEY_BASE variable is referenced:

KEY_BASE = r"Software\Microsoft\\"

With this, I was finally able to use the patched msvccompiler9.py to build PyCrypto using VS Express 2010 with Windows SDK 7.1 and Python 3.3.2 (64-bit) installed.

If someone can confirm that this is the only thing missing in the 2 versions of the msvccompiler9.diff files, it would be great.

Hope it helps!

----------
nosy: +lwteng

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

From report at bugs.python.org  Wed Sep  4 19:50:00 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Sep 2013 17:50:00 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <1378317000.72.0.670433487087.issue18922@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Sep  4 20:27:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 18:27:17 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <3cVWd50nwwz7LnZ@mail.python.org>
Message-ID: <CAMpsgwai45ZoLMfyNNu+mDt5iPp4rMzRUWUXWFFWeu9BSP6rvw@mail.gmail.com>


STINNER Victor added the comment:

> New changeset e4d45315c38c by Charles-Fran?ois Natali in branch 'default':
> Issue #16853: Add new selectors module.
> http://hg.python.org/cpython/rev/e4d45315c38c

Great! Congrats Charles-Fran?ois for the new module! I tried to
implement such module once but I gave up because it was more complex
than what I expected.

----------

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

From report at bugs.python.org  Wed Sep  4 20:30:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 18:30:48 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <3cVYWD0Js4z7Lp6@mail.python.org>


Roundup Robot added the comment:

New changeset 6b14ebe0f7ac by Victor Stinner in branch 'default':
Issue #16853: Mention the new selectors module in What's New in Python 3.4
http://hg.python.org/cpython/rev/6b14ebe0f7ac

----------

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

From report at bugs.python.org  Wed Sep  4 20:31:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Sep 2013 18:31:46 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378319506.28.0.605001961441.issue16853@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Agreed, this was a great feat of implementation and API design.

Is there anything left to do or can we close this issue?

(I looked at the Proactor code in Tulip again and I think it is not quite as easy to isolate it, so I'm not requesting that Proactors be added to the stdlib at this time.)

----------

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

From report at bugs.python.org  Wed Sep  4 20:35:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 18:35:44 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378319744.06.0.867324407833.issue16853@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Is there anything left to do or can we close this issue?

It would be nice to mention the new selectors module in the documentation of the select module.

----------

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

From report at bugs.python.org  Wed Sep  4 20:37:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 18:37:14 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1378319744.06.0.867324407833.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378319826.2577.0.camel@fsol>


Antoine Pitrou added the comment:

> > Is there anything left to do or can we close this issue?
> 
> It would be nice to mention the new selectors module in the documentation of the select module.

Feel free to make documentation commits :) They don't necessarily have
to pass a review stage.

----------

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

From report at bugs.python.org  Wed Sep  4 20:40:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 18:40:27 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <3cVYkL6np9zSDD@mail.python.org>


Roundup Robot added the comment:

New changeset 142ff216e4b4 by Victor Stinner in branch 'default':
Issue #16853: Mention the new selectors module in the select module
http://hg.python.org/cpython/rev/142ff216e4b4

----------

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

From report at bugs.python.org  Wed Sep  4 20:41:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 18:41:35 +0000
Subject: [issue18923] Use the new selectors module in the subprocess module
Message-ID: <1378320095.08.0.301150241372.issue18923@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python 3.4 has a new selectors module (issue #16853). It would be nice to use it instead of select.poll or select.select in the subprocess module.

----------
messages: 196936
nosy: haypo
priority: normal
severity: normal
status: open
title: Use the new selectors module in the subprocess module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 20:44:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 18:44:54 +0000
Subject: [issue18923] Use the new selectors module in the subprocess module
In-Reply-To: <1378320095.08.0.301150241372.issue18923@psf.upfronthosting.co.za>
Message-ID: <1378320294.46.0.495933222446.issue18923@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Other modules using select.select() or select.poll() for more than 1 file descriptor:

- asyncore
- multiprocessing.connection
- multiprocessing.forkserver

----------

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

From report at bugs.python.org  Wed Sep  4 20:44:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 18:44:57 +0000
Subject: [issue18823] Idle: use pipes instead of sockets to talk with user
 subprocess
In-Reply-To: <1377300904.13.0.124289838176.issue18823@psf.upfronthosting.co.za>
Message-ID: <1378320297.53.0.790235433924.issue18823@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  4 20:45:33 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 18:45:33 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378320333.78.0.928681855077.issue16853@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Feel free to make documentation commits :)

Ok, done.

I also created the issue #18923: "Use the new selectors module in the subprocess module".

----------

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

From report at bugs.python.org  Wed Sep  4 20:47:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 18:47:05 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378320425.9.0.654145714778.issue16853@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I feel this can be closed then :) Thanks, Charles-Fran?ois!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Sep  4 20:48:10 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 04 Sep 2013 18:48:10 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378320490.36.0.0707186762122.issue16853@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> Is there anything left to do or can we close this issue?

Add support for select.devpoll on Solaris.

----------

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

From report at bugs.python.org  Wed Sep  4 20:49:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 04 Sep 2013 18:49:26 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378320566.65.0.272219744611.issue16853@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> Is there anything left to do or can we close this issue?

I usually wait until the test is run on the buildbots to check I didn't break anything: apparently that's OK, so we can close.

> It would be nice to mention the new selectors module in the documentation of the select module.

Indeed (I mentioned the select module in selectors' doc, but the contrary is certainly useful to point users to this new module), thanks for your commit.

Where were you when I asked for documentation review ;-)

----------

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

From report at bugs.python.org  Wed Sep  4 20:58:01 2013
From: report at bugs.python.org (Nicola Palumbo)
Date: Wed, 04 Sep 2013 18:58:01 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <1378321081.11.0.552450521086.issue18922@psf.upfronthosting.co.za>


Nicola Palumbo added the comment:

Now The Lib/smtpd.py and Tools/i18n/msgfmt.py scripts write their version strings to stdout, and not to sderr.

Applying the patch the stdout can be redirect
/python.exe Lib/smtpd.py --version >> /dev/null

Without the patch:
/python.exe Lib/smtpd.py --version >> /dev/null
Python SMTP proxy version 0.3

----------
keywords: +patch
nosy: +npalumbo
Added file: http://bugs.python.org/file31590/issue18922.patch

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

From report at bugs.python.org  Wed Sep  4 20:58:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 18:58:06 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <3cVZ6j3mNcz7Ll5@mail.python.org>


Roundup Robot added the comment:

New changeset 33bd39b67cc1 by Antoine Pitrou in branch '3.3':
Issue #18876: The FileIO.mode attribute now better reflects the actual mode under which the file was opened.
http://hg.python.org/cpython/rev/33bd39b67cc1

New changeset b5530669ef70 by Antoine Pitrou in branch 'default':
Issue #18876: The FileIO.mode attribute now better reflects the actual mode under which the file was opened.
http://hg.python.org/cpython/rev/b5530669ef70

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

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

From report at bugs.python.org  Wed Sep  4 20:59:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 18:59:00 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378321140.76.0.138473791804.issue18829@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

IMHO the error should say """TypeError: "delimiter" must be an 1-character string, not bytes""".
We could also have two separate errors for "wrong type" and "right type, wrong length" (this would be a ValueError though).

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

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

From report at bugs.python.org  Wed Sep  4 21:07:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 19:07:22 +0000
Subject: [issue18853] Got ResourceWarning unclosed file when running
 Lib/shlex.py demo
In-Reply-To: <1377612267.45.0.680080135941.issue18853@psf.upfronthosting.co.za>
Message-ID: <1378321642.68.0.838767317108.issue18853@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  4 21:09:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 19:09:05 +0000
Subject: [issue18856] Added test coverage for calendar print functions
In-Reply-To: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>
Message-ID: <1378321745.59.0.153555930973.issue18856@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Sep  4 21:09:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 19:09:56 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1378321796.04.0.134923050782.issue18857@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  4 21:10:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Sep 2013 19:10:48 +0000
Subject: [issue18859] README.valgrind should mention --with-valgrind
In-Reply-To: <1377649189.0.0.381916551624.issue18859@psf.upfronthosting.co.za>
Message-ID: <1378321848.82.0.0967518088139.issue18859@psf.upfronthosting.co.za>


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


----------
type:  -> enhancement

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

From report at bugs.python.org  Wed Sep  4 21:47:27 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 19:47:27 +0000
Subject: [issue18924] Enum members are easily replaced
Message-ID: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Python 3.4.0a1+ (default:33727fbb4668+, Aug 31 2013, 12:34:55) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
--> import enum
--> class Test(enum.Enum):
...   this = 'that'
... 
--> Test.this
<Test.this: 'that'>
--> Test.this = 9
--> Test.this
9

I'm pretty sure we don't want that.

----------
assignee: ethan.furman
messages: 196945
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: Enum members are easily replaced
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep  4 21:55:49 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Sep 2013 19:55:49 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <20130904155546.66f94117@anarchist>


Barry A. Warsaw added the comment:

On Sep 04, 2013, at 07:47 PM, Ethan Furman wrote:

>I'm pretty sure we don't want that.

Agreed, although a "we're all consenting adults" argument could be made.

----------

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

From report at bugs.python.org  Wed Sep  4 22:04:25 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Wed, 04 Sep 2013 20:04:25 +0000
Subject: [issue18045] get_python_version is not import in bdist_rpm.py
In-Reply-To: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za>
Message-ID: <1378325065.47.0.100672032597.issue18045@psf.upfronthosting.co.za>


Lukas Wunner added the comment:

The attached patch adds just the missing import statement (which already exists in all 3.x versions) and changes nothing else.

----------
nosy: +l
Added file: http://bugs.python.org/file31591/issue18045-py27.diff

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

From report at bugs.python.org  Wed Sep  4 22:12:46 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 20:12:46 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <20130904155546.66f94117@anarchist>
Message-ID: <5227943F.8070701@stoneleaf.us>


Ethan Furman added the comment:

I'm not suggesting we try to make it impossible, just tougher (akin to what we did with the name and value attributes on 
an Enum member -- at Guido's behest, no less ;).

----------

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

From report at bugs.python.org  Wed Sep  4 22:18:37 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 20:18:37 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378325917.86.0.199419869209.issue18924@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Time for your friendly devil's advocate... We're using and loving this language:

>>> class Foo:
...   bar = 2
... 
>>> f = Foo()
>>> f.bar
2
>>> f.bar = 42
>>> f.bar
42
>>> 


So let's stop trying to make enums even more alien. This is a non-issue in Python.

[Barry, how come your name in the tracker is linked to your website? me wants...]

----------
keywords: +buildbot

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

From report at bugs.python.org  Wed Sep  4 22:23:19 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Sep 2013 20:23:19 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378325917.86.0.199419869209.issue18924@psf.upfronthosting.co.za>
Message-ID: <20130904162316.7825bb13@anarchist>


Barry A. Warsaw added the comment:

On Sep 04, 2013, at 08:18 PM, Eli Bendersky wrote:

>[Barry, how come your name in the tracker is linked to your website? me
>wants...]

Go to "Your Details" in the left sidebar and enter a "Homepage".

----------

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

From report at bugs.python.org  Wed Sep  4 22:34:36 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 20:34:36 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378326876.68.0.287807964863.issue18924@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

"You do not have permission to edit user" - in a red banner, no less. Blasphemy.

----------

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

From report at bugs.python.org  Wed Sep  4 22:46:24 2013
From: report at bugs.python.org (jort bloem)
Date: Wed, 04 Sep 2013 20:46:24 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378327584.89.0.274856143475.issue18879@psf.upfronthosting.co.za>


jort bloem added the comment:

I am only new to Python, but...

Having looked at the code, I am surprised that the _TemporaryFileWrapper is not a subclass of "file". Surely that would be the "python" way, and would solve this problem, too? __getattr__ would no longer be needed. The opening of the file is within the library, so _os.open() could be replaced with file()... It would require rewriting/reorganising chunks of this code...

----------

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

From report at bugs.python.org  Wed Sep  4 22:53:58 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 04 Sep 2013 20:53:58 +0000
Subject: [issue18925] select.poll.modify is not documented
Message-ID: <1378328037.99.0.424927131422.issue18925@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

It was introduced in Python 2.6:
http://bugs.python.org/issue1657
Will commit a patch soon.

----------
assignee: docs at python
components: Documentation
messages: 196953
nosy: docs at python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: select.poll.modify is not documented
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Sep  4 22:57:37 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 20:57:37 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378325917.86.0.199419869209.issue18924@psf.upfronthosting.co.za>
Message-ID: <52279EC2.8000205@stoneleaf.us>


Ethan Furman added the comment:

Eli Bendersky added the comment:
>
> So let's stop trying to make enums even more alien. This is a non-issue in Python.

Enumerations are supposed to be constant.  Since this is Python there is actually very little that cannot be changed, 
but we can make objects better reflect our intent.

For Enum members Guido had me change the `value` and `name` attributes to properties because the value and name should 
also be constant.  Can they still be changed?  Yes, but you have to know what you're doing.  (Enum.member._name_ = ... )

I'm proposing we do the same thing for the Enum class that we did for the Enum member.

To me, an Enumeration that lets you change its constants higgledy-piggledy is way more alien than one that tries to 
stay, um, /constant/.

----------

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

From report at bugs.python.org  Wed Sep  4 23:08:14 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Sep 2013 21:08:14 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <52279EC2.8000205@stoneleaf.us>
Message-ID: <CAF-Rda8wHBSJo5Z_0sZ70dcEatKiOhH_EMuQTmngC3EXpesvHA@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Sep 4, 2013 at 1:57 PM, Ethan Furman <report at bugs.python.org> wrote:

>
> Ethan Furman added the comment:
>
> Eli Bendersky added the comment:
> >
> > So let's stop trying to make enums even more alien. This is a non-issue
> in Python.
>
> Enumerations are supposed to be constant.  Since this is Python there is
> actually very little that cannot be changed,
> but we can make objects better reflect our intent.
>
> For Enum members Guido had me change the `value` and `name` attributes to
> properties because the value and name should
> also be constant.  Can they still be changed?  Yes, but you have to know
> what you're doing.  (Enum.member._name_ = ... )
>
> I'm proposing we do the same thing for the Enum class that we did for the
> Enum member.
>
> To me, an Enumeration that lets you change its constants higgledy-piggledy
> is way more alien than one that tries to
> stay, um, /constant/.
>

I can empathize with your reasoning, but I'm still -1. There's an infinite
amount of tweaks you can think of to make Enum "safer", in a language that
by design is unsafe for such operations. You will keep finding new holes,
because the language will keep fighting you. And the end result? A bit more
theoretical purity, hardly any tangible gain. But more complex code, which
makes it more prone to bugs and more difficult to understand.

----------

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

From report at bugs.python.org  Wed Sep  4 23:09:25 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Sep 2013 21:09:25 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378328965.4.0.848447681959.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Oh, I'm not opposed, I'm just complaining ;-)

It would be much nicer to have an approach that worked for all thread users, not just threading.Thread users.  For example, a user can easily (well, plausibly) get into the same kinds of troubles here by calling _thread.start_new_thread() directly, then waiting for their threads "to end" before letting the program finish - they have no idea either when their tstates are actually destroyed.

A high-probability way to "appear to fix" this for everyone could change Py_EndInterpreter's

    if (tstate != interp->tstate_head || tstate->next != NULL)
        Py_FatalError("Py_EndInterpreter: not the last thread");

to something like

    int count = 0;
    while (tstate != interp->tstate_head || tstate->next != NULL) {
        ++count;
        if (count > SOME_MAGIC_VALUE)
            Py_FatalError("Py_EndInterpreter: not the last thread");
        sleep(SOME_SHORT_TIME);
    }

In the meantime ;-), you should change this part of the new .join() code:

        if endtime is not None:
            waittime = endtime - _time()
            if not lock.acquire(timeout=waittime):
                return

The problem here is that we have no idea how much time may have elapsed before computing the new `waittime`.  So the new `waittime` _may_ be negative, in which case we've already timed out (but passing a negative `waittime` to acquire() means "wait as long as it takes to acquire the lock").  So this block should return if waittime < 0.

----------

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

From report at bugs.python.org  Wed Sep  4 23:10:27 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 04 Sep 2013 21:10:27 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1357234686.56.0.503079428281.issue16853@psf.upfronthosting.co.za>
Message-ID: <1378329027.75.0.841674258567.issue16853@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I have realized just now that at least epoll() and kqueue() selectors could take advantage and define their own modify() method (there was even a TODO I totally missed). 
Anyway, from now on I'm gonna file separate issues.

----------

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

From report at bugs.python.org  Wed Sep  4 23:12:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 21:12:21 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <1378329141.89.0.775245851776.issue18922@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep  4 23:12:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Sep 2013 21:12:39 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1378329159.06.0.230781175393.issue13153@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This bug can be reproduced on Linux too. Just copy and paste illegal UTF-8 sequence. I.e. b'\xed\xb2\x80' or b'\xc0\x80'. My patch works with first example but failed with second. When change the error handler in fromTclStringAndSize() to "replace" it works with all illegal sequences.

----------
assignee:  -> serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file31592/tkinter_string_conv_2.patch

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

From report at bugs.python.org  Wed Sep  4 23:51:08 2013
From: report at bugs.python.org (Raymond Piller)
Date: Wed, 04 Sep 2013 21:51:08 +0000
Subject: [issue18926] plistlib - str converted to bool
Message-ID: <1378331468.16.0.119656145942.issue18926@psf.upfronthosting.co.za>


New submission from Raymond Piller:

A plist with:
<key>My key</key>
<string>False</string>

will parse to a dict as:
{'My key': False}

Expected:
{'My key': 'False'}

If bool(False) is needed, the plist should say:
<key>My key</key>
<false/>

----------
messages: 196959
nosy: VertigoRay
priority: normal
severity: normal
status: open
title: plistlib - str converted to bool
versions: Python 2.7

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

From report at bugs.python.org  Wed Sep  4 23:54:08 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Sep 2013 21:54:08 +0000
Subject: [issue18927] Lock.acquire() docs incorrect about negative timeout
Message-ID: <1378331648.69.0.879815072803.issue18927@psf.upfronthosting.co.za>


New submission from Tim Peters:

Here from the 3.3.2 docs for threading.Lock:

"""
acquire(blocking=True, timeout=-1) 
Acquire a lock, blocking or non-blocking.

...

When invoked with the floating-point timeout argument set to a positive value, block for at most the number of seconds specified by timeout and as long as the lock cannot be acquired. A negative timeout argument specifies an unbounded wait. 

...

"""

However, that's not what the code does for a negative timeout:

>>> from threading import Lock
>>> x = Lock()
>>> x.acquire(1, -0.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: timeout value must be strictly positive

The only negative value the code allows is -1, in lock_PyThread_acquire_lock():

    if (timeout < 0 && timeout != -1) {
        PyErr_SetString(PyExc_ValueError, "timeout value must be "
                        "strictly positive");
        return NULL;
    }

The docs should change to say that -1 is special ;-)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 196960
nosy: docs at python, tim.peters
priority: normal
severity: normal
status: open
title: Lock.acquire() docs incorrect about negative timeout
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Sep  4 23:57:04 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 04 Sep 2013 21:57:04 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378331824.58.0.456873658996.issue18924@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm also -1, though I do appreciate the "indicating intent" argument.  What's the risk that someone will accidentally overwrite an enum item?  Also, is there other enum functionality that relies on the continued existence of the initial enum items?  If not then I'm in the "consenting adults" camp.  Eli makes a good point about the potential for (ultimately) unnecessary complexity and what that costs us.

However, now's the time to come to a conclusion--before the 3.4 release (and likely beta 1) lock in the API.

----------
nosy: +eric.snow

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

From report at bugs.python.org  Wed Sep  4 23:57:42 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Sep 2013 21:57:42 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378331862.56.0.105473555243.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Oops!  The docs are wrong - a negative timeout actually raises:

ValueError: timeout value must be strictly positive

unless the timeout is exactly -1.  All the more reason to ensure that a negative waittime isn't passed.

I opened a different issue about the doc glitch.

----------

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

From report at bugs.python.org  Thu Sep  5 00:00:57 2013
From: report at bugs.python.org (Ray)
Date: Wed, 04 Sep 2013 22:00:57 +0000
Subject: [issue18926] plistlib - str converted to bool
In-Reply-To: <1378331468.16.0.119656145942.issue18926@psf.upfronthosting.co.za>
Message-ID: <1378332057.23.0.689820158469.issue18926@psf.upfronthosting.co.za>


Ray added the comment:

Disregard, I think.  I'm not sure why, but my current app seems to be doing the converting.

>>> import plistlib
>>> pl = {'My key': 'False'}
>>> plist = plistlib.writePlistToString(pl)
>>> plist
'<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n\t<key>My key</key>\n\t<string>False</string>\n</dict>\n</plist>\n'
>>> plistlib.readPlistFromString(plist)
{'My key': 'False'}
>>> pl = {'My key': False}
>>> plist = plistlib.writePlistToString(pl)
>>> plist
'<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<dict>\n\t<key>My key</key>\n\t<false/>\n</dict>\n</plist>\n'
>>> plistlib.readPlistFromString(plist)
{'My key': False}

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 00:03:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 22:03:49 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <3cVfF100JCz7Ljk@mail.python.org>


Roundup Robot added the comment:

New changeset fc2b88a27fa1 by Antoine Pitrou in branch '2.7':
Issue #18876: The FileIO.mode attribute now better reflects the actual mode under which the file was opened.
http://hg.python.org/cpython/rev/fc2b88a27fa1

----------

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

From report at bugs.python.org  Thu Sep  5 00:04:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Sep 2013 22:04:59 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1378332299.42.0.986650503548.issue18876@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I have committed your patch. Thank you!

----------

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

From report at bugs.python.org  Thu Sep  5 00:05:18 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 04 Sep 2013 22:05:18 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378332318.03.0.380952446091.issue18924@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Yes, as a matter of fact:

--> Test.this
<Test.this: 'that'>
--> Test.this = 'other'
--> Test.this
'other'
--> Test('that')
<Test.this: 'that'>
--> list(Test)
[<Test.this: 'that'>]

As you can see, the Test Enum becomes inconsistent if this is allowed.

----------

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

From report at bugs.python.org  Thu Sep  5 00:05:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 22:05:44 +0000
Subject: [issue18925] select.poll.modify is not documented
In-Reply-To: <1378328037.99.0.424927131422.issue18925@psf.upfronthosting.co.za>
Message-ID: <1378332344.83.0.749582157394.issue18925@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For your information, epoll.closed and kqueue.closed were not documented. I documented them recently in Python 3.4 doc.

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Sep  5 00:28:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Sep 2013 22:28:26 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <3cVfnP5WSQz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset f01e06d26b41 by Victor Stinner in branch '3.3':
Issue #18909: Fix _tkinter.tkapp.interpaddr() on Windows 64-bit, don't cast
http://hg.python.org/cpython/rev/f01e06d26b41

New changeset ac27d979078a by Victor Stinner in branch 'default':
(Merge 3.3) Issue #18909: Fix _tkinter.tkapp.interpaddr() on Windows 64-bit,
http://hg.python.org/cpython/rev/ac27d979078a

New changeset 1a65bb15dedf by Victor Stinner in branch '2.7':
Issue #18909: Fix _tkinter.tkapp.interpaddr() on Windows 64-bit, don't cast
http://hg.python.org/cpython/rev/1a65bb15dedf

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

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

From report at bugs.python.org  Thu Sep  5 00:31:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Sep 2013 22:31:55 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378333915.2.0.251705885997.issue18909@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 1a65bb15dedf by Victor Stinner in branch '2.7':
> Issue #18909: Fix _tkinter.tkapp.interpaddr() on Windows 64-bit, don't cast
> http://hg.python.org/cpython/rev/1a65bb15dedf

I prefer to use a function taking a void* instead of hoping that Py_ssize_t has exactly the same size than void*. Ok, the type may change, but who cares? Do you really rely on the exact type of a private function (_tkinter.tkapp.interpaddr())? :-)

@Christoph: Thanks for the report! Can you please your usecase on Python 2.7, 3.3 and/or 3.4 on Windows 64 bit?

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 01:35:54 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 04 Sep 2013 23:35:54 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378337754.24.0.619676159235.issue18909@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

@haypo: Thanks for fixing this so fast! Your changes work for me on win-amd64-py2.7 and py3.3.

I am aware of two 3rd party C extensions that use the value of interpaddr(): 

https://github.com/python-imaging/Pillow/blob/master/_imagingtk.c#L40
https://github.com/matplotlib/matplotlib/blob/master/src/_tkagg.cpp#L233

Both parse the PyObject returned by interpaddr() into a Py_ssize_t variable using `PyArg_ParseTuple(PyObject*, "n", &Py_ssize_t)` and then cast the Py_ssize_t variable to a (TkappObject*). Can a PyLong with a value > 3**31 be parsed into a Py_ssize_t on 32 bit platforms? Could this become a problem on systems where 32 bit processes can address more than 2 GB?

----------

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

From report at bugs.python.org  Thu Sep  5 02:18:34 2013
From: report at bugs.python.org (David Benbennick)
Date: Thu, 05 Sep 2013 00:18:34 +0000
Subject: [issue18928] Remove misleading documentation for random.shuffle
Message-ID: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>


New submission from David Benbennick:

Since Python 2.1 [1], when random.shuffle was added, the documentation has said:

"""Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated."""

This comment is incorrect and misleading.  In fact, I claim that shuffle can produce "all" permutations for any representable sequence.

To shuffle a sequence of length N requires log(N!) ~ N * log(N/e) bits of randomness [2].  The random module provides a generator with "a period of 2**19937-1", meaning you can get 2**19937 bits of randomness out of it before it starts repeating.

All of which is to say that any representable sequence, say N < 2**50, will need no more than 2**60 bits of randomness to shuffle.  That is well within the period of the random number generator.

Attached is a patch that deletes the comment.

An illustration of this misconception is at [3].


1: http://docs.python.org/release/2.1/lib/module-random.html
2: https://en.wikipedia.org/wiki/Factorial#Rate_of_growth_and_approximations_for_large_n
3: http://stackoverflow.com/questions/3062741/maximal-length-of-list-to-shuffle-with-python-random-shuffle

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 196971
nosy: dbenbenn, docs at python
priority: normal
severity: normal
status: open
title: Remove misleading documentation for random.shuffle
Added file: http://bugs.python.org/file31593/mywork.patch

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

From report at bugs.python.org  Thu Sep  5 02:27:15 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Thu, 05 Sep 2013 00:27:15 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <1378299828.64.0.605084555396.issue12704@psf.upfronthosting.co.za>
Message-ID: <5227CFDA.2050801@rath.org>


Nikolaus Rath added the comment:

On 09/04/2013 06:03 AM, Eli Bendersky wrote:
> Why guess... did you try it in the code?

I don't follow... why guess what? And try what in code?

> it would be nice to have a short code sample here demonstrating what's happening. The paragraph you're quoting seems obscure to me, with or without the fix.

Sounds reasonable. I'll revise the patch and add an example.

Best,

   -Nikolaus

-- 
 ?Time flies like an arrow, fruit flies like a Banana.?

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

----------

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

From report at bugs.python.org  Thu Sep  5 03:17:57 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 05 Sep 2013 01:17:57 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1378343877.46.0.945895183319.issue18874@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Sep  5 04:51:02 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Sep 2013 02:51:02 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
Message-ID: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Part of the solution for Issue18693 is to have `inspect.classify_class_attrs()` properly consider the metaclass (or type) of the class when searching for the origination point of class attributes.

The fix is changing line 325:

-        for base in (cls,) + mro:
+        for base in (cls,) + mro + (type(cls),):

or line 361:

-    return cls.__mro__
+    return cls.__mro__ + (type(cls), )

Should we target previous Pythons with this fix?

----------
messages: 196973
nosy: eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: inspect.classify_class_attrs ignores metaclass
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 04:51:59 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Sep 2013 02:51:59 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378349519.14.0.162299323409.issue18929@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file31594/local_fix.stoneleaf.01

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

From report at bugs.python.org  Thu Sep  5 04:52:12 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Sep 2013 02:52:12 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378349532.9.0.795696946841.issue18929@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file31595/global_fix.stoneleaf.01

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

From report at bugs.python.org  Thu Sep  5 05:11:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Sep 2013 03:11:00 +0000
Subject: [issue18928] Remove misleading documentation for random.shuffle
In-Reply-To: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>
Message-ID: <1378350660.5.0.624542182524.issue18928@psf.upfronthosting.co.za>


R. David Murray added the comment:

It seems to me that 2080 (per the accepted answer to your [3]) is indeed "a rather small len(x)", and that the docs are correct as written.

I wonder if it would be worth adding a footnote that explains how to calculate that example 2080 number from the documented period of the random number generator, to make the concepts involved a little bit clearer?

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

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

From report at bugs.python.org  Thu Sep  5 05:20:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Sep 2013 03:20:43 +0000
Subject: [issue18928] Remove misleading documentation for random.shuffle
In-Reply-To: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>
Message-ID: <1378351243.78.0.0611822809763.issue18928@psf.upfronthosting.co.za>


R. David Murray added the comment:

Alternatively, you would have to supply (or supply a pointer to) a mathematical proof of your thesis.

----------

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

From report at bugs.python.org  Thu Sep  5 05:48:15 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 05 Sep 2013 03:48:15 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1378352895.7.0.507135141344.issue12704@psf.upfronthosting.co.za>


Tim Peters added the comment:

I think the docs are already clear:  they say "the generator-iterator?s close() method will be called".  That's all that needs to be said:  now go look at the docs for generator.close().  They explain _all_ that close() does, and it would be a Bad Idea to duplicate all that in this part of the docs too.  (And, yes, for a start, close() "Raises a GeneratorExit at the point where the generator function was paused".)

It would certainly help if the "close" (in "the generator-iterator?s close() method will be called") were an active hyperlink in the docs.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Thu Sep  5 05:49:41 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 05 Sep 2013 03:49:41 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378352981.14.0.367786011203.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Fudge - there's another unlikely problem here.  For example:  main program creates a threading.Thread t, runs it, and does t.join(5) (whatever - any timeout value).  When t.join() returns, the main program has no idea whether t is done or not.  Suppose t isn't done, but finishes _bootstrap_inner a microsecond (whatever) later.

Now the user follows the doc's advice, and checks t.is_alive() to see whether it still needs to join t.  t.is_alive() returns False!  _bootstrap_inner() already finished, so the t._stopped event is already set.

So the main program skips doing another t.join(), and lets the program exit.  There's no guarantee then that t's tstate has been cleared, and we can be back to same fatal error that started this.

Of course this has nothing to do with the patch switching from a Condition to an Event to manage the stopped state (good change!) - it has to do with that, no matter how it's coded, _bootstrap_inner() says "this thread is done" before the tstate is unlinked from the chain.

For a related reason, note that Python's threading._shutdown() doesn't prevent the fatal shutdown error even after the patch!  _pickSomeNonDaemonThread() also ignores threads for which is_alive() returns False.  As above, that can return False while the tstate is still in the chain, and then threading._shutdown() never joins such a thread.  join() can't fix the problem if it's not called.  I supposed that one can be repaired by removing the is_alive() check in _pickSomeNonDaemonThread() (i.e., always join() every non-daemon thread).

In their favor, the probabilistic "sleep" approaches would almost always "fix" these too ;-)

----------

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

From report at bugs.python.org  Thu Sep  5 06:20:34 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 05 Sep 2013 04:20:34 +0000
Subject: [issue18928] Remove misleading documentation for random.shuffle
In-Reply-To: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>
Message-ID: <1378354834.03.0.230262854684.issue18928@psf.upfronthosting.co.za>


Tim Peters added the comment:

When the comment was introduced, Python's Wichmann-Hill generator had a much shorter period, and we couldn't even generate all the permutations of a deck of cards.

The period is astronomically larger now, but the stackoverflow answer (2080) is correct for the current upper bound.  The docs could be beefed up to say more about that - but they'd get awfully tedious ;-)

To the OP, this is your error:  it takes lg(N!) "bits of randomness" (lg is the logarithm to base 2) to generate _one_ random permutation.  That says nothing about what's needed to generate _all_ permutations.

With an RNG of period P, there are P possible starting states.  The starting state wholly determines the permutation produced.  Therefore an RNG of period P cannot generate more than P distinct permutations (and that's an absolute upper bound - it may not be achieved).  That's why comparing N! to P is the correct computation here, and indeed:

>>> math.factorial(2080) > 2**19937 - 1
False
>>> math.factorial(2081) > 2**19937 - 1
True

If you still don't believe it, here's a challenge:  take a toy RNG with a small period, and use it to generate permutations (via any method you like).  You'll find that you never get more distinct permutations than the period of your RNG.  Then reread the above ;-)

----------
nosy: +tim.peters

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

From report at bugs.python.org  Thu Sep  5 07:14:16 2013
From: report at bugs.python.org (David Benbennick)
Date: Thu, 05 Sep 2013 05:14:16 +0000
Subject: [issue18928] Remove misleading documentation for random.shuffle
In-Reply-To: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>
Message-ID: <1378358056.14.0.745824190972.issue18928@psf.upfronthosting.co.za>


David Benbennick added the comment:

Okay, I see what the comment is saying now.  I was mistaken.

It might make the statement clearer if it is made more precise.  "rather small" is vague.  That vagueness is intentional, but it makes it more confusing.

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

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

From report at bugs.python.org  Thu Sep  5 07:25:49 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Sep 2013 05:25:49 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378358749.34.0.981902729499.issue18924@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
Added file: http://bugs.python.org/file31596/issue18924.stoneleaf.patch.01

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

From report at bugs.python.org  Thu Sep  5 07:40:10 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 05 Sep 2013 05:40:10 +0000
Subject: [issue18928] Remove misleading documentation for random.shuffle
In-Reply-To: <1378340314.25.0.0317280223826.issue18928@psf.upfronthosting.co.za>
Message-ID: <1378359610.28.0.931828722241.issue18928@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

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

From report at bugs.python.org  Thu Sep  5 07:58:44 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Sep 2013 05:58:44 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378360724.24.0.199742174161.issue18929@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The global fix causes these two tests to fail:

======================================================================
FAIL: test_newstyle_mro (test.test_inspect.TestClassesAndFunctions)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue18693/Lib/test/test_inspect.py", line 485, in test_newstyle_mro
    self.assertEqual(expected, got)
AssertionError: Tuples differ: (<class 'test.test_inspect.Tes... != (<class 'test.test_inspect.Tes...

Second tuple contains 1 additional elements.
First extra element 5:
<class 'type'>

  (<class 'test.test_inspect.TestClassesAndFunctions.test_newstyle_mro.<locals>.D'>,
   <class 'test.test_inspect.TestClassesAndFunctions.test_newstyle_mro.<locals>.B'>,
   <class 'test.test_inspect.TestClassesAndFunctions.test_newstyle_mro.<locals>.C'>,
   <class 'test.test_inspect.TestClassesAndFunctions.test_newstyle_mro.<locals>.A'>,
-  <class 'object'>)
?                  ^

+  <class 'object'>,
?                  ^

+  <class 'type'>)

======================================================================
FAIL: test_help_output_redirect (test.test_pydoc.PydocDocTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue18693/Lib/test/test_pydoc.py", line 396, in test_help_output_redirect
    self.assertEqual(expected_text, result)
AssertionError: "Help on module test.pydoc_mod in test:\n\nNAME\n    test.pydoc_mod - This is a  [truncated]... != "Help on module test.pydoc_mod in test:\n\nNAME\n    test.pydoc_mod - This is a  [truncated]...
  Help on module test.pydoc_mod in test:
  
  NAME
      test.pydoc_mod - This is a test module for test_pydoc
  
  CLASSES
      builtins.object
          A
          B
      
      class A(builtins.object)
       |  Hello and goodbye
+      |  
+      |  Method resolution order:
+      |      A
+      |      builtins.object
+      |      builtins.type
       |  
       |  Methods defined here:
       |  
       |  __init__()
       |      Wow, I have no function!
       |  
       |  ----------------------------------------------------------------------
       |  Data descriptors defined here:
       |  
       |  __dict__
       |      dictionary for instance variables (if defined)
       |  
       |  __weakref__
       |      list of weak references to the object (if defined)
      
      class B(builtins.object)
+      |  Method resolution order:
+      |      B
+      |      builtins.object
+      |      builtins.type
+      |  
       |  Data descriptors defined here:
       |  
       |  __dict__
       |      dictionary for instance variables (if defined)
       |  
       |  __weakref__
       |      list of weak references to the object (if defined)
       |  
       |  ----------------------------------------------------------------------
       |  Data and other attributes defined here:
       |  
       |  NO_MEANING = 'eggs'
  
======================================================================

I suspect (hope) updating the tests would be fine.

----------

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

From report at bugs.python.org  Thu Sep  5 08:45:42 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Sep 2013 06:45:42 +0000
Subject: [issue18912] Intendation issue in example code in itertools.count
 documentation
In-Reply-To: <1378195706.84.0.122771342837.issue18912@psf.upfronthosting.co.za>
Message-ID: <1378363542.22.0.86100733076.issue18912@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please assign itertools doc changes to me in the future.

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

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

From report at bugs.python.org  Thu Sep  5 09:12:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Sep 2013 07:12:35 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378337754.24.0.619676159235.issue18909@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbX+TU0XWvVzbEWWLMDhTtDDeWis0bPA-GkeH131qt2PA@mail.gmail.com>


STINNER Victor added the comment:

2013/9/5 Christoph Gohlke <report at bugs.python.org>:
> I am aware of two 3rd party C extensions that use the value of interpaddr():
>
> https://github.com/python-imaging/Pillow/blob/master/_imagingtk.c#L40
> https://github.com/matplotlib/matplotlib/blob/master/src/_tkagg.cpp#L233
>
> Both parse the PyObject returned by interpaddr() into a Py_ssize_t variable using `PyArg_ParseTuple(PyObject*, "n", &Py_ssize_t)` and then cast the Py_ssize_t variable to a (TkappObject*).

Ok, the code looks correct. Py_ssize_t is supposed to have the same
size than a void*.

> Can a PyLong with a value > 3**31 be parsed into a Py_ssize_t on 32 bit platforms? Could this become a problem on systems where 32 bit processes can address more than 2 GB?

No, values >= 2^31 will raise an error.

On Linux, addresses with the 32th bit set (range
0x80000000-0xffffffff) are reserved for the Linux kernel. So
interpaddr() should be in the range 0x00000000-0x7fffffff.

If the code worked before my patch, there is not reason for not
working with the patch. My patch only has an impact on one specific
platform: Windows 64 bit, the only platform where sizeof(long) <
sizeof(void*) (on all other platforms supported by Python,
sizeof(void*) == sizeof(long)).

----------

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

From report at bugs.python.org  Thu Sep  5 10:15:00 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Sep 2013 08:15:00 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1378368900.69.0.402589076998.issue18898@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file31597/noincref.diff

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

From report at bugs.python.org  Thu Sep  5 10:15:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Sep 2013 08:15:11 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378368911.55.0.104785470626.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It would be much nicer to have an approach that worked for all thread users, 
> not just threading.Thread users.  For example, a user can easily (well,
> plausibly) get into the same kinds of troubles here by calling
> _thread.start_new_thread() directly, then waiting for their threads "to end" 
> before letting the program finish - they have no idea either when their
> tstates are actually destroyed.

The _thread module is a private API these days, I wouldn't worry too much about that. Are there reasons *not* to use the threading module (except CPython bootstrap issues that normal users should have no bother about)? Also, how would they wait for the thread to end, except by triggering their own Event object?

> So the new `waittime` _may_ be negative, in which case we've already timed
> out (but passing a negative `waittime` to acquire() means "wait as long as 
> it takes to acquire the lock").  So this block should return if waittime < 0.

Thanks, good point :-o

As for the is_alive() method, mmh, ok, it needs to be tweaked too. That will make the patch more interesting.

----------

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

From report at bugs.python.org  Thu Sep  5 10:28:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 08:28:00 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <1378329027.75.0.841674258567.issue16853@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2Vz_M7mPCpt0X3MuSquUJKvjOcAFn3qufPf0cR41vV2A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Giampaolo Rodola' added the comment:
>
> I have realized just now that at least epoll() and kqueue() selectors could take advantage and define their own modify() method (there was even a TODO I totally missed).

As a side note, in the general case, there's more than a performance
optimization: the problem with unregister() + register() vs a real
modify (e.g. EPOLL_CTL_MOD) is that it's subject to a race condition,
if an event fires during the short window where the FD isn't
registered anymore.

But since selectors use level-triggered notification, that's not an
issue: I'll probably add a comment in the code explaining why it's
safe, though.

----------

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

From report at bugs.python.org  Thu Sep  5 10:41:53 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Thu, 05 Sep 2013 08:41:53 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378370513.98.0.753126070354.issue18879@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

I don't see an obvious way of solving that. One thing I could think of is creating a wrapper for file method being returned from __getattr__ that holds reference to _TemporaryFileWrapper instance until the method gets called, please find a patch attached.

----------
keywords: +patch
nosy: +jstasiak
Added file: http://bugs.python.org/file31598/tempfile.patch

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

From report at bugs.python.org  Thu Sep  5 11:22:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Sep 2013 09:22:24 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378372944.1.0.0582615135564.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the patch to accomodate Ezio Melotti's request. The patch now have two separate errors for "wrong type" and "right type, wrong length".

Don't we break compatibility by changing the type of exception from TypeError to ValueError?

----------
Added file: http://bugs.python.org/file31599/fix_error_message_reader_csv_alternative_1_v3.patch

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

From report at bugs.python.org  Thu Sep  5 11:37:10 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Sep 2013 09:37:10 +0000
Subject: [issue1584] Mac OS X: building with X11 Tkinter
In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>
Message-ID: <1378373830.59.0.513441606226.issue1584@psf.upfronthosting.co.za>


Ned Deily added the comment:

Here's a patch. It is simple-minded but I think it should be powerful enough for advanced users to build with non-default Tcl and Tk libraries without having to modify the source.  It adds two new options to configure; if used, both must be specified:

  ./configure \
      --with-tcltk-includes="-I/opt/local/include" \
      --with-tcltk-libs="-L/opt/local/lib -ltcl8.5 -ltk8.5"

The values are passed into the top-level setup.py and override the default searches and values for include_dirs and libraries when building _tkinter.so.

In addition, the options can be overridden with make.  This can be useful when testing tkinter with different versions of Tcl/Tk:

   ./configure
   make
   make test  # test with platform default Tcl/Tk
   ( cd ./build/lib.xx && mv _tkinter.so _tkinter.so.default )
   make \
       TCLTK_INCLUDES="-I/opt/local/include" \
       TCLTK_LIBS="-L/opt/local/lib -ltcl8.6 -ltk8.6"
   make test  # test with another version of Tcl/Tk

I have some more testing to do on other platforms but, unless there are major objections, I intend to commit this soon for use with Issue15663.

----------
components:  -Macintosh
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31600/issue1584_rev0.patch

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

From report at bugs.python.org  Thu Sep  5 12:52:34 2013
From: report at bugs.python.org (Stefan Schukat)
Date: Thu, 05 Sep 2013 10:52:34 +0000
Subject: [issue18930] os.spawnXX functions terminates process if second
 argument is empty list
Message-ID: <1378378354.78.0.544374922966.issue18930@psf.upfronthosting.co.za>


New submission from Stefan Schukat:

If os.spawnv or os.spawnve  is called with an empty second argument the process terminates in release builds under Windows. This is simple to reproduce:

>>> import os
>>> nPath = os.path.join(os.environ["windir"], "notepad.exe")
>>> os.spawnv(os.P_NOWAIT, nPath, []) # or os.spawnv(os.P_NOWAIT, nPath, [], {})

This has the same cause as the bug reported for execv http://bugs.python.org/issue1039 and could be fixed in the same way.

----------
components: Interpreter Core
messages: 196988
nosy: SSchukat
priority: normal
severity: normal
status: open
title: os.spawnXX functions terminates process if second argument is empty list
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  5 12:58:35 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 10:58:35 +0000
Subject: [issue18931] new selectors module should support devpoll on Solaris
Message-ID: <1378378715.64.0.328227872693.issue18931@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is a follow up of issue 16853.
I will try to see whether I can come up with a patch later today.

----------
messages: 196989
nosy: christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, haypo, meador.inge, neologix, pitrou, python-dev, rosslagerwall, sbt
priority: normal
severity: normal
status: open
title: new selectors module should support devpoll on Solaris
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 13:01:54 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 11:01:54 +0000
Subject: [issue18932] selectors and modify()
Message-ID: <1378378914.54.0.524373723237.issue18932@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

This is a follow up of issue 16853 (see comment http://bugs.python.org/issue16853#msg196984).

----------
messages: 196990
nosy: christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, haypo, meador.inge, neologix, pitrou, python-dev, rosslagerwall, sbt
priority: normal
severity: normal
status: open
title: selectors and modify()
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 14:01:00 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:01:00 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382460.47.0.281333296894.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31573/temp_dir_exists_retry_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:01:04 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:01:04 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382464.82.0.592286869088.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31574/temp_dir_exists_retry_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:01:08 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:01:08 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382468.14.0.429066165356.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31579/temp_dir_exists_retry_test_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:01:13 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:01:13 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382473.83.0.420743066046.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31580/temp_dir_exists_retry_test_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:01:43 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:01:43 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382503.09.0.579716054177.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31601/temp_dir_exists_retry_test_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:03:22 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:03:22 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382602.28.0.700397311572.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31602/temp_dir_exists_retry_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:03:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 12:03:24 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378382604.74.0.073236014661.issue18879@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one way is just remove __del__() and monkey-patch underlied file.

----------
Added file: http://bugs.python.org/file31603/tempfile_simplify.patch

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

From report at bugs.python.org  Thu Sep  5 14:03:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 12:03:41 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378382621.22.0.0593471843061.issue18879@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  5 14:03:53 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:03:53 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382633.67.0.314467954953.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31604/temp_dir_exists_retry_test_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:04:03 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:04:03 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382643.16.0.843701946358.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31605/temp_dir_exists_retry_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:07:18 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:07:18 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382838.53.0.965234930471.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31601/temp_dir_exists_retry_test_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:07:23 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:07:23 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382843.06.0.887757533368.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31602/temp_dir_exists_retry_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:07:27 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:07:27 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382847.77.0.081241133914.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31604/temp_dir_exists_retry_test_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:07:34 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:07:34 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382854.73.0.0563127210928.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31605/temp_dir_exists_retry_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:07:48 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:07:48 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382868.52.0.16931447854.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31606/temp_dir_exists_retry_test_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:07:59 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:07:59 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382879.73.0.220302672409.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31607/temp_dir_exists_retry_33_34.patch

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

From report at bugs.python.org  Thu Sep  5 14:09:26 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:09:26 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382966.25.0.783833519424.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31608/temp_dir_exists_retry_test_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:09:39 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Thu, 05 Sep 2013 12:09:39 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <1378382979.73.0.558532263153.issue18849@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31609/temp_dir_exists_retry_27.patch

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

From report at bugs.python.org  Thu Sep  5 14:18:31 2013
From: report at bugs.python.org (Meador Inge)
Date: Thu, 05 Sep 2013 12:18:31 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378383511.04.0.00972772155321.issue18879@psf.upfronthosting.co.za>


Meador Inge added the comment:

I was experimenting with something similar to what Jakub has.  Rebinding the call the the wrapper seems like a simple and clean way to do it.  Although, I wasn't absolutely sure whether this approach covers all cases.

----------

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

From report at bugs.python.org  Thu Sep  5 14:25:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 12:25:38 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1378383938.01.0.0676526067185.issue13153@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Previous patch has a regression, it breaks decoding NUL which Tcl encodes in "modified" UTF-8 as \xc0\x80. However this part of code already broken, because it handles only singular NUL and not a NUL embedded in larger string.

Here is a patch which also fixes decoding NULs from "modified" UTF-8.

----------
Added file: http://bugs.python.org/file31610/tkinter_string_conv_3.patch

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

From report at bugs.python.org  Thu Sep  5 14:26:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 12:26:15 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1378383975.83.0.61958795632.issue13153@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file31185/tkinter_string_conv.patch

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

From report at bugs.python.org  Thu Sep  5 14:26:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 12:26:34 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1378383994.17.0.0236193733877.issue13153@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file31592/tkinter_string_conv_2.patch

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

From report at bugs.python.org  Thu Sep  5 14:42:56 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 12:42:56 +0000
Subject: [issue18923] Use the new selectors module in the subprocess module
In-Reply-To: <1378320095.08.0.301150241372.issue18923@psf.upfronthosting.co.za>
Message-ID: <1378384976.14.0.50653630874.issue18923@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Thu Sep  5 14:47:12 2013
From: report at bugs.python.org (Madison May)
Date: Thu, 05 Sep 2013 12:47:12 +0000
Subject: [issue18856] Added test coverage for calendar print functions
In-Reply-To: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>
Message-ID: <1378385232.43.0.693901609237.issue18856@psf.upfronthosting.co.za>


Madison May added the comment:

At Ezio suggestion, I've updated the patch to use test.support.captured_stdout().

----------
Added file: http://bugs.python.org/file31611/calendar_print_v2.diff

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

From report at bugs.python.org  Thu Sep  5 15:08:38 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 13:08:38 +0000
Subject: [issue18923] Use the new selectors module in the subprocess module
In-Reply-To: <1378320095.08.0.301150241372.issue18923@psf.upfronthosting.co.za>
Message-ID: <1378386518.52.0.788857730155.issue18923@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

It's likely that asyncore won't be able to take any practical advantage from this integration.

To say one, epoll()/kqueue() pollers won't bring any speedup over select()/poll() because of how asyncore.loop() function is implemented (see http://bugs.python.org/issue6692#msg103628 and http://bugs.python.org/issue11273).

Also, the new selectors module only takes read and write events into account, whereas asyncore explicitly closes dispatcher in case of disconnection events (POLLOUT, etc).

In summary I'd say it's a lot wiser to leave asyncore alone and consider it frozen.

----------

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

From report at bugs.python.org  Thu Sep  5 15:09:02 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 05 Sep 2013 13:09:02 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <CAH_1eM2Vz_M7mPCpt0X3MuSquUJKvjOcAFn3qufPf0cR41vV2A@mail.gmail.com>
Message-ID: <52288264.3030702@gmail.com>


Richard Oudkerk added the comment:

On 05/09/2013 9:28am, Charles-Fran?ois Natali wrote:
> As a side note, in the general case, there's more than a performance
> optimization: the problem with unregister() + register() vs a real
> modify (e.g. EPOLL_CTL_MOD) is that it's subject to a race condition,
> if an event fires during the short window where the FD isn't
> registered anymore.

Even with edge-triggered notification, doesn't registering an fd check 
the current readiness:

 >>> import os, select
 >>> r, w = os.pipe()
 >>> p = select.epoll()
 >>> os.write(w, b"h")
 >>> p.register(r, select.EPOLLIN | select.EPOLLET)
 >>> p.poll(0)
[(3, 1)]
 >>> p.poll(0)
[]

Otherwise it would be very difficult to edge-triggered notification.

----------

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

From report at bugs.python.org  Thu Sep  5 15:55:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 13:55:01 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378389301.63.0.324247066133.issue18829@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A comment in csv.py says about compatibility with 2.3! After adding ValueError to the list of catched exceptions we can keep this compatibility for future generations. Here is a patch. I also have resorted the tests a little.

----------
Added file: http://bugs.python.org/file31612/fix_error_message_reader_csv_alternative_1_v4.patch

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

From report at bugs.python.org  Thu Sep  5 16:04:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 14:04:05 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <3cW3Xz4msmz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset a62f59667c9e by Serhiy Storchaka in branch 'default':
Issue #18878: sunau.open now supports the context manager protocol.  Based on
http://hg.python.org/cpython/rev/a62f59667c9e

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

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

From report at bugs.python.org  Thu Sep  5 16:06:25 2013
From: report at bugs.python.org (Nicola Palumbo)
Date: Thu, 05 Sep 2013 14:06:25 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <1378389985.3.0.477997961256.issue18922@psf.upfronthosting.co.za>


Changes by Nicola Palumbo <nikpalumbo at gmail.com>:


Removed file: http://bugs.python.org/file31590/issue18922.patch

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

From report at bugs.python.org  Thu Sep  5 16:06:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 14:06:59 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <3cW3cM0hWMz7Lm8@mail.python.org>


Roundup Robot added the comment:

New changeset 90040e560527 by Christian Heimes in branch '3.3':
Issue #18709: GCC 4.6 complains that 'v' may be used uninitialized in GEN_EMAIL/GEN_URI/GEN_DNS case
http://hg.python.org/cpython/rev/90040e560527

New changeset 4e93f32176fb by Christian Heimes in branch 'default':
Issue #18709: GCC 4.6 complains that 'v' may be used uninitialized in GEN_EMAIL/GEN_URI/GEN_DNS case
http://hg.python.org/cpython/rev/4e93f32176fb

New changeset 07ee48ce4513 by Christian Heimes in branch '2.6':
Issue #18709: GCC 4.6 complains that 'v' may be used uninitialized in GEN_EMAIL/GEN_URI/GEN_DNS case
http://hg.python.org/cpython/rev/07ee48ce4513

New changeset a7d5b86ffb95 by Christian Heimes in branch '2.7':
Issue #18709: GCC 4.6 complains that 'v' may be used uninitialized in GEN_EMAIL/GEN_URI/GEN_DNS case
http://hg.python.org/cpython/rev/a7d5b86ffb95

----------

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

From report at bugs.python.org  Thu Sep  5 16:08:26 2013
From: report at bugs.python.org (Nicola Palumbo)
Date: Thu, 05 Sep 2013 14:08:26 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <1378390106.17.0.243731910034.issue18922@psf.upfronthosting.co.za>


Changes by Nicola Palumbo <nikpalumbo at gmail.com>:


Added file: http://bugs.python.org/file31613/issue18922.patch

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

From report at bugs.python.org  Thu Sep  5 16:10:06 2013
From: report at bugs.python.org (Jonathan Frere)
Date: Thu, 05 Sep 2013 14:10:06 +0000
Subject: [issue18933] Add link to source code in logging documentation
Message-ID: <1378390206.88.0.825858805448.issue18933@psf.upfronthosting.co.za>


New submission from Jonathan Frere:

The logging module documentation is probably best accompanied by the source that it is meant to be documenting.  Could a link to either the package directory (http://hg.python.org/cpython/file/2.7/Lib/logging/) or the __init__.py file in that directory (http://hg.python.org/cpython/file/2.7/Lib/logging/__init__.py), I'd argue the __init__.py file.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 197000
nosy: Johz, docs at python, vinay.sajip
priority: normal
severity: normal
status: open
title: Add link to source code in logging documentation
type: enhancement

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

From report at bugs.python.org  Thu Sep  5 16:37:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 14:37:48 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <3cW4Hv5Md3z7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 39d0dfa5808c by Serhiy Storchaka in branch '3.3':
Issue #18830: inspect.getclasstree() no more produces duplicated entries even
http://hg.python.org/cpython/rev/39d0dfa5808c

New changeset 86ab7b7c173e by Serhiy Storchaka in branch 'default':
Issue #18830: inspect.getclasstree() no more produces duplicated entries even
http://hg.python.org/cpython/rev/86ab7b7c173e

New changeset 408165aced01 by Serhiy Storchaka in branch '2.7':
Issue #18830: inspect.getclasstree() no more produces duplicated entries even
http://hg.python.org/cpython/rev/408165aced01

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

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

From report at bugs.python.org  Thu Sep  5 16:39:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 14:39:27 +0000
Subject: [issue18878] Add support of the 'with' statement to sunau.open.
In-Reply-To: <1377805738.91.0.260228450439.issue18878@psf.upfronthosting.co.za>
Message-ID: <1378391967.83.0.813805479702.issue18878@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 16:39:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 14:39:54 +0000
Subject: [issue18830] Remove duplicates from a result of getclasstree()
In-Reply-To: <1377442213.69.0.00603799982208.issue18830@psf.upfronthosting.co.za>
Message-ID: <1378391994.64.0.955727488995.issue18830@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 16:45:15 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Sep 2013 14:45:15 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378392315.49.0.671108573365.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Same as fix_error_message_reader_csv_alternative_1_v4.patch (by Serhiy), but I removed unused variables in the test.

----------
Added file: http://bugs.python.org/file31614/fix_error_message_reader_csv_alternative_1_v5.patch

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

From report at bugs.python.org  Thu Sep  5 16:45:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 14:45:23 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <3cW4Sf36bSz7Ljn@mail.python.org>


Roundup Robot added the comment:

New changeset e81699a6390c by Serhiy Storchaka in branch 'default':
Issue #18922: Now The Lib/smtpd.py and Tools/i18n/msgfmt.py scripts write
http://hg.python.org/cpython/rev/e81699a6390c

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

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

From report at bugs.python.org  Thu Sep  5 16:47:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 14:47:29 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <1378392449.94.0.584870627257.issue18922@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Nicola and Berker.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 17:01:34 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 05 Sep 2013 15:01:34 +0000
Subject: [issue18933] Add link to source code in logging documentation
In-Reply-To: <1378390206.88.0.825858805448.issue18933@psf.upfronthosting.co.za>
Message-ID: <1378393294.26.0.903851038693.issue18933@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Why for the logging module in particular? This isn't the norm for stdlib packages, AFAIK.

The logging documentation (both tutorial and reference) is supposed to stand on its own, and in general I don't expect documentation users to (have to) look at the source to understand how to use logging.

If you think particular aspects of the documentation need clarifying, then please indicate what they are and suggest what sort of improvements you think are in order.

----------

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

From report at bugs.python.org  Thu Sep  5 17:05:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 15:05:40 +0000
Subject: [issue18672] Fix format specifiers for debug output in _sre.c
In-Reply-To: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>
Message-ID: <3cW4w31mw0z7Lkm@mail.python.org>


Roundup Robot added the comment:

New changeset 99310e5e1b1c by Serhiy Storchaka in branch '3.3':
Issue #18672: Fixed format specifiers for Py_ssize_t in debugging output in
http://hg.python.org/cpython/rev/99310e5e1b1c

New changeset c41c68a18bb6 by Serhiy Storchaka in branch 'default':
Issue #18672: Fixed format specifiers for Py_ssize_t in debugging output in
http://hg.python.org/cpython/rev/c41c68a18bb6

New changeset 603b4d593758 by Serhiy Storchaka in branch '2.7':
Issue #18672: Fixed format specifiers for Py_ssize_t in debugging output in
http://hg.python.org/cpython/rev/603b4d593758

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

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

From report at bugs.python.org  Thu Sep  5 17:24:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 15:24:58 +0000
Subject: [issue18672] Fix format specifiers for debug output in _sre.c
In-Reply-To: <1375805518.91.0.887667887132.issue18672@psf.upfronthosting.co.za>
Message-ID: <1378394698.15.0.713214911254.issue18672@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 17:34:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 15:34:48 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378395288.15.0.381712193632.issue18829@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I rather prefer adding new tests.

----------
Added file: http://bugs.python.org/file31615/fix_error_message_reader_csv_alternative_1_v6.patch

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

From report at bugs.python.org  Thu Sep  5 17:54:24 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 05 Sep 2013 15:54:24 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378332318.03.0.380952446091.issue18924@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_hc_2z9nm9=m8qsasx2UFs=LHvNmuQS1t=0AS8uOeigA@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Sep 4, 2013 at 3:05 PM, Ethan Furman <report at bugs.python.org> wrote:

>
> Ethan Furman added the comment:
>
> Yes, as a matter of fact:
>
> --> Test.this
> <Test.this: 'that'>
> --> Test.this = 'other'
> --> Test.this
> 'other'
> --> Test('that')
> <Test.this: 'that'>
> --> list(Test)
> [<Test.this: 'that'>]
>
> As you can see, the Test Enum becomes inconsistent if this is allowed.
>

Again, this is fully in accordance to the Python philosophy of allowing
monkey-patching in the first place. There's any number of way
monkey-patching objects can lead to inconsistent states, because the
internal invariants are only guaranteed to be preserved through public,
documented interfaces.

I'm still -1.

----------

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

From report at bugs.python.org  Thu Sep  5 17:57:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 05 Sep 2013 15:57:57 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <5227CFDA.2050801@rath.org>
Message-ID: <CAF-Rda-62NbYLVFx9KqNGFoPtdAkUbqmCLDwJQw-D9pfC16Dgg@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Sep 4, 2013 at 5:27 PM, Nikolaus Rath <report at bugs.python.org>wrote:

>
> Nikolaus Rath added the comment:
>
> On 09/04/2013 06:03 AM, Eli Bendersky wrote:
> > Why guess... did you try it in the code?
>
> I don't follow... why guess what? And try what in code?
>

I was referring to this part of the original report:

"""
This strongly suggests that the last-executed yield statement will raise an
exception if the generator is closed. If this is the case, it would be
great if the documentation could be extended to say what exception is
raised.

If this is not the case, it would be great if whatever magic is happening
could be documented as well.
"""

If this is the case, if this is not the case... I was just saying that you
can provide some sample code in the issue that demonstrates what *actually*
happens and whether it's not explained well enough in the documentation.

----------

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

From report at bugs.python.org  Thu Sep  5 18:42:34 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 16:42:34 +0000
Subject: [issue16853] add a Selector to the select module
In-Reply-To: <52288264.3030702@gmail.com>
Message-ID: <CAH_1eM0wg6=AbnnL19dJGZmzFBtmVYod1kseY7ipkaPuvXcW7Q@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Richard Oudkerk added the comment:
>
> Even with edge-triggered notification, doesn't registering an fd check
> the current readiness:

Hum...
Looks like I forgot to turn my brain on this morning :-)

----------

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

From report at bugs.python.org  Thu Sep  5 18:44:41 2013
From: report at bugs.python.org (Jonathan Frere)
Date: Thu, 05 Sep 2013 16:44:41 +0000
Subject: [issue18933] Add link to source code in logging documentation
In-Reply-To: <1378390206.88.0.825858805448.issue18933@psf.upfronthosting.co.za>
Message-ID: <1378399481.48.0.210289320453.issue18933@psf.upfronthosting.co.za>


Jonathan Frere added the comment:

Well, if all the modules could link back to source code, that would be ideal, it's just the logging happens to be the one that I keep coming back to.  Encouraging users to read the source will hopefully help people understand the modules they're using conceptually, and also give people more sample code to use.

That said, a number of modules link back to the source, particularly small single-file implementations of things, such as glob, fnmatch, string, pprint, repr, types, UserDict, weakref, Queue, sched, to name a few that I randomly opened.

Why logging in particular?  Well, as I said, I keep on coming back to it, so at least one Python user feels this need.  Secondly, it's a module that perhaps isn't quite as conceptually clear as others (hence the 'alternatives' that abound).  Thirdly, parts of the module such as logging.handlers will be directly used as templates by many developers.

----------

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

From report at bugs.python.org  Thu Sep  5 18:46:25 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 16:46:25 +0000
Subject: [issue18934] multiprocessing: use selectors module
Message-ID: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Here's a patch.

----------
components: Library (Lib)
files: selectors_multiprocessing.diff
keywords: needs review, patch
messages: 197012
nosy: neologix, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing: use selectors module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31616/selectors_multiprocessing.diff

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

From report at bugs.python.org  Thu Sep  5 18:59:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 16:59:58 +0000
Subject: [issue18935] test_regrtest.test_timeout failure
Message-ID: <1378400398.96.0.0580722992203.issue18935@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

http://buildbot.python.org/all/builders/AMD64 Fedora without threads 3.x/builds/5074/steps/test/logs/stdio
"""
======================================================================
FAIL: test_timeout (test.test_regrtest.ParseArgsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_regrtest.py", line 30, in test_timeout
    self.assertEqual(ns.timeout, 4.2)
AssertionError: None != 4.2
"""

That's because the "--timeout" isn't supported if Python is built --without-threads.

Possible patch attached.

----------
components: Tests
files: test_timeout.diff
keywords: needs review, patch
messages: 197013
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: test_regrtest.test_timeout failure
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31617/test_timeout.diff

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

From report at bugs.python.org  Thu Sep  5 19:21:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 17:21:09 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1378401669.79.0.393999058748.issue2259@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.0, Python 3.1

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

From report at bugs.python.org  Thu Sep  5 19:31:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 17:31:14 +0000
Subject: [issue1575020] Request wave support > 16 bit samples
Message-ID: <1378402274.21.0.229651482136.issue1575020@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  5 19:31:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 17:31:31 +0000
Subject: [issue1575020] Request wave support > 16 bit samples
Message-ID: <1378402291.6.0.935594127847.issue1575020@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep  5 19:43:51 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 05 Sep 2013 17:43:51 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <1378403030.99.0.344214691139.issue18934@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

LGTM.

But I would move "import selectors" in multiprocessing.connection to just before the definition of wait() for Unix.  It is not needed on Windows and unnecessary imports slow down start up of new processes.

----------

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

From report at bugs.python.org  Thu Sep  5 19:57:15 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 17:57:15 +0000
Subject: [issue18931] new selectors module should support devpoll on Solaris
In-Reply-To: <1378378715.64.0.328227872693.issue18931@psf.upfronthosting.co.za>
Message-ID: <1378403835.77.0.549286682527.issue18931@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Patch is in attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file31618/devpoll.patch

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

From report at bugs.python.org  Thu Sep  5 20:12:25 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 05 Sep 2013 18:12:25 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <1378404745.52.0.214601610219.issue18934@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Thu Sep  5 20:34:42 2013
From: report at bugs.python.org (Meador Inge)
Date: Thu, 05 Sep 2013 18:34:42 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378406082.33.0.00973210525882.issue18879@psf.upfronthosting.co.za>


Meador Inge added the comment:

The monkey-patched version breaks the auto-close on __del__ feature:

[meadori at li589-207 cpython]$ ./python 
Python 3.4.0a1+ (default:c41c68a18bb6, Sep  5 2013, 17:51:03) 
[GCC 4.7.2 20120921 (Red Hat 4.7.2-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.NamedTemporaryFile(dir=".",delete=False).write(b"hello")
__main__:1: ResourceWarning: unclosed file <_io.BufferedRandom name=4>
5

Also run the test suite with '-R :' and you will see tons of resource warnings.

Breaking auto-close is because now unlinking *and* closing are being guarded by 'delete'.  Even if that is fixed you still run into resource leak problems.  Looks like the monkey-patching introduces a reference cycle.

The wrapper binding approach works fine in all the tests I did.

----------

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

From report at bugs.python.org  Thu Sep  5 20:47:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 18:47:11 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <3cW9qf3yDVz7Lkb@mail.python.org>


Roundup Robot added the comment:

New changeset 81f0c6358a5f by Charles-Fran?ois Natali in branch 'default':
Issue #18934: multiprocessing: use selectors module.
http://hg.python.org/cpython/rev/81f0c6358a5f

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

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

From report at bugs.python.org  Thu Sep  5 21:36:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 19:36:00 +0000
Subject: [issue12866] Add support for 24-bit samples in the audioop module
In-Reply-To: <1314744712.67.0.770855933698.issue12866@psf.upfronthosting.co.za>
Message-ID: <1378409760.47.0.712037734341.issue12866@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately Peter's file is not ready for release. It adds support of 24-bit samples only to the part of functions, it works only on little-endian platform, it should crash on platforms which not allows non-aligned access, and I suspect it can overflow output buffers. And it doesn't provided in diff format.

Here is other patch which adds support for 24-bit samples. It also cleanup and simplify the code of audioop.c so that its total size is even decreased. Patch includes test and documentation changes.

----------
components: +Extension Modules
keywords: +patch
nosy: +r.david.murray
stage:  -> patch review
title: Want to submit our Audioop.c patch for 24bit audio -> Add support for 24-bit samples in the audioop module
Added file: http://bugs.python.org/file31619/audioop_24bit.patch

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

From report at bugs.python.org  Thu Sep  5 21:38:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 19:38:18 +0000
Subject: [issue2259] Poor support other than 44.1khz, 16bit audio files?
In-Reply-To: <1205075207.56.0.203597492215.issue2259@psf.upfronthosting.co.za>
Message-ID: <1378409898.33.0.0148074066887.issue2259@psf.upfronthosting.co.za>


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


----------
dependencies: +Add support for 24-bit samples in the audioop module

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

From report at bugs.python.org  Thu Sep  5 21:39:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 19:39:28 +0000
Subject: [issue1575020] Request wave support > 16 bit samples
Message-ID: <1378409968.2.0.578039156951.issue1575020@psf.upfronthosting.co.za>


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


----------
dependencies: +Add support for 24-bit samples in the audioop module

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

From report at bugs.python.org  Thu Sep  5 21:58:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Sep 2013 19:58:46 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1378411126.66.0.574492411353.issue18879@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The monkey-patched version breaks the auto-close on __del__ feature:

Files were closed. Just with a warning. I consider this as an enhancement. If you don't close file explicitly you will get a leak on non-refcounted Python implementations. It's true for both ordinal files so tempfiles. Perhaps we should add a warning in any __del__ method (even if we will commit Jakub's patch, this way LGTM too).

----------

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

From report at bugs.python.org  Thu Sep  5 22:03:08 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 05 Sep 2013 20:03:08 +0000
Subject: [issue18936] getopt chokes on unicode option names
Message-ID: <1378411388.86.0.748005801735.issue18936@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Today I encountered a bug where I was using a Distutils.Command subclass, which uses getopt for option parsing. The implementation is here: https://bitbucket.org/jaraco/jaraco.packaging/src/2.2/jaraco/packaging/depends.py?at=default

Around line 59, the options are defined, but because the syntax is Python 3 style with unicode literals, under Python 2.7, those get created as unicode objects.

When I invoke that Command under Python 2.7, I get this error:

Traceback (most recent call last):
  File "setup.py", line 160, in <module>
    setup(**setup_params)
  File "/usr/lib/python2.7/distutils/core.py", line 138, in setup
    ok = dist.parse_command_line()
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 250, in parse_command_line
  File "/usr/lib/python2.7/distutils/dist.py", line 467, in parse_command_line
    args = self._parse_command_opts(parser, args)
  File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 533, in _parse_command_opts
  File "/usr/lib/python2.7/distutils/dist.py", line 564, in _parse_command_opts
    (args, opts) = parser.getopt(args[1:])
  File "/usr/lib/python2.7/distutils/fancy_getopt.py", line 253, in getopt
    self._grok_option_table()
  File "/usr/lib/python2.7/distutils/fancy_getopt.py", line 171, in _grok_option_table
    "must be a string of length >= 2") % long
distutils.errors.DistutilsGetoptError: invalid long option 'requirement=': must be a string of length >= 2

That error is raised because 'requirement=' is a Unicode, but the test in fancy_getopt is isinstance(opt, str).

I can work around the issue by wrapping all of the options in str() calls, which leaves them unchanged on Python 3 and downcasts them to strings on Python 2, but that's not pretty.

I suggest that fancy_getopt should either include 'unicode' in the isinstance test or (if unicode values really aren't supported), encode unicode values first.

----------
components: Library (Lib)
messages: 197020
nosy: jason.coombs
priority: low
severity: normal
status: open
title: getopt chokes on unicode option names
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  5 22:17:44 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 05 Sep 2013 20:17:44 +0000
Subject: [issue18909] Segfaults on win-amd64 due to corrupt pointer to
 Tkapp_Interp
In-Reply-To: <1378171503.23.0.926493949821.issue18909@psf.upfronthosting.co.za>
Message-ID: <1378412264.94.0.39648163266.issue18909@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Sorry, of course I meant > 2**31. Thank you very much for your review!

----------

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

From report at bugs.python.org  Thu Sep  5 22:26:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Sep 2013 20:26:01 +0000
Subject: [issue18937] add unittest assertion for logging
Message-ID: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It is sometimes useful to check for the log messages emitted by some piece of code (especially a library). Would it be a good idea to add a dedicated assertion method for that? I would propose the following API:


with self.assertLogging("logger.name", level="WARN") as cm:
    ...

The `cm` context manager could give access to all the log records and formatted output lines for the given logger name (and children) and at least the given logging level. I have something like that here, except not with a dedicated assertion method:
https://bitbucket.org/optiflowsrd/obelus/src/c2a2f78068123264adde8cc3ece4889c61773f00/obelus/test/__init__.py?at=default#cl-20

----------
components: Library (Lib)
messages: 197022
nosy: ezio.melotti, michael.foord, pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: add unittest assertion for logging
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Sep  5 22:42:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Sep 2013 20:42:40 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378413760.62.0.649148279396.issue18937@psf.upfronthosting.co.za>


R. David Murray added the comment:

I have project in which that would be useful, so +1 from me for the general concept.

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

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

From report at bugs.python.org  Thu Sep  5 22:56:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Sep 2013 20:56:37 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378414597.93.0.961923473384.issue18924@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think Ethan has a point that the inconsistency when overriding a member can hide subtle bugs. I would agree with Eli and Eric if it wasn't for that problem. Also, we can first forbid overriding, then change our decision later on if someone comes with a use case (doing the converse would be more annoying as it would break compatibility).

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Sep  5 23:11:25 2013
From: report at bugs.python.org (Johnny Boy)
Date: Thu, 05 Sep 2013 21:11:25 +0000
Subject: [issue18938] Prepend Is Not A Word
Message-ID: <1378415485.5.0.896501812591.issue18938@psf.upfronthosting.co.za>


New submission from Johnny Boy:

If you do a custom install on Windows and click "Add python.exe to Path" the text below says "Prepend c:\Python33\ to the system Path variable"

Prepend is not a word!
The word you are looking for is Prefix.
http://encyclopedia2.thefreedictionary.com/prepend
"
Although it sounds correct, prepend is not an English word. It was created to sound like the opposite of "append," which means to add to the end. The correct English word is "prefix;"
"

----------
components: Installation
messages: 197025
nosy: opticyclic
priority: normal
severity: normal
status: open
title: Prepend Is Not A Word
versions: Python 3.3

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

From report at bugs.python.org  Thu Sep  5 23:15:05 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Sep 2013 21:15:05 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <3cW9qf3yDVz7Lkb@mail.python.org>
Message-ID: <CAH_1eM253ygoGcfg2rN0cRCcDRfmjAMaJncwMy7P2Wf_W0VOUg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

The test is failing on some (unstable) buildbots:
http://buildbot.python.org/all/builders/AMD64%20Solaris%2011%20%5BSB%5D%203.x/builds/1598/steps/test/logs/stdio
"""
======================================================================
FAIL: test_invalid_handles (test.test_multiprocessing_fork.TestInvalidHandle)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/test/_test_multiprocessing.py",
line 2962, in test_invalid_handles
    self.assertRaises((ValueError, OSError), conn.poll)
AssertionError: (<class 'ValueError'>, <class 'OSError'>) not raised by poll
"""

Basically, this test checks that calling poll() on an invalid
Connection (invalid FD) raises an OSError.
That's true for select, kqueue and epoll, but not for poll(), which
returns POLLNVAL.
I'm not sure about what to do here.

----------

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

From report at bugs.python.org  Thu Sep  5 23:15:10 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Sep 2013 21:15:10 +0000
Subject: [issue18938] Prepend Is Not A Word
In-Reply-To: <1378415485.5.0.896501812591.issue18938@psf.upfronthosting.co.za>
Message-ID: <1378415710.71.0.418894492352.issue18938@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

It is however a very common programming term.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Sep  5 23:38:37 2013
From: report at bugs.python.org (Graham Wideman)
Date: Thu, 05 Sep 2013 21:38:37 +0000
Subject: [issue18938] Prepend Is Not A Word
In-Reply-To: <1378415485.5.0.896501812591.issue18938@psf.upfronthosting.co.za>
Message-ID: <1378417117.36.0.933816913169.issue18938@psf.upfronthosting.co.za>


Graham Wideman added the comment:

"Prepend" appears in every online dictionary I consulted. For a dictionary to list it and give the usual meaning for it, pretty much demonstrates "prepend" functioning as a real word. That and its 1.3 million hits on google.

"Prepend" certainly has a commonly understood meaning, particularly in computing. 

To the extent that "prepend" has became popular as the appropriate-sounding opposite of "append", that is exactly why it _should_ be used in this context... where one might well need to discuss adding strings before or after, and be clear about the distinction.

----------
nosy: +gwideman

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

From report at bugs.python.org  Thu Sep  5 23:43:36 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 05 Sep 2013 21:43:36 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378417416.53.0.123668636054.issue18937@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I agree a context manager would be useful. Note that I have already provided a Handler subclass (TestHandler) as well as a Matcher class which allows matching of LogRecords, and which can be used in assertions. These are in test.support as they were originally intended for Python's own tests, but could be moved to the logging package if they are considered more generally useful.

See this for how to use them:

http://plumberjack.blogspot.co.uk/2010/09/unit-testing-and-logging.html

----------

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

From report at bugs.python.org  Fri Sep  6 00:02:40 2013
From: report at bugs.python.org (Graham Wideman)
Date: Thu, 05 Sep 2013 22:02:40 +0000
Subject: [issue18939] Venv docs regarding original python install
Message-ID: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>


New submission from Graham Wideman:

http://docs.python.org/dev/library/venv.html

More detail needed regarding the original python environment

The article explains how to use venv to create a new python installation with independent libraries etc, and a means to activate one or another virtual python environment. However, there are some points regarding the original python environment which are cloudy.

(1) After pyvenv, what status does the original python installation have? Does pyvenv turn it into just one of now two or more virtual environments? Or is the original one special? Must it be specifically deactivated in order to activate a (different) virtual environment?

(2) The motivation behind venv seems to be to create virtual enviroments that can be substantially or completely separate from the system site directories or from the original python that pyvenv was run from.  Yet elsewhere the doc discusses how  pyvenv creates a pyvenv.cfg file with a home key pointing back to the originating Python installation, and "sys.base_prefix and sys.base_exec_prefix point to the non-venv Python installation which was used to create the venv."... which suggest that a venv is _not_ independent of its creating Python installation.

It would be helpful to provide some context for this seemingly contradictory information.  Perhaps there are scenarios with differing degrees of independence, in which these pointers back to the originating Python installation may or may not be relevant?

(3) How do you proceed to create virtual environments from scratch when you have no initial python installation, or no python installation of that python version?

-- Hope these suggestions help.

----------
assignee: docs at python
components: Documentation
messages: 197030
nosy: docs at python, gwideman
priority: normal
severity: normal
status: open
title: Venv docs regarding original python install
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Sep  6 00:02:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Sep 2013 22:02:58 +0000
Subject: [issue18933] Add link to source code in logging documentation
In-Reply-To: <1378390206.88.0.825858805448.issue18933@psf.upfronthosting.co.za>
Message-ID: <3cWG9Y3pbkz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset dc4e6b48c321 by Vinay Sajip in branch '2.7':
Issue #18933: Added links to source code.
http://hg.python.org/cpython/rev/dc4e6b48c321

New changeset 34e515f2fdfe by Vinay Sajip in branch '3.3':
Issue #18933: Added links to source code.
http://hg.python.org/cpython/rev/34e515f2fdfe

New changeset c5924523747e by Vinay Sajip in branch 'default':
Closes #18933: Merged update from 3.3.
http://hg.python.org/cpython/rev/c5924523747e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 00:04:11 2013
From: report at bugs.python.org (Erik Bray)
Date: Thu, 05 Sep 2013 22:04:11 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1377796053.23.0.271574141063.issue18876@psf.upfronthosting.co.za>
Message-ID: <1378418651.25.0.71018645547.issue18876@psf.upfronthosting.co.za>


Erik Bray added the comment:

Thank you!  Has there been a separate issue opened for the BufferedWriter bug or can that be covered by this issue as well?

----------

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

From report at bugs.python.org  Fri Sep  6 00:08:59 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 05 Sep 2013 22:08:59 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <1378418939.36.0.644825845371.issue18934@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I remember wondering at one time why EPOLLNVAL did not exist, and realizing that closed fds are just silently unregistered by epoll().

I guess the issue is that some of the selectors indicate a bad fd on registration, and others do it when polled.

                On registration      On poll
----------------------------------------------------------------
SelectSelector  No                   Raises OSError
PollSelector    No                   No (EVENT_READ or EVENT_WRITE)
EpollSelector   Raises OSError       No
KqueueSelector  ?                    ?

It would be easiest to relax the test, perhaps by just checking that conn.poll(0) raises or returns True.

Or maybe PollSelector.select() should raise OSError if POLLNVAL is indicated.  That would match the behaviour of SelectSelector.select().

----------

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

From report at bugs.python.org  Fri Sep  6 00:16:17 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 05 Sep 2013 22:16:17 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378419377.33.0.584718969732.issue18937@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Whoops, meant to say "... moved to the unittest package ...".

----------

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

From report at bugs.python.org  Fri Sep  6 01:49:28 2013
From: report at bugs.python.org (Joshua Olson)
Date: Thu, 05 Sep 2013 23:49:28 +0000
Subject: [issue18940] TimedRotatingFileHandler fails to doRollover if a logger
 has delay=True and no logs in that time.
Message-ID: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>


New submission from Joshua Olson:

In TimedRotatingFileHandler if you have a low volume logger than hasn't written to the log within the interval time doRollover will fail because there is no file to rotate.

os.rename(self.baseFilename, dfn) 

should be something like

if os.path.exists(self.base_fileName):
    os.rename(self.baseFilename, dfn

I have included a unit test file.  This test fails on 2.7.1 and 2.7.3. I have not tried 2.7.5.

----------
components: Library (Lib)
files: logging_test.py
messages: 197035
nosy: solarmist
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler fails to doRollover if a logger has delay=True and no logs in that time.
versions: Python 2.7
Added file: http://bugs.python.org/file31620/logging_test.py

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

From report at bugs.python.org  Fri Sep  6 01:56:09 2013
From: report at bugs.python.org (Joshua Olson)
Date: Thu, 05 Sep 2013 23:56:09 +0000
Subject: [issue18941] RotatingFileHandler and TimedRotatingFileHandler do not
 respect delay on rollover
Message-ID: <1378425368.84.0.428778978895.issue18941@psf.upfronthosting.co.za>


New submission from Joshua Olson:

For low volume loggers RotatingFileHandler and TimedRotatingFileHandler will create possibly unnecessary files on doRollover, since they don't check the value of delay when opening the new self.stream.

self.stream = self._open()

should be something like

if not self.delay:
    self.stream = self._open()

----------
messages: 197036
nosy: solarmist
priority: normal
severity: normal
status: open
title: RotatingFileHandler and TimedRotatingFileHandler do not respect delay on rollover

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

From report at bugs.python.org  Fri Sep  6 02:02:30 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 06 Sep 2013 00:02:30 +0000
Subject: [issue18931] new selectors module should support devpoll on Solaris
In-Reply-To: <1378378715.64.0.328227872693.issue18931@psf.upfronthosting.co.za>
Message-ID: <1378425750.93.0.511437334652.issue18931@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Fri Sep  6 02:07:05 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Sep 2013 00:07:05 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378426025.13.0.859526095363.issue18929@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Another option with the global fix is to only add the metaclass to the mro if the metaclass is not 'type'.

----------

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

From report at bugs.python.org  Fri Sep  6 02:19:26 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 00:19:26 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378426766.78.0.328967780995.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

So you're not concerned about a now-private API (which used to be advertised), but are concerned about a user mucking with a new private lock in an exceedingly unlikely (in the absence of malice) way.  That clarifies things ;-)

I'm not really concerned about either.  User perversity knows no limits, though, so I wouldn't be surprised if some people are rolling their own higher-level threads in Python for reasons they think are compelling.

Details don't really matter to that, right?  Like:

> Also, how would they wait for the thread to end, except by
> triggering their own Event object?

Any number of ways.  Roll their own Event, roll their own Barrier, roll their own Condition, or even something as simple as keeping an integer count of the number of threads they created, and then (e.g.)

while nthreads:
    time.sleep(1)

at the end, with each thread doing a

    global nthreads
    with nthreads_lock:
        nthreads -= 1

in its end-of-life code.  Essentially rolling their own clumsy variant of a Semaphore.

I've seen code like that "in the wild".  But, no, I'll join you in not worrying about it ;-)

----------

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

From report at bugs.python.org  Fri Sep  6 02:46:02 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 00:46:02 +0000
Subject: [issue18940] TimedRotatingFileHandler fails to doRollover if a logger
 has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378428362.15.0.38207270954.issue18940@psf.upfronthosting.co.za>


Joshua Olson added the comment:

Here is a patch for the logging file from the cpython hg repo.

----------
keywords: +patch
Added file: http://bugs.python.org/file31621/doRollover.patch

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

From report at bugs.python.org  Fri Sep  6 02:47:48 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 00:47:48 +0000
Subject: [issue18940] TimedRotatingFileHandler fails to doRollover if a logger
 has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378428468.2.0.627177244957.issue18940@psf.upfronthosting.co.za>


Changes by Joshua Olson <joshua.olson at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Fri Sep  6 03:50:11 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 01:50:11 +0000
Subject: [issue18940] TimedRotatingFileHandler fails to doRollover if a logger
 has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378432211.65.0.0965587537225.issue18940@psf.upfronthosting.co.za>


Changes by Joshua Olson <joshua.olson at gmail.com>:


Removed file: http://bugs.python.org/file31621/doRollover.patch

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

From report at bugs.python.org  Fri Sep  6 03:50:18 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 01:50:18 +0000
Subject: [issue18940] TimedRotatingFileHandler fails to doRollover if a logger
 has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378432218.24.0.366435654652.issue18940@psf.upfronthosting.co.za>


Changes by Joshua Olson <joshua.olson at gmail.com>:


Removed file: http://bugs.python.org/file31620/logging_test.py

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

From report at bugs.python.org  Fri Sep  6 03:50:55 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Sep 2013 01:50:55 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378432255.62.0.590790449674.issue18924@psf.upfronthosting.co.za>


Eric Snow added the comment:

> I would agree with Eli and Eric if it wasn't for that problem.

Agreed.  That was the gist of my question that led to Ethan's example.  If it's easy to accidentally break an enum, particularly in a subtle way, then it may not be worth taking a consenting adults approach.

Usually in consenting adults cases, it's simply not worth adding the extra complexity (or taking the time) to lock down an API or cover all the cases--it won't be a problem in practice since normal usage doesn't bear enough risk to worry about it.

In the case of enums, particularly in how they re-purpose classes and yet allow non-item attributes, there's a higher risk of accidentally breaking something during normal usage.  They quack like a class, but maybe they need to look less like a duck.  The question is, is the risk (and associated cost) of accidental breakage high enough to warrant the cost of being more heavy-handed?

> Also, we can first forbid overriding, then change our decision later
> on if someone comes with a use case (doing the converse would be more
> annoying as it would break compatibility).

+1

----------

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

From report at bugs.python.org  Fri Sep  6 03:51:21 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 01:51:21 +0000
Subject: [issue18940] TimedRotatingFileHandler and RotatingFileHandler fail to
 doRollover if a logger has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378432281.27.0.409797023383.issue18940@psf.upfronthosting.co.za>


Joshua Olson added the comment:

This fixes the issue in both RotatingFilerHandler classes.

----------
title: TimedRotatingFileHandler fails to doRollover if a logger has delay=True and no logs in that time. -> TimedRotatingFileHandler and RotatingFileHandler fail to doRollover if a logger has delay=True and no logs in that time.
Added file: http://bugs.python.org/file31622/doRollover.patch

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

From report at bugs.python.org  Fri Sep  6 03:53:00 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 01:53:00 +0000
Subject: [issue18940] TimedRotatingFileHandler and RotatingFileHandler fail to
 doRollover if a logger has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378432380.87.0.686832433441.issue18940@psf.upfronthosting.co.za>


Changes by Joshua Olson <joshua.olson at gmail.com>:


Added file: http://bugs.python.org/file31623/logging_test.py

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

From report at bugs.python.org  Fri Sep  6 03:56:06 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 01:56:06 +0000
Subject: [issue18941] RotatingFileHandler and TimedRotatingFileHandler do not
 respect delay on rollover
In-Reply-To: <1378425368.84.0.428778978895.issue18941@psf.upfronthosting.co.za>
Message-ID: <1378432566.6.0.266707744224.issue18941@psf.upfronthosting.co.za>


Joshua Olson added the comment:

Demonstrate the bug

----------
Added file: http://bugs.python.org/file31624/logging_test.py

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

From report at bugs.python.org  Fri Sep  6 03:56:46 2013
From: report at bugs.python.org (Joshua Olson)
Date: Fri, 06 Sep 2013 01:56:46 +0000
Subject: [issue18941] RotatingFileHandler and TimedRotatingFileHandler do not
 respect delay on rollover
In-Reply-To: <1378425368.84.0.428778978895.issue18941@psf.upfronthosting.co.za>
Message-ID: <1378432606.45.0.805007272645.issue18941@psf.upfronthosting.co.za>


Joshua Olson added the comment:

If delay is set then don't automatically open the new file.

----------
keywords: +patch
Added file: http://bugs.python.org/file31625/delay_rollover.patch

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

From report at bugs.python.org  Fri Sep  6 04:02:58 2013
From: report at bugs.python.org (Graham Wideman)
Date: Fri, 06 Sep 2013 02:02:58 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <1378432978.72.0.412156225351.issue18939@psf.upfronthosting.co.za>


Graham Wideman added the comment:

Additionally on the subject of venv docs:  I would encourage making it more clear regarding how activate changes the user's PATH. Both http://www.python.org/dev/peps/pep-0405/  and http://docs.python.org/3.3/library/venv.html  talk about how activate adds the activated python binary to the path, but doesn't mention what path:  The one for the current console session? The system PATH environment variable (Windows) or one of the bash startup scripts (unix)? This is important, because it determines how far-reaching is activation of a particular virtual environment.

----------

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

From report at bugs.python.org  Fri Sep  6 04:39:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 02:39:59 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <1378435199.39.0.513955602251.issue18939@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  It seems to me that that document is indeed not clear as to what is really going on.  My understanding has always been that there is only one Python interpreter, but that it behaves differently when invoked through the symlink in the venv.  I suppose that on Windows platforms where symlink isn't available it must actually copy the whole binary, but I don't use Windows so I don't know for sure.  (So, to answer one of your questions, you *can't* create a venv for a Python you don't already have installed.)

It should also mention that the activation is per-shell-session, which would answer some of your other questions.

----------
nosy: +r.david.murray, vinay.sajip

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

From report at bugs.python.org  Fri Sep  6 04:42:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 02:42:09 +0000
Subject: [issue18940] TimedRotatingFileHandler and RotatingFileHandler fail to
 doRollover if a logger has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <1378435329.68.0.254362478575.issue18940@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Fri Sep  6 04:43:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 02:43:00 +0000
Subject: [issue18941] RotatingFileHandler and TimedRotatingFileHandler do not
 respect delay on rollover
In-Reply-To: <1378425368.84.0.428778978895.issue18941@psf.upfronthosting.co.za>
Message-ID: <1378435380.04.0.549014806194.issue18941@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Fri Sep  6 04:48:48 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Sep 2013 02:48:48 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378435728.57.0.984351102215.issue18924@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Heavy-handed would be having the metaclass turn all the enum members into read-only properties.  The solution I have proposed is more like a wagging of one's finger saying, "No, no, that's not the right way!"  ;)

----------

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

From report at bugs.python.org  Fri Sep  6 05:07:27 2013
From: report at bugs.python.org (Graham Wideman)
Date: Fri, 06 Sep 2013 03:07:27 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <1378436847.67.0.425426260956.issue18939@psf.upfronthosting.co.za>


Graham Wideman added the comment:

Thanks R. David for your comments.

> It should also mention that the activation is per-shell-session,

.. which also has implications (or lack of effect) for launching from Windows Explorer, for example.

Seems like in practical use, one would need to set up a batch file or shell script to run a particular venv activate command and launch a command shell with that python environment already set up. "Shell for python 2.7.5 and library XYZ" etc.

Advice along these lines would be helpful.

----------

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

From report at bugs.python.org  Fri Sep  6 05:46:24 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 03:46:24 +0000
Subject: [issue18942] _debugmallocstats() gibberish output on Windows
Message-ID: <1378439184.72.0.614374936253.issue18942@psf.upfronthosting.co.za>


New submission from Tim Peters:

On Windows, _debugmallocstats() output ends with lines like this:

  0 free 12-sized PyTupleObjects * zd bytes each =                    0
  0 free 13-sized PyTupleObjects * zd bytes each =                    0

"zd" is senseless.  Betting it's due to using a %zd format code, which MS doesn't support (but Python itself supports in other printf-like functions, like PyErr_Format()).  I'll track it down and fix it :-)

----------
assignee: tim.peters
messages: 197048
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: _debugmallocstats() gibberish output on Windows
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep  6 06:11:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 04:11:26 +0000
Subject: [issue18942] _debugmallocstats() gibberish output on Windows
In-Reply-To: <1378439184.72.0.614374936253.issue18942@psf.upfronthosting.co.za>
Message-ID: <3cWQLk0vKtzNtB@mail.python.org>


Roundup Robot added the comment:

New changeset d95cc29ea94e by Tim Peters in branch '3.3':
Issue #18942: sys._debugmallocstats() output was damaged on Windows.
http://hg.python.org/cpython/rev/d95cc29ea94e

New changeset 43f772554872 by Tim Peters in branch 'default':
Nerge 3.3 into default.
http://hg.python.org/cpython/rev/43f772554872

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

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

From report at bugs.python.org  Fri Sep  6 06:13:17 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 04:13:17 +0000
Subject: [issue18942] _debugmallocstats() gibberish output on Windows
In-Reply-To: <1378439184.72.0.614374936253.issue18942@psf.upfronthosting.co.za>
Message-ID: <1378440797.39.0.303277705385.issue18942@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 06:44:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 04:44:01 +0000
Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
In-Reply-To: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>
Message-ID: <3cWR4K1KTmz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 975d1e180689 by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/975d1e180689

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

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

From report at bugs.python.org  Fri Sep  6 06:46:21 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 06 Sep 2013 04:46:21 +0000
Subject: [issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
In-Reply-To: <1342263934.43.0.385544849615.issue15350@psf.upfronthosting.co.za>
Message-ID: <1378442781.26.0.793993518964.issue15350@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed in 3.3 and cpython. 3.2 is security fix mode and patches are not backported. This does not apply to 2.7. Thanks for the patch.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Sep  6 08:31:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 06:31:48 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1378426766.78.0.328967780995.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378449102.2487.4.camel@fsol>


Antoine Pitrou added the comment:

Le vendredi 06 septembre 2013 ? 00:19 +0000, Tim Peters a ?crit :
> Tim Peters added the comment:
> 
> So you're not concerned about a now-private API (which used to be
> advertised), but are concerned about a user mucking with a new private
> lock in an exceedingly unlikely (in the absence of malice) way.  That
> clarifies things ;-)

:-)
The only reason I'm concerned about the user mucking with the private
lock is that it's a new opportunity that's opened. But, yeah, I could
remove the weakref and only keep the lock. The code would only be ~10
lines shorter, though. What do other people think?

> in its end-of-life code.  Essentially rolling their own clumsy variant
> of a Semaphore.

I guess they spell it like:

  import clumsy_threading as threading

> I've seen code like that "in the wild".

Well, I've sure seen my share of sleep() calls as a synchronization
measure too (and removed a number of them)... :-)
That's one of the reasons I added the timeout arguments, actually.

----------

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

From report at bugs.python.org  Fri Sep  6 08:57:40 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Sep 2013 06:57:40 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378418939.36.0.644825845371.issue18934@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3dEZ9YhrFWmojW2L=xMp5Gq1OHZZDk_Bd_g5MEbrcdHA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Richard Oudkerk added the comment:
>
> I remember wondering at one time why EPOLLNVAL did not exist, and realizing that closed fds are just silently unregistered by epoll().

Exactly.

> I guess the issue is that some of the selectors indicate a bad fd on registration, and others do it when polled.
>
>                 On registration      On poll
> ----------------------------------------------------------------
> SelectSelector  No                   Raises OSError
> PollSelector    No                   No (EVENT_READ or EVENT_WRITE)
> EpollSelector   Raises OSError       No
> KqueueSelector  ?                    ?

Kqueue raises OSError upon registration. Not sure about poll().

> It would be easiest to relax the test, perhaps by just checking that conn.poll(0) raises or returns True.

That's what I think too. Apparently, the test was added for this
issue: http://bugs.python.org/issue3321

Basically, the goal was to check that conn.poll() wouldn't crash if
passed an invalid FD (which can happen if you register a FD greater
than FD_SETSIZE in a fd_set).
So relaxing the check would still make sense.

> Or maybe PollSelector.select() should raise OSError if POLLNVAL is indicated.  That would match the behaviour of SelectSelector.select().

Yes, that would be a possibility. I'll have to give it some more thought.

----------

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

From report at bugs.python.org  Fri Sep  6 10:08:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 08:08:09 +0000
Subject: [issue1584] Mac OS X: building with X11 Tkinter
In-Reply-To: <1197345898.75.0.132866639605.issue1584@psf.upfronthosting.co.za>
Message-ID: <3cWWbr4SXDz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 0986e4f5750d by Ned Deily in branch 'default':
Issue #1584: Provide options to override default search paths for Tcl and Tk
http://hg.python.org/cpython/rev/0986e4f5750d

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

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

From report at bugs.python.org  Fri Sep  6 10:22:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 08:22:04 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <3cWWvw11Vgz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 985384cd6365 by Ned Deily in branch 'default':
Issue #15663: Tcl/Tk 8.5.14 is now included with the OS X 10.6+
http://hg.python.org/cpython/rev/985384cd6365

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

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

From report at bugs.python.org  Fri Sep  6 10:25:54 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 Sep 2013 08:25:54 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <1378455954.45.0.98889043284.issue18939@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

The venv documentation does assume that the reader knows what virtual environments are and how they work. More details are available in PEP 405, which is not referenced in this documentation - I will rectify that.

----------

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

From report at bugs.python.org  Fri Sep  6 10:36:11 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 06 Sep 2013 08:36:11 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1378456571.85.0.453997601461.issue15663@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
dependencies: +Mac OS X: building with X11 Tkinter

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

From report at bugs.python.org  Fri Sep  6 10:51:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 08:51:55 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <3cWXZL4d8Pz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset ad09332f856f by Vinay Sajip in branch '3.3':
Issue #18939: Updated venv documentation with some clarifications.
http://hg.python.org/cpython/rev/ad09332f856f

New changeset 408b6b3dcf9a by Vinay Sajip in branch 'default':
Closes #18939: Merged documentation update from 3.3.
http://hg.python.org/cpython/rev/408b6b3dcf9a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 11:00:02 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 09:00:02 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
Message-ID: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>


New submission from Armin Rigo:

In argparse, default arguments have a strange behavior that shows up in mutually exclusive groups: specifying explicitly on the command-line an argument, but giving it its default value, is sometimes equivalent to not specifying the argument at all, and sometimes not.

See the attached test diff: it contains two apparently equivalent pieces of code, but one passes and one fails.  The difference is that, in CPython, int("42") is 42 but int("4200") is not 4200 (in the sense of the operator "is").

The line that uses "is" in this way is this line in argparse.py (line 1783 in 2.7 head):

            if argument_values is not action.default:

----------
files: test_argparse.diff
keywords: patch
messages: 197058
nosy: arigo
priority: normal
severity: normal
status: open
title: argparse: default args in mutually exclusive groups
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file31626/test_argparse.diff

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

From report at bugs.python.org  Fri Sep  6 11:01:37 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 09:01:37 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378458097.23.0.519627571524.issue18943@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
keywords:  -patch

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

From report at bugs.python.org  Fri Sep  6 11:11:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 09:11:50 +0000
Subject: [issue18940] TimedRotatingFileHandler and RotatingFileHandler fail to
 doRollover if a logger has delay=True and no logs in that time.
In-Reply-To: <1378424967.99.0.0736879617379.issue18940@psf.upfronthosting.co.za>
Message-ID: <3cWY1L1JKtz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 6a591870017c by Vinay Sajip in branch '2.7':
Issue #18940: Handled low-volume logging when delay is True.
http://hg.python.org/cpython/rev/6a591870017c

New changeset 324774a59256 by Vinay Sajip in branch '3.3':
Issue #18940: Handled low-volume logging when delay is True.
http://hg.python.org/cpython/rev/324774a59256

New changeset 8002aee72837 by Vinay Sajip in branch 'default':
Closes #18940: Merged fix from 3.3.
http://hg.python.org/cpython/rev/8002aee72837

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 11:12:01 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 09:12:01 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378458721.9.0.935337474484.issue18943@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
components: +Library (Lib)

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

From report at bugs.python.org  Fri Sep  6 11:12:51 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 09:12:51 +0000
Subject: [issue18944] Minor mistake in test_set.py
Message-ID: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>


New submission from Armin Rigo:

Found a minor mistake in test_set.py.  Patch attached.

----------
components: Interpreter Core
files: test_set.diff
keywords: patch
messages: 197060
nosy: arigo
priority: normal
severity: normal
status: open
title: Minor mistake in test_set.py
versions: Python 3.5
Added file: http://bugs.python.org/file31627/test_set.diff

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

From report at bugs.python.org  Fri Sep  6 11:27:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 09:27:03 +0000
Subject: [issue18941] RotatingFileHandler and TimedRotatingFileHandler do not
 respect delay on rollover
In-Reply-To: <1378425368.84.0.428778978895.issue18941@psf.upfronthosting.co.za>
Message-ID: <3cWYLt3Nk6z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 4d45f1ed1179 by Vinay Sajip in branch '2.7':
Issue #18941: Respected delay when doing rollover.
http://hg.python.org/cpython/rev/4d45f1ed1179

New changeset 0577c9a82c0a by Vinay Sajip in branch '3.3':
Issue #18941: Respected delay when doing rollover.
http://hg.python.org/cpython/rev/0577c9a82c0a

New changeset 7627fea85a6d by Vinay Sajip in branch 'default':
Closes #18941: Merged fix from 3.3.
http://hg.python.org/cpython/rev/7627fea85a6d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 11:34:12 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Fri, 06 Sep 2013 09:34:12 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
Message-ID: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>


New submission from Vlad Shcherbina:

I intend to add test for (existing dir)-(new file) collision in http://bugs.python.org/issue18849, but file-file, file-dir and dir-dir collisions are yet to be covered.

----------
components: Tests
messages: 197062
nosy: vlad
priority: normal
severity: normal
status: open
title: Name collision handling in tempfile is not covered by tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Sep  6 13:58:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 11:58:52 +0000
Subject: [issue18876] Problems with files opened in append mode with io module
In-Reply-To: <1378418651.25.0.71018645547.issue18876@psf.upfronthosting.co.za>
Message-ID: <985449185.41369533.1378468726108.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Erik Bray added the comment:
> 
> Thank you!  Has there been a separate issue opened for the
> BufferedWriter bug or can that be covered by this issue as well?

No other issue has been opened as I know of, but indeed it would be
clearer to open a separate one.

----------

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

From report at bugs.python.org  Fri Sep  6 14:51:00 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 Sep 2013 12:51:00 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1378471860.64.0.829056796895.issue15663@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Great work. Thanks.

----------

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

From report at bugs.python.org  Fri Sep  6 15:14:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 13:14:56 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <3cWfPq6Wpmz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 7611e7244bdd by Eli Bendersky in branch '3.3':
Issue #18849: Fixed a Windows-specific tempfile bug where collision with an
http://hg.python.org/cpython/rev/7611e7244bdd

New changeset 035b61b52caa by Eli Bendersky in branch 'default':
Issue #18849: Fixed a Windows-specific tempfile bug where collision with an
http://hg.python.org/cpython/rev/035b61b52caa

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

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

From report at bugs.python.org  Fri Sep  6 15:17:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 13:17:55 +0000
Subject: [issue18849] Failure to try another name for tempfile when directory
 with chosen name exists on windows
In-Reply-To: <1377593921.13.0.684885433639.issue18849@psf.upfronthosting.co.za>
Message-ID: <3cWfTH04Csz7Lk2@mail.python.org>


Roundup Robot added the comment:

New changeset e0037f266d45 by Eli Bendersky in branch '2.7':
Close #18849: Fixed a Windows-specific tempfile bug where collision with an
http://hg.python.org/cpython/rev/e0037f266d45

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 15:33:46 2013
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 06 Sep 2013 13:33:46 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1378474426.66.0.578833994216.issue18852@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I suggest to remove the comment part from the patch and then apply it.

----------

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

From report at bugs.python.org  Fri Sep  6 15:49:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 13:49:54 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <3cWgBB1hzyz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset ec9a4b77f37b by Eli Bendersky in branch 'default':
Issue #18920: argparse's default version action (for -v, --version) should
http://hg.python.org/cpython/rev/ec9a4b77f37b

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

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

From report at bugs.python.org  Fri Sep  6 15:50:24 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Sep 2013 13:50:24 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378475424.58.0.263424214514.issue18920@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks, I moved the NEWS entry to the right place. Yes, all tests pass. I'll update whatsnew separately.

----------

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

From report at bugs.python.org  Fri Sep  6 15:56:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 13:56:37 +0000
Subject: [issue18922] Output versions of scripts to stdout
In-Reply-To: <1378306168.12.0.839885180116.issue18922@psf.upfronthosting.co.za>
Message-ID: <3cWgKw6XWLz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 587bdb940524 by Eli Bendersky in branch 'default':
Update whatsnew/3.4 wrt. --version going to stdout. #18338, #18920, #18922
http://hg.python.org/cpython/rev/587bdb940524

----------

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

From report at bugs.python.org  Fri Sep  6 15:56:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 13:56:38 +0000
Subject: [issue18338] python --version should send output to STDOUT
In-Reply-To: <1372676487.3.0.302989276182.issue18338@psf.upfronthosting.co.za>
Message-ID: <3cWgKx4lQ7z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 587bdb940524 by Eli Bendersky in branch 'default':
Update whatsnew/3.4 wrt. --version going to stdout. #18338, #18920, #18922
http://hg.python.org/cpython/rev/587bdb940524

----------

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

From report at bugs.python.org  Fri Sep  6 15:56:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 13:56:39 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <3cWgKy311yz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 587bdb940524 by Eli Bendersky in branch 'default':
Update whatsnew/3.4 wrt. --version going to stdout. #18338, #18920, #18922
http://hg.python.org/cpython/rev/587bdb940524

----------

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

From report at bugs.python.org  Fri Sep  6 15:57:07 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Sep 2013 13:57:07 +0000
Subject: [issue18920] argparse module version action
In-Reply-To: <1378297847.46.0.268237187871.issue18920@psf.upfronthosting.co.za>
Message-ID: <1378475827.11.0.275931173879.issue18920@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.4

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

From report at bugs.python.org  Fri Sep  6 16:02:13 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Fri, 06 Sep 2013 14:02:13 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1378476133.34.0.388969735708.issue917120@psf.upfronthosting.co.za>


Changes by Dani?l van Eeden <launchpad at myname.nl>:


----------
nosy: +dveeden

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

From report at bugs.python.org  Fri Sep  6 16:13:35 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Sep 2013 14:13:35 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <1378476815.53.0.380323526128.issue18924@psf.upfronthosting.co.za>


Ethan Furman added the comment:

In retrospect the read-only properties would not be any more difficult to get around than the __setattr__ solution, and it would conflict with our use of _RouteClassAttributeToGetattr.

To properly replace an enum member one has to change two internal data structures:

    _member_map_      -> 'enum_name' : member
    _member2value_map -> enum_value  : member   # if hashable

To actually create a real (non-mock) member is even more work.

----------

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

From report at bugs.python.org  Fri Sep  6 16:17:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 14:17:19 +0000
Subject: [issue18924] Enum members are easily replaced
In-Reply-To: <1378324047.44.0.111510450424.issue18924@psf.upfronthosting.co.za>
Message-ID: <3cWgnp264zz7Lkj@mail.python.org>


Roundup Robot added the comment:

New changeset 1d88d04aade2 by Ethan Furman in branch 'default':
Close #18924:  Block naive attempts to change an Enum member.
http://hg.python.org/cpython/rev/1d88d04aade2

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 16:20:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Sep 2013 14:20:34 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378477234.25.0.260409644476.issue18945@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Fri Sep  6 16:57:13 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 14:57:13 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378479433.92.0.994881181732.issue16938@psf.upfronthosting.co.za>


Armin Rigo added the comment:

I believe that this describes a problem more general than the problem of Enums from Issue18693: help(x) shouldn't crash in the presence of a __dir__() method that returns unexpected names.

----------
nosy: +arigo

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

From report at bugs.python.org  Fri Sep  6 17:04:10 2013
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Sep 2013 15:04:10 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
 VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1378479850.84.0.769306756548.issue7511@psf.upfronthosting.co.za>


Steve Dower added the comment:

I believe that is all that is missing from the patches I posted, though I'd have thought that having Visual C++ 2010 Express installed would be sufficient without the patch (though you didn't mention C++, so maybe you have a different one?).

----------

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

From report at bugs.python.org  Fri Sep  6 18:10:43 2013
From: report at bugs.python.org (James Lu)
Date: Fri, 06 Sep 2013 16:10:43 +0000
Subject: [issue18946] HTMLParser should ignore errors when parsing text in
 <script> tags
Message-ID: <1378483843.82.0.705841583098.issue18946@psf.upfronthosting.co.za>


New submission from James Lu:

It will show invalid html inside of script tags, for example, at the learners dictionary:
	function output_creative (id)
		{	document.write
				("<div id='" + id + "'>" + 
					"<scr" + "ipt type='text/javascript'>\r\n" + 
					"googletag.cmd.push(function() { googletag.display('" + id + "'); });\r\n" +
					"</sc" + "ript>" + invalid end tag
					"</div>");
		};
it thinks </sc" + "ript"> is an actual end tag.

----------
messages: 197077
nosy: James.Lu
priority: normal
severity: normal
status: open
title: HTMLParser should ignore errors when parsing text in <script> tags

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

From report at bugs.python.org  Fri Sep  6 18:29:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Sep 2013 16:29:27 +0000
Subject: [issue18946] HTMLParser should ignore errors when parsing text in
 <script> tags
In-Reply-To: <1378483843.82.0.705841583098.issue18946@psf.upfronthosting.co.za>
Message-ID: <1378484967.01.0.189527256086.issue18946@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What version of Python are you using?

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

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

From report at bugs.python.org  Fri Sep  6 18:31:27 2013
From: report at bugs.python.org (James Lu)
Date: Fri, 06 Sep 2013 16:31:27 +0000
Subject: [issue18946] HTMLParser should ignore errors when parsing text in
 <script> tags
In-Reply-To: <1378484967.01.0.189527256086.issue18946@psf.upfronthosting.co.za>
Message-ID: <CANQHGB3Odo-jDVYTn-LQMtrNYT0=Tqn5A7mQLVxLitE91aHBYw@mail.gmail.com>


James Lu added the comment:

2.5, but I don't think the library has changed since.

james

On Fri, Sep 6, 2013 at 12:29 PM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti added the comment:
>
> What version of Python are you using?
>
> ----------
> nosy: +ezio.melotti
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18946>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Sep  6 18:33:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Sep 2013 16:33:22 +0000
Subject: [issue18946] HTMLParser should ignore errors when parsing text in
 <script> tags
In-Reply-To: <1378483843.82.0.705841583098.issue18946@psf.upfronthosting.co.za>
Message-ID: <1378485202.02.0.83077700396.issue18946@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This should be fixed in 2.7 and 3.2+.
Try with a more recent version of Python and if you still have problems feel free to reopen the issue.

----------
components: +Library (Lib)
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Sep  6 18:57:02 2013
From: report at bugs.python.org (Sergey Vishnikin)
Date: Fri, 06 Sep 2013 16:57:02 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378486622.88.0.824642135648.issue18873@psf.upfronthosting.co.za>


Sergey Vishnikin added the comment:

-cookie_re = re.compile("coding[:=]\s*([-\w.]+)")
+cookie_re = re.compile("#[^\r\n]*coding[:=]\s*([-\w.]+)")

Regex matches only if the encoding expression is preceded by a comment.

----------
keywords: +patch
nosy: +armicron
Added file: http://bugs.python.org/file31628/tokenizer.patch

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

From report at bugs.python.org  Fri Sep  6 19:09:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 17:09:14 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <3cWlc943TGz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset 3070fdd58645 by R David Murray in branch 'default':
#18852: Handle readline.__doc__ being None in site.py readline activation.
http://hg.python.org/cpython/rev/3070fdd58645

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

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

From report at bugs.python.org  Fri Sep  6 19:10:15 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 17:10:15 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1378487415.41.0.818861094555.issue18852@psf.upfronthosting.co.za>


R. David Murray added the comment:

Done.  Thanks, Berker.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Sep  6 19:10:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 17:10:31 +0000
Subject: [issue18852] site.py does not handle readline.__doc__ being None
In-Reply-To: <1377609308.01.0.92318264163.issue18852@psf.upfronthosting.co.za>
Message-ID: <1378487431.31.0.839334072319.issue18852@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks David! I had forgotten about the issue.

----------

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

From report at bugs.python.org  Fri Sep  6 20:14:05 2013
From: report at bugs.python.org (Mikael Ryding)
Date: Fri, 06 Sep 2013 18:14:05 +0000
Subject: [issue18947] Bug in module netaddr
Message-ID: <1378491245.37.0.748278475446.issue18947@psf.upfronthosting.co.za>


New submission from Mikael Ryding:

I found this in the netaddr module when I was trying to get the CIDR from a number of ip/netmask combinations. The expected cidr in the example below should be: 192.1.0.0/23.

>>> ip = netaddr.IPNetwork("192.1.1.128", "255.255.254.0")
>>> ip.netmask
IPAddress('255.255.255.0')
>>> ip.cidr
IPNetwork('192.1.1.0/24')

----------
messages: 197085
nosy: mryding
priority: normal
severity: normal
status: open
title: Bug in module netaddr
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep  6 20:42:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 18:42:40 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1378492960.58.0.011500058474.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Is there anything else that this patch should address?

I hoped Charles-Fran?ois would answer this one, but no, I don't think there's anything left :)
Next step (for another issue perhaps) is to actually re-use this context manager in the other tests which deliberately crash the interpreter.

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

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

From report at bugs.python.org  Fri Sep  6 20:50:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 18:50:12 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <3cWnrg3n2Cz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 28a1843c0fc1 by Antoine Pitrou in branch 'default':
Issue #18623: Factor out the _SuppressCoreFiles context manager into test.support.
http://hg.python.org/cpython/rev/28a1843c0fc1

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

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

From report at bugs.python.org  Fri Sep  6 20:50:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 18:50:52 +0000
Subject: [issue18947] Bug in module netaddr
In-Reply-To: <1378491245.37.0.748278475446.issue18947@psf.upfronthosting.co.za>
Message-ID: <1378493452.27.0.59134099661.issue18947@psf.upfronthosting.co.za>


R. David Murray added the comment:

Netaddr is not an stdlib module.  Please report the bug to the netaddr maintainers.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions: +3rd party -Python 2.7

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

From report at bugs.python.org  Fri Sep  6 20:51:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 18:51:01 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1378493461.41.0.761665342212.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Patch committed, thanks!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 20:56:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 18:56:05 +0000
Subject: [issue18948] deliberately crashing tests should prevent core dumps
Message-ID: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a (exhaustive?) list of tests which deliberately crash the interpreter:
- test_daemon_threads_fatal_error() in test_threading
- several fatal error tests in test_faulthandler
- test_recursionlimit_fatalerror() in test_sys
- test_no_FatalError_infinite_loop() in test_capi

They should reuse the new SuppressCoreFiles facility from test.support.

----------
components: Tests
keywords: easy
messages: 197090
nosy: lambertv, neologix, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: deliberately crashing tests should prevent core dumps
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep  6 20:59:45 2013
From: report at bugs.python.org (Wilberto Morales)
Date: Fri, 06 Sep 2013 18:59:45 +0000
Subject: [issue18949] codeop possible flow erro
Message-ID: <1378493985.89.0.543332382387.issue18949@psf.upfronthosting.co.za>


New submission from Wilberto Morales:

I think the way this loop in /Lib/codeop.py is wrong

def _maybe_compile(compiler, source, filename, symbol):
    # Check for source consisting of only blank lines and comments
    for line in source.split("\n"):
        line = line.strip()
        if line and line[0] != '#':
            break               # Leave it alone
    else:
        if symbol != "eval":
            source = "pass"     # Replace it with a 'pass' statement

I think the else statement shouldn't be there.

----------
messages: 197091
nosy: Wilberto
priority: normal
severity: normal
status: open
title: codeop possible flow erro
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep  6 21:01:01 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Sep 2013 19:01:01 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <CAH_1eM3dEZ9YhrFWmojW2L=xMp5Gq1OHZZDk_Bd_g5MEbrcdHA@mail.gmail.com>
Message-ID: <CAH_1eM11fdekYtpqtS484rcgrOebrER1TP4vnoPQbrNGReup_w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I just realized that using DefaultSelector isn't optimal for Connection:
It's fine for forkserver, since it's a long lived process, but for
Connection.poll(), this means that it'll use epoll or kqueue: which
means allocating a new epoll/kqueue object for each conn.poll().
That's a couple syscalls more (epoll_create()/epoll_ctl()/close()),
but most important it uses an extra FD per connection.

The attached patch uses PollSelector if available, otherwise SelectSelector.

----------
Added file: http://bugs.python.org/file31629/connection_selector.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18934>
_______________________________________
-------------- next part --------------
diff -r 3070fdd58645 Lib/multiprocessing/connection.py
--- a/Lib/multiprocessing/connection.py	Fri Sep 06 13:08:08 2013 -0400
+++ b/Lib/multiprocessing/connection.py	Fri Sep 06 20:45:04 2013 +0200
@@ -878,13 +878,21 @@
 
     import selectors
 
+    # poll/select have the advantage of not requiring any extra file
+    # descriptor, contrarily to epoll/kqueue. Also, they're a bit faster for
+    # short-lived polling, since they require a single syscall.
+    if hasattr(selectors, 'PollSelector'):
+        _WaitSelector = selectors.PollSelector
+    else:
+        _WaitSelector = selectors.SelectSelector
+
     def wait(object_list, timeout=None):
         '''
         Wait till an object in object_list is ready/readable.
 
         Returns list of those objects in object_list which are ready/readable.
         '''
-        with selectors.DefaultSelector() as selector:
+        with _WaitSelector() as selector:
             for obj in object_list:
                 selector.register(obj, selectors.EVENT_READ)
 

From report at bugs.python.org  Fri Sep  6 21:06:11 2013
From: report at bugs.python.org (Wilberto Morales)
Date: Fri, 06 Sep 2013 19:06:11 +0000
Subject: [issue18949] codeop possible flow error
In-Reply-To: <1378493985.89.0.543332382387.issue18949@psf.upfronthosting.co.za>
Message-ID: <1378494371.17.0.0852082470846.issue18949@psf.upfronthosting.co.za>


Changes by Wilberto Morales <wilbertomorales777 at gmail.com>:


----------
title: codeop possible flow erro -> codeop possible flow error

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

From report at bugs.python.org  Fri Sep  6 21:06:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Sep 2013 19:06:54 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1378492960.58.0.011500058474.issue18623@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1LuNNwADTd5EdgtUPit7U2KoBiYcQSBuPhfGqTfQ4qfQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>> Is there anything else that this patch should address?
>
> I hoped Charles-Fran?ois would answer this one, but no, I don't think there's anything left :)

Sorry, I had completely forgotten this issue.

The only comment I have is this:

class SuppressCoreFiles(object):

The explicit 'object' superclass is old-school ;-)

----------

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

From report at bugs.python.org  Fri Sep  6 21:07:41 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Sep 2013 19:07:41 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
In-Reply-To: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>
Message-ID: <1378494461.32.0.279410879968.issue18903@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This strikes me a sort-of a bug.  However, feature vs. bug does not matter for small changes (see PEP434).  Is Windows the only case preserving, case insensitive OS?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Sep  6 21:14:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Sep 2013 19:14:07 +0000
Subject: [issue18917] python won't display greek characters in apache under
 windows
In-Reply-To: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>
Message-ID: <1378494847.5.0.828033168682.issue18917@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe that this is *the* answer to the issue, so the issue should be closed.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Sep  6 21:14:20 2013
From: report at bugs.python.org (Darko Veberic)
Date: Fri, 06 Sep 2013 19:14:20 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1378494860.1.0.686734554921.issue1625@psf.upfronthosting.co.za>


Darko Veberic added the comment:

It is interesting, this issue was fixed in boost 4 years ago:
https://svn.boost.org/trac/boost/ticket/3853
and a comment from the pbzip2 author suggests that not supporting multiple streams is in violation of the bz2 file format spec.

----------
nosy: +Darko.Veberic
versions: +Python 2.7 -Python 3.3

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

From report at bugs.python.org  Fri Sep  6 21:15:11 2013
From: report at bugs.python.org (Nick)
Date: Fri, 06 Sep 2013 19:15:11 +0000
Subject: [issue18917] python won't display greek characters in apache under
 windows
In-Reply-To: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>
Message-ID: <1378494911.56.0.825242003741.issue18917@psf.upfronthosting.co.za>


Changes by Nick <lowdx1 at yahoo.com>:


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

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

From report at bugs.python.org  Fri Sep  6 21:17:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 19:17:29 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <3cWpS92LtXz7Lks@mail.python.org>


Roundup Robot added the comment:

New changeset 14972c999e80 by Charles-Fran?ois Natali in branch 'default':
Issue #18934: Relax test_multiprocessing.test_invalid_handles a bit: we just
http://hg.python.org/cpython/rev/14972c999e80

----------

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

From report at bugs.python.org  Fri Sep  6 21:18:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 19:18:45 +0000
Subject: [issue18623] Factor out the _SuppressCoreFiles context manager
In-Reply-To: <1375395147.99.0.182035967047.issue18623@psf.upfronthosting.co.za>
Message-ID: <1378495125.69.0.118756059153.issue18623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> The explicit 'object' superclass is old-school ;-)

Ha. Ok, I've fixed it.

----------

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

From report at bugs.python.org  Fri Sep  6 21:21:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 19:21:21 +0000
Subject: [issue18949] codeop possible flow error
In-Reply-To: <1378493985.89.0.543332382387.issue18949@psf.upfronthosting.co.za>
Message-ID: <1378495281.81.0.313022329067.issue18949@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why do you think that?  Can you provide a test case that fails?

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

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

From report at bugs.python.org  Fri Sep  6 21:25:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Sep 2013 19:25:27 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378495527.58.0.0978360697523.issue18944@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The typo causes 1 test to run 5 times instead of 5 tests 1 each.
After fix, all pass on Win7, 3.4.0a1 (where fix is on line 1675 instead of 1618).

----------
nosy: +rhettinger, terry.reedy

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

From report at bugs.python.org  Fri Sep  6 21:27:23 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Sep 2013 19:27:23 +0000
Subject: [issue18917] python won't display greek characters in apache under
 windows
In-Reply-To: <1378267183.66.0.904044097978.issue18917@psf.upfronthosting.co.za>
Message-ID: <1378495643.82.0.33825380173.issue18917@psf.upfronthosting.co.za>


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


----------
resolution:  -> works for me
stage:  -> committed/rejected

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

From report at bugs.python.org  Fri Sep  6 21:41:47 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 19:41:47 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378496507.41.0.885877038214.issue18944@psf.upfronthosting.co.za>


Tim Peters added the comment:

The fix is obviously correct ;-) - so what next?  Armin & Terry, I don't know whether you have commit privileges.  If you don't, assign it to me and I'll commit it.

Removed 3.5 from the Versions list and added 3.3 and 3.4.

----------
nosy: +tim.peters
versions: +Python 3.3, Python 3.4 -Python 3.5

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

From report at bugs.python.org  Fri Sep  6 21:42:07 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 19:42:07 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378496527.0.0.648955581975.issue18944@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
components: +Tests -Interpreter Core

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

From report at bugs.python.org  Fri Sep  6 22:13:09 2013
From: report at bugs.python.org (Wilberto Morales)
Date: Fri, 06 Sep 2013 20:13:09 +0000
Subject: [issue18949] codeop possible flow error
In-Reply-To: <1378493985.89.0.543332382387.issue18949@psf.upfronthosting.co.za>
Message-ID: <1378498389.78.0.856934996318.issue18949@psf.upfronthosting.co.za>


Wilberto Morales added the comment:

I can't provide a example but reading the source comments it seems wrong.

'First, check if the source consists entirely of blank lines and
comments; if so, replace it with 'pass', because the built-in
parser doesn't always do the right thing for these.'

So the way I understand this is.

pure_comments_or_blank = True

for line in source:
    line = line.strip()
    if line and line[0] != '#':
        pure_comments_or_blank = False
        break

if pure_comments_or_blank:
    if symbol != "eval":
        source = "pass"

So check that atleast one line is actual code and not comments or blank. If none is then replace it with a 'pass'

Instead the loop seems a little weird. 

for line in source.split("\n"):
    line = line.strip()
    if line and line[0] != '#':
        break               # Leave it alone
else:
    if symbol != "eval":
        source = "pass"   

If it finds a something that is not a comment in a line it breaks. But then right after the for loop it contains an else statement. I'm not even sure when this else statement is executed. I'm sorry if I'm misinterpreting this.

----------

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

From report at bugs.python.org  Fri Sep  6 22:13:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Sep 2013 20:13:55 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378498435.59.0.688647272439.issue18937@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Proposed patch with an assertLogs() method.

----------
keywords: +patch
Added file: http://bugs.python.org/file31630/assertlogs.patch

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

From report at bugs.python.org  Fri Sep  6 22:34:27 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 20:34:27 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378499667.45.0.642959212288.issue18944@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
assignee:  -> tim.peters

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

From report at bugs.python.org  Fri Sep  6 22:43:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 20:43:26 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <3cWrMK74Ckz7LnY@mail.python.org>


Roundup Robot added the comment:

New changeset b6059bac8a9c by Tim Peters in branch '3.3':
Issue 18944:  fix a 1-character typo in test_set.py.
http://hg.python.org/cpython/rev/b6059bac8a9c

New changeset 4b64166d5abb by Tim Peters in branch 'default':
Merge 3.3 into default.
http://hg.python.org/cpython/rev/4b64166d5abb

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

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

From report at bugs.python.org  Fri Sep  6 22:43:59 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Sep 2013 20:43:59 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378500239.22.0.159929448901.issue18944@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Sep  6 22:55:11 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Sep 2013 20:55:11 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378500911.28.0.499034305799.issue16938@psf.upfronthosting.co.za>


Ethan Furman added the comment:

"Crash" is probably too strong.  help() runs, but doesn't return anything useful.

Metaclasses aside, I think the real issue here is objects that don't have __objclass__ defined.  __objclass__ has been around for over a decade (see PEP-0252), and with that `inspect` works fine (aside from metaclasses ;) .

----------

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

From report at bugs.python.org  Fri Sep  6 23:02:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:02:47 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1378501367.15.0.783706163828.issue18919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch updated. It now contains tests for all supported encoding formats (PCM8-32, u-Law, A-Law).

----------

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

From report at bugs.python.org  Fri Sep  6 23:17:44 2013
From: report at bugs.python.org (Graham Wideman)
Date: Fri, 06 Sep 2013 21:17:44 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <1378502264.93.0.683278564466.issue18939@psf.upfronthosting.co.za>


Graham Wideman added the comment:

@Vinay Sajip  Thanks for looking at this issue and adding the link to PEP 405, and your explanation "When working..." with helpful shebang comments.

That said, the combination of PEP 405 and this updated page doesn't clear things up completely.

Vinay remarks "The venv documentation does assume that the reader knows what virtual environments are and how they work."

If so, let's have a link to where the reader can get up to speed on how they work. PEP 405 is a help, but doesn't detail the topics I raised in earlier thread messages. Also, different legacy virtual environment schemes work differently, so prior knowledge doesn't necessarily help.

But the article already has a link to "virtual environments"... to a box in the same article, which is at the heart of not bringing clarity to the topics at hand.

One problem is lack of clarity about what "active" and "activate" means. Here is what I currently believe:

In connection with venv, the term "active" is used in two relatively trivial but subtly different ways. 

(1) "First on PATH": The phrase "active environment" may be used to simply indicate the python environment which will be found first via the user's shell PATH. Further, each venv-configured python virtual environment installation includes an "activate" script whose main effect is just to add that environment's bin or Scripts directory to the beginning of the user's PATH. This makes the selected python environment the default when the user types the 'python' command. This use of "active" or "activate" might better be termed "default or "make default".

(2) "Actually running": A second meaning of "active" refers to an actually running instance of a python interpreter and its associated environment, whether or not it is first in the user's PATH. Any installed python (virtual or not) may be launched by explicitly invoking the complete path to its executable (eg: C:\python33\python.exe), whereupon that version of python will run, with its associated sys.path and so on.

These two meanings are obviously related. The particular python environment (virtual or not) that is "active" in the first sense, when invoked by a plain "python" command, will become "active" in the second sense.  But a running python ("active" in the second sense) will not necessarily be the "active" one in the first sense.

Implications for installers: A library installer invoked from the command line, unless told otherwise, will presumably install its payload into the python environment found via PATH. Consequently, in preparation, the intended target python should be made "active" in the first sense.

I have not elaborated here on my other concern (since I don't understand the details) -- clarification of different degrees of isolation/autonomy which can be established for each virtual environment. I still believe that's important to understand, and the current article and PEP 405 don't cover it successfully, in my view.

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

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

From report at bugs.python.org  Fri Sep  6 23:18:36 2013
From: report at bugs.python.org (Alex)
Date: Fri, 06 Sep 2013 21:18:36 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1378502316.82.0.147146121173.issue4709@psf.upfronthosting.co.za>


Alex added the comment:

I want to add that this bug led to bizarre behavior (described here: http://stackoverflow.com/questions/18646694/pass-pointer-from-c-to-python-w-boost-python) when using 64-bit Boost-Python compiled with Mingw-w64 in Windows 7.  Boost-Python and programs linked to it compiled, but failed at run-time with segfaults.  The solution described by jdpipe worked for me, but I only found it after a day of fruitless debugging attempts.

----------
nosy: +arbitraryvalue

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

From report at bugs.python.org  Fri Sep  6 23:24:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:24:54 +0000
Subject: [issue18950] Miscellaneous fixes for the sunau module
Message-ID: <1378502694.18.0.563332968903.issue18950@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch fixes followed bugs in the sunau module:

1. Au_read.readframes() reads wrong number of frames from multichannel stream.

2. Au_read.readframes() doesn't change current file position.

3. Au_write.writeframesraw() incorrectly updates current file position in a stream with u-Law compression.

4. Au_read.getnframes() returns a float (underporting from Python 2).

5. Au_write incorrectly updates header when it was opened with existing non-empty file object.

New tests proposed in issue18919 expose all these bugs.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: sunau.patch
keywords: patch
messages: 197109
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Miscellaneous fixes for the sunau module
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31631/sunau.patch

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

From report at bugs.python.org  Fri Sep  6 23:25:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:25:20 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1378502720.23.0.590049914812.issue18919@psf.upfronthosting.co.za>


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


----------
dependencies: +Miscellaneous fixes for the sunau module

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

From report at bugs.python.org  Fri Sep  6 23:29:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:29:15 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1378502955.64.0.247663552504.issue18919@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file31632/audiotests_2.patch

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

From report at bugs.python.org  Fri Sep  6 23:39:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:39:23 +0000
Subject: [issue5202] wave.py cannot write wave files into a shell pipeline
In-Reply-To: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
Message-ID: <1378503563.14.0.94038521554.issue5202@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forgot attach a patch. In any case it already slightly outdated.

After looking at other audio modules I think David's approach is better. It is also used in the chunk module. Here is updated patch with tests (tests are not final, issue18919 provides better tests).

----------
dependencies: +Unify audio modules tests

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

From report at bugs.python.org  Fri Sep  6 23:40:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:40:10 +0000
Subject: [issue5202] wave.py cannot write wave files into a shell pipeline
In-Reply-To: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
Message-ID: <1378503610.0.0.281538906429.issue5202@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forgot attach a patch. In any case it already slightly outdated.

After looking at other audio modules I think David's approach is better. It is also used in the chunk module. Here is updated patch with tests (tests are not final, issue18919 provides better tests).

----------
Added file: http://bugs.python.org/file31633/wave_write_unseekable.patch

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

From report at bugs.python.org  Fri Sep  6 23:40:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 21:40:45 +0000
Subject: [issue5202] wave.py cannot write wave files into a shell pipeline
In-Reply-To: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
Message-ID: <1378503645.58.0.191387481623.issue5202@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep  6 23:53:09 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 06 Sep 2013 21:53:09 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378504389.56.0.663650488413.issue16938@psf.upfronthosting.co.za>


Armin Rigo added the comment:

The __objclass__ is a workaround.  I don't understand your point.  I think the original poster is saying that simply putting a __dir__() method on a class can confuse help() more than would be necessary, and if he's correct I agree with him.

----------

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

From report at bugs.python.org  Sat Sep  7 00:10:12 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 06 Sep 2013 22:10:12 +0000
Subject: [issue18458] libedit history offset workaround
In-Reply-To: <1373891060.78.0.881069869114.issue18458@psf.upfronthosting.co.za>
Message-ID: <1378505412.72.0.877536566119.issue18458@psf.upfronthosting.co.za>


Ned Deily added the comment:

The original patch missed one spot.  Here's an updated version. I'm going to apply this to default (for the imminent 3.4.0a2) in case people start running into this on new versions of OS X.  It needs to be backported to 2.7 and 3.3; a test would be nice and it could be simplified a bit as part of the generalized support for libedit (Issue13501).

----------
Added file: http://bugs.python.org/file31634/issue18458.patch

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

From report at bugs.python.org  Sat Sep  7 00:14:13 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Sep 2013 22:14:13 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378505653.93.0.998449847864.issue16938@psf.upfronthosting.co.za>


Ethan Furman added the comment:

dir(obj) is only confused if it returns attributes that are not found in obj.__dict__ (aka virtual attributes).

For these virtual attributes, setting __objclass__ solves the problem.

Armin, when you say it's a workaround do you mean __objclass__ itself, or the way Ronald and I are using it?  It looks like Ronald is using it the way it was intended (on a descriptor), although I may be abusing it by putting it on an Enum member.

----------

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

From report at bugs.python.org  Sat Sep  7 00:14:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 22:14:46 +0000
Subject: [issue18949] codeop possible flow error
In-Reply-To: <1378493985.89.0.543332382387.issue18949@psf.upfronthosting.co.za>
Message-ID: <1378505686.07.0.409311897842.issue18949@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I'm not even sure when this else statement is executed.

It executed when no breaks were happen. I.e. both variants of code are equivalent besides the fact that variant with "else" doesn't require named boolean variable. It is a feature of Python syntax.

----------
nosy: +serhiy.storchaka
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Sep  7 00:17:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Sep 2013 22:17:06 +0000
Subject: [issue18458] libedit history offset workaround
In-Reply-To: <1373891060.78.0.881069869114.issue18458@psf.upfronthosting.co.za>
Message-ID: <3cWtRP5fdvz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset b6b8a2171aa3 by Ned Deily in branch 'default':
Issue #18458: Prevent crashes with newer versions of libedit.  Its readline
http://hg.python.org/cpython/rev/b6b8a2171aa3

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

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

From report at bugs.python.org  Sat Sep  7 00:22:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Sep 2013 22:22:35 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378506155.92.0.918193825668.issue18873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It will fail on:

"#coding=0"

I'm wondering why findall() is used to match this regexp.

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

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

From report at bugs.python.org  Sat Sep  7 00:29:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Sep 2013 22:29:11 +0000
Subject: [issue18939] Venv docs regarding original python install
In-Reply-To: <1378418560.94.0.0370764034466.issue18939@psf.upfronthosting.co.za>
Message-ID: <1378506551.37.0.640905921061.issue18939@psf.upfronthosting.co.za>


R. David Murray added the comment:

You have understood correctly, after reading the now-existing documentation.  Do you have a suggestion for how they could be further improved, given that they currently seem to convey accurate information?

For the "autonomy" question, as far as I know the only option that affects that is whether or not the installed Python's site-packages is included in sys.path or not, and I'm sure that is documented.  Perhaps you were confused by how trivial indeed "activation" is?

If there are other things you still don't understand, it would help if you could pose specific questions.

----------

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

From report at bugs.python.org  Sat Sep  7 00:33:17 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Sep 2013 22:33:17 +0000
Subject: [issue16938] pydoc confused by __dir__
In-Reply-To: <1357944129.98.0.501949279766.issue16938@psf.upfronthosting.co.za>
Message-ID: <1378506797.59.0.441834051768.issue16938@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Ronald said:
> One possible workaround: assume that the class is the inspected
> class when a name returned by dir(cls) cannot be found in one of
> the classes on the mro.

At some point will this cause help to display an attribute on the wrong class?

----------

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

From report at bugs.python.org  Sat Sep  7 00:54:05 2013
From: report at bugs.python.org (Michael Foord)
Date: Fri, 06 Sep 2013 22:54:05 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378508045.12.0.00805909732135.issue18937@psf.upfronthosting.co.za>


Michael Foord added the comment:

So making assertions about logging is very common, but I *always* do this by just mocking out the logger and making an assertion about the call. It's trivially easy to do.

----------

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

From report at bugs.python.org  Sat Sep  7 01:59:44 2013
From: report at bugs.python.org (paul j3)
Date: Fri, 06 Sep 2013 23:59:44 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378511984.32.0.832491289455.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

The patch isn't a good unittest case because it produces an Error, not a Failure.  It does, though, raise a valid question about how a Mutually_exclusive_group tests for the use of its arguments.

As you note, argparse does use the `is` test: `argument_values is not action.default`.  argument_values is the result of passing an argument_string through its 'type' function.

This reworks your test case a bit:

    group = parser.add_mutually_exclusive_group()
    group.add_argument('--foo', default='test')
    group.add_argument('--bar', type=int, default=256)
    group.add_argument('--baz', type=int, default=257)

'--foo test --baz 257' will give the `argument --foo: not allowed with argument --baz` error message, but '--foo test --baz 256' does not.

So which is right?  Should it complain because 2 exclusive arguments are being used?  Or should it be excused from complaining because the values match their defaults?

The other issue is whether the values really match the defaults or not.  With an `is` test, the `id`s must match. The ids for small integers match all the time, while ones >256 differ.

Strings might have the same id or not, depending on how they are created.  If I create `x='test'`, and `y='--foo test'.split()[1]`.  `x==y` is True, but `x is y` is False.  So '--foo test' argument_value does not match the 'foo.default'.

So large integers (>256) behave like strings when used as defaults in this situation.  It's the small integers that have unique ids, and hence don't trigger mutually_exclusive_group errors when they should.

This mutually_exclusive_group 'is' test might not be ideal (free from all ambiguities), but I'm not sure it needs to be changed.  Maybe there needs to be a warning in the docs about mutually_exclusive_groups and defaults other than None.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Sat Sep  7 02:10:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 00:10:40 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378508045.12.0.00805909732135.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378512637.2498.6.camel@fsol>


Antoine Pitrou added the comment:

> So making assertions about logging is very common, but I *always* do
> this by just mocking out the logger and making an assertion about the
> call. It's trivially easy to do.

Only works if you test the exact logger that will be triggered, rather
than e.g. a child in the hierarchy (and the exact logging method, for
that matter, too).

----------

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

From report at bugs.python.org  Sat Sep  7 02:21:20 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 07 Sep 2013 00:21:20 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378513280.79.0.310667862818.issue18937@psf.upfronthosting.co.za>


Michael Foord added the comment:

Do you have a lot of circumstances where you want to test logging but you don't know the specific logger and method called? That's not a situation I've been in.

----------

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

From report at bugs.python.org  Sat Sep  7 02:26:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 00:26:07 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378513280.79.0.310667862818.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378513559.2498.9.camel@fsol>


Antoine Pitrou added the comment:

> Do you have a lot of circumstances where you want to test logging but
> you don't know the specific logger and method called? That's not a
> situation I've been in.

I have a lot of circumstances where I do not *care* about the specific
logger (as long as it's somewhere in a subhierarchy) and the specific
level (as long as it's e.g. a warning or above).

----------

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

From report at bugs.python.org  Sat Sep  7 02:50:02 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 00:50:02 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378515002.44.0.6354335369.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

All the timeout args are great!  I wish Python had always had them :-)

Back to the pain at hand, it's not the number of lines of code that rubs me the wrong way, but the sheer obscurity of it all.  This handful of lines is - of necessity - sprayed across two C code files, a C header file, and a Python module.  That makes it very hard (for anyone but you - LOL) to reconstruct the _intent_ of it all.

I'm adding another patch, which is your threadstate_join_2.patch but with a new comment block (in pystate.h) spelling out the rationale behind it all.  I can live with that ;-)

----------
Added file: http://bugs.python.org/file31635/threadstate_join_3.patch

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

From report at bugs.python.org  Sat Sep  7 03:55:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Sep 2013 01:55:31 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378518931.0.0.811208147012.issue18944@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Just to answer, anyone with Python snake has commit privileges of some sort but may not be setup to commit to cpython. I suspect Armin found this while review the test for pypy.  I focus mostly on Idle, but on better days, will do little commits like this.

----------

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

From report at bugs.python.org  Sat Sep  7 04:06:06 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 02:06:06 +0000
Subject: [issue18944] Minor mistake in test_set.py
In-Reply-To: <1378458771.78.0.221134021979.issue18944@psf.upfronthosting.co.za>
Message-ID: <1378519566.3.0.608888944023.issue18944@psf.upfronthosting.co.za>


Tim Peters added the comment:

Right, I should have asked specifically about cpython commit privs ;-)  Thanks for expounding!

----------

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

From report at bugs.python.org  Sat Sep  7 04:13:38 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 07 Sep 2013 02:13:38 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378520018.75.0.638727966888.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

A further complication on this.  With the arguments I defined in the previous post

    p.parse_args('--foo test --baz 257'.split())

gives the mutually exclusive error message.  `sys.argv` does the same.

    p.parse_args(['--foo', 'test', '--baz', '257'])

does not give an error, because here the 'test' argument string is the same as the default 'test'.  So the m_x_g test thinks `--foo' is the default, and does not count as an input.

Usually in testing an argparse setup I use the list and split arguments interchangeably, but this shows they are not equivalent.

----------

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

From report at bugs.python.org  Sat Sep  7 04:20:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Sep 2013 02:20:20 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378520420.82.0.09638970802.issue18937@psf.upfronthosting.co.za>


R. David Murray added the comment:

Exactly.  It is the difference between black box testing and white box testing.  IMO mock, while a great tool, should be used with caution, because it tends to lead to white box testing.

----------

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

From report at bugs.python.org  Sat Sep  7 04:46:26 2013
From: report at bugs.python.org (py.user)
Date: Sat, 07 Sep 2013 02:46:26 +0000
Subject: [issue18951] In unittest.TestCase.assertRegex change "re" and "regex"
 to "r"
Message-ID: <1378521986.13.0.796704852763.issue18951@psf.upfronthosting.co.za>


New submission from py.user:

there is no direct link to table

look under link
http://docs.python.org/3/library/unittest.html#unittest.TestCase.assertWarnsRegex

----------
assignee: docs at python
components: Documentation
files: issue.diff
keywords: patch
messages: 197130
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In unittest.TestCase.assertRegex change "re" and "regex" to "r"
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31636/issue.diff

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

From report at bugs.python.org  Sat Sep  7 04:53:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 02:53:42 +0000
Subject: [issue18908] Enum docs: sections leak out
In-Reply-To: <1378161600.59.0.237500625913.issue18908@psf.upfronthosting.co.za>
Message-ID: <3cX0ZY1t8mz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset a55cbaf9a581 by Ethan Furman in branch 'default':
Close #18908: Keep Enum docs in their own section.  Patch by Elazar Gershuni.
http://hg.python.org/cpython/rev/a55cbaf9a581

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Sep  7 06:22:13 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 07 Sep 2013 04:22:13 +0000
Subject: [issue18952] Fix test.support.open_urlresource (support package
 regression)
Message-ID: <1378527733.08.0.636104620502.issue18952@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Since test.support was moved into its own package, support.open_urlresource has been unable to work.  It expects <__file__ dir>/data to exist, but since <__file__ dir> is now Lib/test/support instead of Lib/test, it doesn't unless someone creates it manually.  Since open_urlresource turns all exceptions into SkipTest, this means that all test runs have been silently skipping test_codecmaps_* and a couple others since support became a package.

Here's a patch with my preferred fix, which is to move Lib/test/data to Lib/test/support/data.  This dir is only used by support.open_urlresource, and moving it does just a tiny bit to de-clutter Lib/test.

----------
components: Tests
files: move_test_data.diff
keywords: patch
messages: 197132
nosy: ezio.melotti, ncoghlan, zach.ware
priority: normal
severity: normal
status: open
title: Fix test.support.open_urlresource (support package regression)
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31637/move_test_data.diff

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

From report at bugs.python.org  Sat Sep  7 06:23:09 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 07 Sep 2013 04:23:09 +0000
Subject: [issue18952] Fix test.support.open_urlresource (support package
 regression)
In-Reply-To: <1378527733.08.0.636104620502.issue18952@psf.upfronthosting.co.za>
Message-ID: <1378527789.08.0.121890460091.issue18952@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's an alternative fix, which just makes open_urlresource look one directory higher than where __file__ lives.

----------
Added file: http://bugs.python.org/file31638/fix_support_open_urlresource.diff

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

From report at bugs.python.org  Sat Sep  7 06:40:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 04:40:22 +0000
Subject: [issue18953] Typo in NEWS about fixed format specifiers for
 Py_ssize_t in debugging output in the _sre module
Message-ID: <1378528822.12.0.535842380939.issue18953@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

File Misc/NEWS, line 65 & 66:

- Issue #18672: Fixed format specifiers for Py_ssize_t in debugging output in
  the _sre moduel.

"moduel" => "module"

Related commit:
http://hg.python.org/cpython/rev/c41c68a18bb6

----------
assignee: docs at python
components: Documentation
messages: 197134
nosy: docs at python, serhiy.storchaka, vajrasky
priority: normal
severity: normal
status: open
title: Typo in NEWS about fixed format specifiers for Py_ssize_t in debugging output in the _sre module
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 06:48:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 04:48:08 +0000
Subject: [issue18954] Grammatically incorrect sentences in Python/fileutils.c
Message-ID: <1378529288.44.0.552917798936.issue18954@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In commit about "implementation of the PEP 446: file descriptors and file handles are now created non-inheritable", there are some grammatically incorrect sentences in Python/fileutils.c.

Please see the patch for details.

Related commit:
http://hg.python.org/cpython/rev/ef889c3d5dc6?revcount=240

----------
assignee: docs at python
components: Documentation
files: fix_typo_in_fileutils.patch
keywords: patch
messages: 197135
nosy: docs at python, haypo, vajrasky
priority: normal
severity: normal
status: open
title: Grammatically incorrect sentences in Python/fileutils.c
versions: Python 3.4
Added file: http://bugs.python.org/file31639/fix_typo_in_fileutils.patch

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

From report at bugs.python.org  Sat Sep  7 06:56:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 04:56:33 +0000
Subject: [issue18955] Confusing documentation in Lib/importlib/util.py
Message-ID: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/importlib/util.py, the documentation is confusing me.

Line 42 & 43:

    If an exception is raised and the decorator created the module it is
    subsequently removed from sys.modules.

Is it supposed to be:

    "If an exception is raised and the decorator which created the module is
    subsequently removed from sys.modules." ?

----------
assignee: docs at python
components: Documentation
messages: 197136
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Confusing documentation in Lib/importlib/util.py
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 07:31:51 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 05:31:51 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378531911.28.0.675377901227.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

New patch (threadstate_join_4.patch) refactors so that is_alive() returns True until the tstate is cleared.  This simplifies join() a lot (it doesn't have to roll its own timeout implementation anymore), but complicates is_alive().

Caution:  I don't know anything about the dummy threading implementation.  So if I broke that, sue me ;-)

----------
Added file: http://bugs.python.org/file31640/threadstate_join_4.patch

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

From report at bugs.python.org  Sat Sep  7 07:38:56 2013
From: report at bugs.python.org (Ben Finney)
Date: Sat, 07 Sep 2013 05:38:56 +0000
Subject: =?utf-8?q?=5Bissue18956=5D_Document_useful_functions_in_=E2=80=98pydoc?=
 =?utf-8?q?=E2=80=99_module?=
Message-ID: <1378532336.08.0.216765249116.issue18956@psf.upfronthosting.co.za>


New submission from Ben Finney:

The library documentation for ?pydoc? expects that the ?pydoc? module will only ever be run as a command-line program. This ignores the general usefulness of several of the functions in that module when imported from the library.

The documentation should describe at least the following functions:

* pydoc.getdoc

* pydoc.synopsis

* pydoc.splitdoc

The following would be useful also:

* pydoc.classname

* pydoc.cram

* pydoc.allmethods

----------
assignee: docs at python
components: Documentation
messages: 197138
nosy: bignose, docs at python
priority: normal
severity: normal
status: open
title: Document useful functions in ?pydoc? module
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Sep  7 07:56:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Sep 2013 05:56:37 +0000
Subject: [issue18894] In unittest.TestResult.failures remove deprecated fail*
 methods
In-Reply-To: <1377966174.08.0.355322542495.issue18894@psf.upfronthosting.co.za>
Message-ID: <1378533397.95.0.527589288193.issue18894@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, michael.foord

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

From report at bugs.python.org  Sat Sep  7 07:58:24 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Sep 2013 05:58:24 +0000
Subject: =?utf-8?q?=5Bissue18956=5D_Document_useful_functions_in_=E2=80=98pydoc?=
 =?utf-8?q?=E2=80=99_module?=
In-Reply-To: <1378532336.08.0.216765249116.issue18956@psf.upfronthosting.co.za>
Message-ID: <1378533504.92.0.722929443474.issue18956@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks like duplicate of issue 7798.

> * pydoc.getdoc

http://docs.python.org/3.4/library/inspect.html#inspect.getdoc

> * pydoc.splitdoc

See issue 12916 for inspect.splitdoc.

> * pydoc.cram

This was rejected in issue 12914.

> * pydoc.allmethods

This was rejected in issue 12917.

----------
nosy: +berker.peksag
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Sat Sep  7 07:58:52 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Sep 2013 05:58:52 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1378533532.96.0.637859404303.issue18896@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  7 08:13:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Sep 2013 06:13:20 +0000
Subject: [issue18936] 2.7 distutils getopt chokes on unicode option names
In-Reply-To: <1378411388.86.0.748005801735.issue18936@psf.upfronthosting.co.za>
Message-ID: <1378534400.16.0.639978855253.issue18936@psf.upfronthosting.co.za>


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


----------
assignee:  -> eric.araujo
components: +Distutils -Library (Lib)
nosy: +eric.araujo, tarek
title: getopt chokes on unicode option names -> 2.7 distutils getopt chokes on unicode option names

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

From report at bugs.python.org  Sat Sep  7 08:15:56 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Sep 2013 06:15:56 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378534556.38.0.997165830002.issue18943@psf.upfronthosting.co.za>


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


----------
nosy: +bethard

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

From report at bugs.python.org  Sat Sep  7 08:52:45 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 07 Sep 2013 06:52:45 +0000
Subject: [issue18955] Confusing documentation in Lib/importlib/util.py
In-Reply-To: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>
Message-ID: <1378536765.91.0.975032469842.issue18955@psf.upfronthosting.co.za>


Eric Snow added the comment:

It is the module that gets removed.  I suppose it could say, "...created the module, then that module is subsequently...".  Would that help?

----------
nosy: +eric.snow

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

From report at bugs.python.org  Sat Sep  7 09:02:54 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 07 Sep 2013 07:02:54 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378537374.01.0.914980718393.issue18943@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Getting consistently one behavior or the other would be much better imho; I think it's wrong-ish to have the behavior depend uncontrollably on implementation details.  But I agree that it's slightly messy to declare which of the two possible fixes is the "right" one.  I'm slightly in favor of the more permissive solution ("--bar 42" equivalent to no arguments at all if 42 is the default) only because the other solution might break someone's existing code.  If I had no such backward-compatibility issue in mind, I'd vote for the other solution (you can't specify "--bar" with any value, because you already specified "--foo").

----------

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

From report at bugs.python.org  Sat Sep  7 09:24:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 07:24:09 +0000
Subject: [issue18900] Add the random.distrib module
In-Reply-To: <1378061368.61.0.991913209917.issue18900@psf.upfronthosting.co.za>
Message-ID: <1378538649.63.0.924762443381.issue18900@psf.upfronthosting.co.za>


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


----------
stage:  -> committed/rejected
status: pending -> closed

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

From report at bugs.python.org  Sat Sep  7 10:34:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Sep 2013 08:34:01 +0000
Subject: [issue18957] PYTHONFAULTHANDLER enables faulthandler when the
 variable is empty
Message-ID: <1378542841.95.0.330646753662.issue18957@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Most Python environment variables (PYTHON*) only enable something when their value is non-empty. The PYTHONFAULTHANDLER enables the faulthandler even if the value is empty. As the author of the module, I think that it is a bug and should be fixed (even in Python 3.3).

----------
messages: 197142
nosy: haypo
priority: normal
severity: normal
status: open
title: PYTHONFAULTHANDLER enables faulthandler when the variable is empty
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Sep  7 10:37:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 08:37:56 +0000
Subject: [issue18954] Grammatically incorrect sentences in Python/fileutils.c
In-Reply-To: <1378529288.44.0.552917798936.issue18954@psf.upfronthosting.co.za>
Message-ID: <3cX8Cl54CXz7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset 98f82b124c7d by Victor Stinner in branch 'default':
Close #18954: Fix some typo in fileutils.c comments
http://hg.python.org/cpython/rev/98f82b124c7d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Sep  7 10:38:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Sep 2013 08:38:21 +0000
Subject: [issue18954] Grammatically incorrect sentences in Python/fileutils.c
In-Reply-To: <1378529288.44.0.552917798936.issue18954@psf.upfronthosting.co.za>
Message-ID: <1378543101.03.0.79667317366.issue18954@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the report! Don't hesitate to report other grammar issues ;-)

----------

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

From report at bugs.python.org  Sat Sep  7 12:12:07 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 10:12:07 +0000
Subject: [issue18957] PYTHONFAULTHANDLER enables faulthandler when the
 variable is empty
In-Reply-To: <1378542841.95.0.330646753662.issue18957@psf.upfronthosting.co.za>
Message-ID: <1378548727.3.0.980062926119.issue18957@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Do you mean something like *this*?

this -> the patch, pythonfaulthandler_env_var.patch.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31641/pythonfaulthandler_env_var.patch

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

From report at bugs.python.org  Sat Sep  7 12:47:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 10:47:00 +0000
Subject: [issue18955] Confusing documentation in Lib/importlib/util.py
In-Reply-To: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>
Message-ID: <1378550820.01.0.918318442342.issue18955@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

That would help.

----------

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

From report at bugs.python.org  Sat Sep  7 13:04:09 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 11:04:09 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378551849.1.0.851571884169.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I noticed in CPython source code, when we print the type of the object, we use "%.200s" not "%s". For example, in Modules/posixmodule.c:

"uid should be integer, not %.200s",

So the newest path was created to conform with this tradition.

Another thing I noticed, there are two ways to get the type of object:

1. src->ob_type->tp_name
2. Py_TYPE(src)->tp_name

Both are widely used. So I am not sure which is the best way. I leave it alone this issue.

----------
Added file: http://bugs.python.org/file31642/fix_error_message_reader_csv_alternative_1_v7.patch

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

From report at bugs.python.org  Sat Sep  7 14:20:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 12:20:33 +0000
Subject: [issue18894] In unittest.TestResult.failures remove deprecated fail*
 methods
In-Reply-To: <1377966174.08.0.355322542495.issue18894@psf.upfronthosting.co.za>
Message-ID: <3cXF8Y2dsSz7LkG@mail.python.org>


Roundup Robot added the comment:

New changeset c391c30fee99 by Ezio Melotti in branch '2.7':
#18894: remove mention of deprecated fail* methods.
http://hg.python.org/cpython/rev/c391c30fee99

New changeset c3a2c0504960 by Ezio Melotti in branch '3.3':
#18894: remove mention of deprecated fail* methods.
http://hg.python.org/cpython/rev/c3a2c0504960

New changeset 5fbb01033a08 by Ezio Melotti in branch 'default':
#18894: merge with 3.3.
http://hg.python.org/cpython/rev/5fbb01033a08

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

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

From report at bugs.python.org  Sat Sep  7 14:21:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Sep 2013 12:21:24 +0000
Subject: [issue18894] In unittest.TestResult.failures remove deprecated fail*
 methods
In-Reply-To: <1377966174.08.0.355322542495.issue18894@psf.upfronthosting.co.za>
Message-ID: <1378556484.16.0.362102169137.issue18894@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Sat Sep  7 14:24:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 12:24:27 +0000
Subject: [issue18895] In unittest.TestResult.addError split the sentence
In-Reply-To: <1377966366.86.0.69110585984.issue18895@psf.upfronthosting.co.za>
Message-ID: <3cXFF63X3mz7LkG@mail.python.org>


Roundup Robot added the comment:

New changeset 523cfc78847c by Ezio Melotti in branch '2.7':
#18895: split a sentence in unittest docs.
http://hg.python.org/cpython/rev/523cfc78847c

New changeset dd669daad7de by Ezio Melotti in branch '3.3':
#18895: split a sentence in unittest docs.
http://hg.python.org/cpython/rev/dd669daad7de

New changeset 1043cc2cb0ff by Ezio Melotti in branch 'default':
#18895: merge with 3.3.
http://hg.python.org/cpython/rev/1043cc2cb0ff

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

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

From report at bugs.python.org  Sat Sep  7 14:24:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Sep 2013 12:24:49 +0000
Subject: [issue18895] In unittest.TestResult.addError split the sentence
In-Reply-To: <1377966366.86.0.69110585984.issue18895@psf.upfronthosting.co.za>
Message-ID: <1378556689.5.0.981458901862.issue18895@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Sat Sep  7 14:26:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Sep 2013 12:26:53 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <1378556813.6.0.782596065876.issue18904@psf.upfronthosting.co.za>


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


----------
assignee:  -> haypo
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Sat Sep  7 14:28:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Sep 2013 12:28:35 +0000
Subject: [issue18918] help('FILES') finds no documentation
In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>
Message-ID: <1378556915.92.0.127155925791.issue18918@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  7 14:33:15 2013
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Chaves_Fern=C3=A1ndez?=)
Date: Sat, 07 Sep 2013 12:33:15 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
Message-ID: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>


New submission from Adri?n Chaves Fern?ndez:

Calling json.load() with a file object or json.loads() with a string containing the attached JSON code raises an exception with the message 'No JSON object could be decoded'.

I?ve pasted the JSON code into http://jsonlint.com/ and it reports it as valid JSON.

This JSON code comes from the 0 A.D. game (https://github.com/0ad/0ad/blob/master/binaries/data/mods/public/civs/maur.json), and the game successfully parses it as well (with whatever they use for that). Yet it fails with json.load() and json.loads().

Note also that the rest of the JSON files of the same game folder (https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/civs) do work with json.load() and json.loads().

----------
components: Extension Modules
files: input.json
messages: 197152
nosy: Gallaecio
priority: normal
severity: normal
status: open
title: Exception('No JSON object could be decoded') when parsing a valid JSON
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31643/input.json

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

From report at bugs.python.org  Sat Sep  7 14:45:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Sep 2013 12:45:20 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378557920.64.0.685187510097.issue18945@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Do you want to submit a patch to add tests for these cases?

----------
nosy: +ezio.melotti
stage:  -> test needed

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

From report at bugs.python.org  Sat Sep  7 15:09:22 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Sep 2013 13:09:22 +0000
Subject: [issue18959] Create a "Superseded modules" section in standard
 library ToC
Message-ID: <1378559362.61.0.726437189184.issue18959@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

As discussed at the language summit earlier this year [1], it isn't alway easy to tell when glancing through the standard library docs which modules are merely hanging around because removing them would break backwards compatibility.

However, after reviewing the current ToC, we currently appear to only have two genuinely superseded modules: optparse (superseded by argparse) and imp (superseded by importlib).

Other cases where different modules touch on the same area are high level/low level splits (e.g. select vs selectors), or ones where the alternate modules are offering compatibility with different styles of API (e.g. etree vs DOM for XML, getopt vs argparse).

In future, asyncore/asynchat will hopefully be superseded by the PEP 3156 code (as "concurrent.events" or similar) and would also be moved under the new heading.

Marking as "easy" since the mechanics of the patch should be pretty simple: create a new heading and move the references to optparse and imp from their current locations.

[1] http://python-notes.boredomandlaziness.org/en/latest/conferences/pyconus2013/20130313-language-summit.html#legacy-modules

(I thought I had already created a bug for this, but can't find it, so I've created this new one. If I did already create an issue, we can close it as a duplicate and keep this one.)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 197154
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Create a "Superseded modules" section in standard library ToC
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  7 15:10:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 13:10:19 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1378559419.86.0.645863176446.issue18958@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

>>> a = open('/tmp/input.json')
>>> b = a.read()
>>> b[0]
'\ufeff'
>>> import json
>>> json.loads(b[1:])
loads just fine....
>>> json.loads(b)
chokes.....


Whether python json module should handle '\ufeff' gracefully or not, I am not sure. Let me investigate it.

----------
nosy: +vajrasky

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

From report at bugs.python.org  Sat Sep  7 15:11:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 13:11:33 +0000
Subject: [issue18960] First line can be executed twice
Message-ID: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When run in Python 3 followed script:

print('first')
#coding=iso8859-1
print('second')

it prints the 'first' string twice.

Besides this weird behavior I think PEP-0263 should specify that if a magic comment is second line in the file then first line should be a comment too.

----------
components: Interpreter Core
files: double_first_line.py
messages: 197156
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: First line can be executed twice
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31644/double_first_line.py

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

From report at bugs.python.org  Sat Sep  7 15:14:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Sep 2013 13:14:18 +0000
Subject: [issue18960] First line can be executed twice
In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>
Message-ID: <1378559658.18.0.911262898831.issue18960@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I think PEP-0263 should specify that if a magic comment is
> second line in the file then first line should be a comment too.

+1

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

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

From report at bugs.python.org  Sat Sep  7 15:15:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Sep 2013 13:15:24 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1378559724.25.0.663276969881.issue18958@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

The U+FEFF character is related with Byte order mark.

Reference:
http://en.wikipedia.org/wiki/Byte_Order_Mark

----------

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

From report at bugs.python.org  Sat Sep  7 15:22:26 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Sat, 07 Sep 2013 13:22:26 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378560146.42.0.423585112119.issue18945@psf.upfronthosting.co.za>


Vlad Shcherbina added the comment:

Probably yes, I'm just not sure when I'll get the time.

----------

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

From report at bugs.python.org  Sat Sep  7 15:35:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 13:35:14 +0000
Subject: [issue18960] First line can be executed twice
In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>
Message-ID: <1378560914.22.0.0739436311995.issue18960@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  7 15:35:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 13:35:23 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1378560923.53.0.814641094884.issue18958@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Use the utf-8-sig encoding.

See also issue17909.

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

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

From report at bugs.python.org  Sat Sep  7 15:35:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 13:35:29 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378560929.26.0.448614379601.issue18945@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl, ncoghlan

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

From report at bugs.python.org  Sat Sep  7 15:39:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 13:39:59 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378561199.08.0.383356484576.issue18943@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> The patch isn't a good unittest case because it produces an Error, not 
> a Failure.

Please let's not be pedantic about what a "good unittest" is.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sat Sep  7 15:43:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 13:43:27 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378561407.93.0.788816869418.issue18929@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Of course it is causing tests to fail. You are changing behaviour of an existing API. Please find another solution.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sat Sep  7 16:05:04 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sat, 07 Sep 2013 14:05:04 +0000
Subject: [issue18959] Create a "Superseded modules" section in standard
 library ToC
In-Reply-To: <1378559362.61.0.726437189184.issue18959@psf.upfronthosting.co.za>
Message-ID: <1378562704.41.0.290228665784.issue18959@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

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

From report at bugs.python.org  Sat Sep  7 16:42:25 2013
From: report at bugs.python.org (=?utf-8?q?Adri=C3=A1n_Chaves_Fern=C3=A1ndez?=)
Date: Sat, 07 Sep 2013 14:42:25 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1378564945.71.0.682684550653.issue18958@psf.upfronthosting.co.za>


Adri?n Chaves Fern?ndez added the comment:

I?ll veave how to address this up to you. Thanks a lot for finding out that the cause was the BOM, I?ve just removed it from the file and now everything works as expected.

----------

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

From report at bugs.python.org  Sat Sep  7 17:01:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Sep 2013 15:01:46 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1378566106.15.0.262297725648.issue18958@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Switching to a docs bug - this won't be fixed in 2.7, but it should probably be documented as a limitation.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +docs at python, ncoghlan
stage:  -> needs patch

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

From report at bugs.python.org  Sat Sep  7 17:15:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 15:15:06 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378566906.37.0.234235485002.issue18873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The tokenize module, 2to3, IDLE, and the Tools/scripts/findnocoding.py script affected by this bug. Proposed patch fixes this in all places and adds tests for tokenize and 2to3.

----------
components: +Demos and Tools, IDLE, Library (Lib)
nosy: +georg.brandl, kbk, loewis, meador.inge, roger.serwy, terry.reedy
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31645/detect_encoding_in_comments_only.patch

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

From report at bugs.python.org  Sat Sep  7 17:19:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 15:19:09 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378567149.24.0.625519398235.issue18873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And here is a patch which fixes the regular expression in PEP 263.

----------
Added file: http://bugs.python.org/file31646/pep0263_regex.diff

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

From report at bugs.python.org  Sat Sep  7 17:19:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 15:19:51 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378567191.8.0.113242529244.issue18873@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  7 17:30:48 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 07 Sep 2013 15:30:48 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
In-Reply-To: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>
Message-ID: <1378567848.51.0.770316865038.issue18821@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello. Here's a basic patch with tests which accomplishes your request. Currently, it defaults to None if no item failed, but probably it can be set only when something fails the predicate (and the user will check using hasattr(t, 'last') ).

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31647/itertools_takewhile.patch

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

From report at bugs.python.org  Sat Sep  7 17:34:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Sep 2013 15:34:27 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1378568067.77.0.401095284182.issue5907@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is very surprising that evaling the repr doesn't work, since struct_time is documented to have a named tuple interface, and evaling the repr for a namedtuple works.  So hopefully fixing issue 1820 will also fix this.

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

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

From report at bugs.python.org  Sat Sep  7 17:35:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 15:35:49 +0000
Subject: [issue18961] Non-UTF8 encoding line
Message-ID: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a file which is accepted by Python interpreter but is rejected by the tokenize module.

$ ./python nonutf8_coding_line.py 
$ ./python -m tokenize nonutf8_coding_line.py 
nonutf8_coding_line.py: error: invalid or missing encoding declaration for 'nonutf8_coding_line.py'

Python itself checks that a line is UTF-8 encoded only if not found a magic comment. The tokenize module checks it before searching (issue14629).

----------
components: Interpreter Core, Library (Lib)
files: nonutf8_coding_line.py
messages: 197169
nosy: Arfrever, benjamin.peterson, brett.cannon, eric.snow, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Non-UTF8 encoding line
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31648/nonutf8_coding_line.py

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

From report at bugs.python.org  Sat Sep  7 17:36:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 15:36:32 +0000
Subject: [issue18961] Non-UTF8 encoding line
In-Reply-To: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>
Message-ID: <1378568192.74.0.421772814603.issue18961@psf.upfronthosting.co.za>


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


----------
nosy: +meador.inge

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

From report at bugs.python.org  Sat Sep  7 17:37:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Sep 2013 15:37:38 +0000
Subject: [issue18952] Fix test.support.open_urlresource (support package
 regression)
In-Reply-To: <1378527733.08.0.636104620502.issue18952@psf.upfronthosting.co.za>
Message-ID: <1378568258.09.0.673479678219.issue18952@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

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

From report at bugs.python.org  Sat Sep  7 17:39:51 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Sep 2013 15:39:51 +0000
Subject: [issue18952] Fix test.support.open_urlresource (support package
 regression)
In-Reply-To: <1378527733.08.0.636104620502.issue18952@psf.upfronthosting.co.za>
Message-ID: <1378568391.12.0.849022473572.issue18952@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I was going to go with the "move the directory" solution, but realised that would mean existing checkouts end up downloading the data files again, and also with a stale copy of the data cluttering them up.

So adjusting the support module for the different relative path seems like the better option - I'll apply that one tomorrow (well, technically, later today...)

----------

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

From report at bugs.python.org  Sat Sep  7 18:24:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 16:24:36 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
In-Reply-To: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>
Message-ID: <1378571076.94.0.182289458187.issue18821@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oscar, did you considered itertools.groupby()? Perhaps it better meets your needs.

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

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

From report at bugs.python.org  Sat Sep  7 18:38:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 16:38:41 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378571921.1.0.108154830064.issue18829@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

When specify an empty string error message is confusing too:

$ ./python -c 'import csv; reader = csv.reader("foo", delimiter="")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: delimiter must be set

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

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

From report at bugs.python.org  Sat Sep  7 18:59:58 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Sat, 07 Sep 2013 16:59:58 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
In-Reply-To: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>
Message-ID: <1378573198.37.0.95588433289.issue18903@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I believe HFS is case-preserving as well, but it also can be configured to be case-sensitive.  I'm not a Mac owner though so don't take my word for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18903>
_______________________________________

From report at bugs.python.org  Sat Sep  7 19:56:37 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Sep 2013 17:56:37 +0000
Subject: [issue18905] pydoc -p 0 says the server is available at localhost:0
In-Reply-To: <1378140560.28.0.729434187467.issue18905@psf.upfronthosting.co.za>
Message-ID: <1378576597.68.0.330344980922.issue18905@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18905>
_______________________________________

From report at bugs.python.org  Sat Sep  7 20:26:28 2013
From: report at bugs.python.org (Wouter Bolsterlee)
Date: Sat, 07 Sep 2013 18:26:28 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
Message-ID: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>


New submission from Wouter Bolsterlee:

The heapq.merge() function merges multiple sorted iterables into a single sorted output.  The function uses a heap queue that is repeatedly looped over until it has generated all output.

If only a single iterable is passed to heapq.merge(), the heap will have len(h) == 1, which means the looping and heap manipulation just degrades to a convoluted "yield from iterables[0]". This negatively impacts performance. The attached patch adds a short-circuit for this single input case.

The behaviour of the function remains unchanged:

>>> list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
[0, 1, 2, 3, 4, 5, 5, 7, 8, 10, 15, 20, 25]
>>> list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
[0, 1, 2, 3, 4, 5, 5, 7, 8, 10, 15, 20, 25]

For multiple inputs, there is no measurable performance difference (measured
using IPython's %timeit). Without patch:

>>> %timeit list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.7 ?s per loop
>>> %timeit list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.4 ?s per loop
>>> %timeit list(merge_before([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.5 ?s per loop

With patch:

>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.7 ?s per loop
>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.6 ?s per loop
>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.6 ?s per loop
>>> %timeit list(merge_after([1,3,5,7], [0,2,4,8], [5,10,15,20], [], [25]))
100000 loops, best of 3: 13.8 ?s per loop

The real performance gain is of course when only a single iterable is passed. Without patch:

>>> %timeit for x in merge_before(range(10000)): pass
100 loops, best of 3: 2.65 ms per loop
>>> %timeit for x in merge_before(range(10000)): pass
100 loops, best of 3: 2.52 ms per loop
>>> %timeit for x in merge_before(range(10000)): pass
100 loops, best of 3: 2.51 ms per loop

With patch:

>>> %timeit for x in merge_after(range(10000)): pass
1000 loops, best of 3: 604 ?s per loop
>>> %timeit for x in merge_after(range(10000)): pass
1000 loops, best of 3: 609 ?s per loop
>>> %timeit for x in merge_after(range(10000)): pass
1000 loops, best of 3: 603 ?s per loop

This is a ~4x speedup for an input consisting of 10000 items. Compared to plain iteration:

>>> %timeit for x in range(10000): pass
1000 loops, best of 3: 263 ?s per loop
>>> %timeit for x in range(10000): pass
1000 loops, best of 3: 268 ?s per loop
>>> %timeit for x in range(10000): pass
1000 loops, best of 3: 273 ?s per loop

Without the patch, heapq.merge() is ~10x as slow as plain iteration. With the patch, this is reduced to ~2.5x.

(Note: all testing done using Python 3.3.2 on a 64bit Linux machine.)

----------
components: Library (Lib)
files: heapq-merge-single-input-optimization.patch
keywords: patch
messages: 197174
nosy: wbolster
priority: normal
severity: normal
status: open
title: Add special case for single iterator in heapq.merge function
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file31649/heapq-merge-single-input-optimization.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sat Sep  7 20:30:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 18:30:15 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <3cXPMB3CYgz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset d5c5ac33b9a1 by Senthil Kumaran in branch '2.7':
os.isatty is not Unix only. Correct the wrong documentation.
http://hg.python.org/cpython/rev/d5c5ac33b9a1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Sat Sep  7 20:31:21 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 07 Sep 2013 18:31:21 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1378578681.07.0.793751651121.issue18553@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I have corrected the documentation. Thanks for raising this issue, anatoly techtonik.

----------
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Sat Sep  7 20:32:00 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 18:32:00 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378578720.98.0.225343898764.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

New patch threadstate_join_5.patch adds more testing of is_alive().

An inelegance I don't care about (but someone might):  if join() is called with a timeout, and the Python part of the thread ends before the timeout expires (_stopped gets set), then a _non_-blocking attempt to acquire _tstate_lock is made, and join() returns regardless of the outcome.  So, with a timeout, it's possible for join() to return before the C part of the thread is done even if the timeout isn't yet exhausted.

That's unlikely, and I don't see that it makes any difference.  Anyone doing a join() with a timeout has to be aware that they have no idea whether the thread is done when join() returns, and do another join() or check is_alive() later.

I'd rather not complicate the code to wait longer for _tstate_lock in this case.

----------
Added file: http://bugs.python.org/file31650/threadstate_join_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 20:59:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 18:59:24 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378580364.86.0.402305781856.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Anyone doing a join() with a timeout has to be aware that they have no 
> idea whether the thread is done when join() returns, and do another
> join() or check is_alive() later.

Agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 21:25:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 19:25:20 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378581920.1.0.598164151837.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I like threadstate_join_5.patch, but I got the following failure when running the test suite:

======================================================================
FAIL: test_is_alive_after_fork (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 478, in test_is_alive_after_fork
    self.assertEqual(0, status)
AssertionError: 0 != 256

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 21:31:43 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 07 Sep 2013 19:31:43 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1378582303.59.0.265728829091.issue18800@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

How does this simple patch sound?

----------
keywords: +patch
nosy: +orsenthil
Added file: http://bugs.python.org/file31651/18800.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Sat Sep  7 21:34:42 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 19:34:42 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378582482.75.0.662917876953.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Ah!  I'm running on Windows, where all fork() tests are skipped.  Can you fix it?  My prejudice is that anyone mixing threads with fork() should be shot for the good of humanity <0.7 wink>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 21:37:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 19:37:15 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378582635.29.0.563209705085.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, the fix is to reinitialize the lock (in the surviving thread) or yank it (in the other threads). Patch attached.

----------
Added file: http://bugs.python.org/file31652/threadstate_join_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 21:54:08 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 19:54:08 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378583648.91.0.551545803904.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Cool!  What could possibly go wrong?  ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 22:00:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 20:00:53 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378584053.64.0.664860384987.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, do you think the patch is finally ready? If so, I'm gonna commit (unless you'd rather do it yourself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 22:23:57 2013
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 07 Sep 2013 20:23:57 +0000
Subject: [issue1065986] Fix pydoc crashing on unicode strings
Message-ID: <1378585437.26.0.449627730638.issue1065986@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1065986>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:12:38 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 21:12:38 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378588358.26.0.279575228225.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

If would be nice if Tamas could test it in his application, since we're not actually testing Py_EndInterpreter.  But, ya, commit it!  If it doesn't work for Tamas, we can start over again ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:13:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 21:13:20 +0000
Subject: [issue18206] license url in site.py should always use X.Y.Z form of
 version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <3cXSzM4nlGz7Ll3@mail.python.org>


Roundup Robot added the comment:

New changeset a723adeb1f47 by Senthil Kumaran in branch '3.3':
Fix License URL display and add test to check for license url presence.
http://hg.python.org/cpython/rev/a723adeb1f47

New changeset 12aaf64feca2 by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/12aaf64feca2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:16:06 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 07 Sep 2013 21:16:06 +0000
Subject: [issue18206] license url in site.py should always use X.Y.Z form of
 version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1378588566.39.0.6009495125.issue18206@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed in the 3.3 and 3.4.

3.3 - changeset a723adeb1f47
3.4 - changeset 12aaf64feca2
3.4 - (Fixed a merge conflict) changeset 6ecdf2b3192b

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:29:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 21:29:30 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378589370.91.0.857576463749.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, we *can* add a test for the race condition. Patch attached :-)

----------
Added file: http://bugs.python.org/file31653/subinterp_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:32:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Sep 2013 21:32:00 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
Message-ID: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>


New submission from Ned Deily:

======================================================================
ERROR: test_above_fd_setsize (test.test_selectors.PollSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/support/__init__.py", line 485, in wrapper
    return func(*args, **kw)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_selectors.py", line 312, in test_above_fd_setsize
    resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
ValueError: current limit exceeds maximum limit

======================================================================
ERROR: test_above_fd_setsize (test.test_selectors.KqueueSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/support/__init__.py", line 485, in wrapper
    return func(*args, **kw)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_selectors.py", line 312, in test_above_fd_setsize
    resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))
ValueError: current limit exceeds maximum limit

----------------------------------------------------------------------
Ran 58 tests in 8.080s

FAILED (errors=2, skipped=12)

Looking at the OS X man page for setrlimit(2), it appears the test's strategy of trying to set the soft RLIMIT_NOFILE to the hard RLIMIT_NOFILE ceiling will fail on OS X (at least) if the hard limit is infinite:

>>> import resource
>>> resource.getrlimit(resource.RLIMIT_NOFILE)
(2560, 9223372036854775807)

>From the man page:
COMPATIBILITY
     setrlimit() now returns with errno set to EINVAL in places that historically
     succeeded.  It no longer accepts "rlim_cur = RLIM_INFINITY" for RLIM_NOFILE.
     Use "rlim_cur = min(OPEN_MAX, rlim_max)".

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/setrlimit.2.html

----------
components: Tests
messages: 197189
nosy: ned.deily, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: test_selectors test_above_fd_setsize cases fail on OS X due to infinite hard limit
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:36:04 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 21:36:04 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378589764.55.0.52686219023.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Excellent - ship it! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:39:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Sep 2013 21:39:16 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <3cXTYJ0LX1z7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset d52b68edbca6 by Antoine Pitrou in branch 'default':
Issue #18808: Thread.join() now waits for the underlying thread state to be destroyed before returning.
http://hg.python.org/cpython/rev/d52b68edbca6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:45:31 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Sep 2013 21:45:31 +0000
Subject: [issue18964] test_tcl fails when _tkinter linked with Tcl 8.4
Message-ID: <1378590331.21.0.150230107781.issue18964@psf.upfronthosting.co.za>


New submission from Ned Deily:

The 32bit-only OS X installer links with Tcl/Tk 8.4 as these are the only supported native (Aqua) versions on older supported systems (OS X 10.5 Leopard and earlier).  These failures are also appearing on the Tiger (10.4) buildbots.

$ /usr/local/bin/python3.4 -c 'import tkinter;print(tkinter.TclVersion)'
8.4
$ /usr/local/bin/python3.4 -m test -w -uall test_tcl
[1/1] test_tcl
test test_tcl failed -- multiple errors occurred; run in verbose mode for details
1 test failed:
    test_tcl
Re-running failed tests in verbose mode
Re-running test 'test_tcl' in verbose mode
testCall (test.test_tcl.TclTest) ... ok
testCallException (test.test_tcl.TclTest) ... ok
testCallException2 (test.test_tcl.TclTest) ... ok
testEval (test.test_tcl.TclTest) ... ok
testEvalException (test.test_tcl.TclTest) ... ok
testEvalException2 (test.test_tcl.TclTest) ... ok
testEvalFile (test.test_tcl.TclTest) ... ok
testEvalFileException (test.test_tcl.TclTest) ... ok
testGetVar (test.test_tcl.TclTest) ... ok
testGetVarArray (test.test_tcl.TclTest) ... ok
testGetVarArrayException (test.test_tcl.TclTest) ... ok
testGetVarException (test.test_tcl.TclTest) ... ok
testLoadWithUNC (test.test_tcl.TclTest) ... skipped 'Requires Windows'
testPackageRequireException (test.test_tcl.TclTest) ... ok
testSetVar (test.test_tcl.TclTest) ... ok
testSetVarArray (test.test_tcl.TclTest) ... ok
testUnsetVar (test.test_tcl.TclTest) ... ok
testUnsetVarArray (test.test_tcl.TclTest) ... ok
testUnsetVarException (test.test_tcl.TclTest) ... ok
test_passing_values (test.test_tcl.TclTest) ... ok
test_split (test.test_tcl.TclTest) ... ERROR
test_splitlist (test.test_tcl.TclTest) ... ERROR
testFlattenLen (test.test_tcl.TkinterTest) ... ok
test_huge_string (test.test_tcl.BigmemTclTest) ... skipped 'needs UINT_MAX < SIZE_MAX'

======================================================================
ERROR: test_split (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_tcl.py", line 237, in test_split
    (call('dict', 'create', 12, '\u20ac', b'\xe2\x82\xac', (3.4,)),
_tkinter.TclError: invalid command name "dict"

======================================================================
ERROR: test_splitlist (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/test/test_tcl.py", line 203, in test_splitlist
    (call('dict', 'create', 1, '\u20ac', b'\xe2\x82\xac', (3.4,)),
_tkinter.TclError: invalid command name "dict"

----------------------------------------------------------------------
Ran 24 tests in 7.573s

FAILED (errors=2, skipped=2)
test test_tcl failed

----------
components: Tests, Tkinter
keywords: buildbot
messages: 197192
nosy: ned.deily, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tcl fails when _tkinter linked with Tcl 8.4
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18964>
_______________________________________

From report at bugs.python.org  Sat Sep  7 23:50:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 21:50:37 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378590637.47.0.17283311169.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, this should be finally fixed!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 00:32:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Sep 2013 22:32:21 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>
Message-ID: <1378593141.55.0.388686838068.issue18963@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue issue 17409.

The code isn't setting it to RLIM_INFINITY explicitly, though, so this must mean that OSX is reporting an infinite hard limit when the hard limit is not in fact infinite.  Seems like this is an OSX bug that we will have to work around somehow.  Maybe in getrlimit, by doing the max(OPEN_MAX, rlim_max) dance suggested by the osx man page.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:03:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Sep 2013 23:03:26 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378595006.3.0.559053152432.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ha, apparently test_is_alive_after_fork still fails on old Linux kernels:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/8562
http://buildbot.python.org/all/builders/x86%20RHEL%206%203.x/builds/2665

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:09:45 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Sep 2013 23:09:45 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378595385.78.0.735567012714.issue18873@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Nasty bug. Running a file with 'coding=0', a quite legitimate assignment statement, causes Idle to close, with LookupError, leading to SyntaxError, reported on the console if there is one ('crash' otherwise). (Idle closing is a separate problem, with an issue, from the misinterpretation of 'coding'.)

Loading such a file works with a warning that should not be there.

Adding # leads to "SyntaxError: unknown encoding" in a message box, without closing Idle. I presume this is to be expected and is proper. There is also a warning on loading.

The code patch adds '^[ \t\f]' to the re. \f = FormFeed? Should that really be there? The PEP patch instead adds '^[ \t\v]', \v= VerticalTab? Same question, and why the difference?

Your other changes to IOBinding.coding_spec look correct and fix a couple of bugs in the function (searching all lines for the coding cookie, mangling a line without a line end).

Someone else should review the other code changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:17:07 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Sep 2013 23:17:07 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378595827.13.0.147181157408.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Figures.  That's why I wanted your name on the blamelist ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:24:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Sep 2013 23:24:03 +0000
Subject: [issue18957] PYTHONFAULTHANDLER enables faulthandler when the
 variable is empty
In-Reply-To: <1378548727.3.0.980062926119.issue18957@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZgKu8faUm71goPS1xFgK_p3CQTyFgbdDttwKYPWTjRMg@mail.gmail.com>


STINNER Victor added the comment:

Yes. Maybe also with a test. The doc of all env vars must be checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18957>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:26:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 23:26:28 +0000
Subject: [issue18037] 2to3 passes through string literal which causes
 SyntaxError in 3.x
In-Reply-To: <1369259204.14.0.48841389768.issue18037@psf.upfronthosting.co.za>
Message-ID: <1378596388.16.0.509191486944.issue18037@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch against 2.7.

What is the policy about changing 2to3 in 3.x?

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31654/2to3_escape_u-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18037>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:29:53 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 Sep 2013 23:29:53 +0000
Subject: [issue18037] 2to3 passes through string literal which causes
 SyntaxError in 3.x
In-Reply-To: <1369259204.14.0.48841389768.issue18037@psf.upfronthosting.co.za>
Message-ID: <1378596593.79.0.912028039789.issue18037@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

You can change 2to3 in 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18037>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:34:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 23:34:33 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378596873.59.0.718768181115.issue18873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The code patch adds '^[ \t\f]' to the re. \f = FormFeed? Should that really be there? The PEP patch instead adds '^[ \t\v]', \v= VerticalTab? Same question, and why the difference?

Good catch. I missed in the PEP patch, it should be '\f' ('\014') in all cases.

Yes, it should be. It corresponds to the code in Parser/tokenizer.c.

----------
Added file: http://bugs.python.org/file31655/pep0263_regex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:34:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 23:34:59 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1378596899.78.0.512714272256.issue18873@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file31646/pep0263_regex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:44:33 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Sep 2013 23:44:33 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1378595827.13.0.147181157408.issue18808@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d0VhtJjMeU07LGVnuwDx8SxcbconFZwbQF7Nf01kFC_g@mail.gmail.com>


Nick Coghlan added the comment:

You mean I actually need to pay proper attention now? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:54:57 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 07 Sep 2013 23:54:57 +0000
Subject: [issue16662] load_tests not invoked in package/__init__.py
In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za>
Message-ID: <1378598097.35.0.692183456205.issue16662@psf.upfronthosting.co.za>


Michael Foord added the comment:

I get a couple of test failures with this patch applied:

======================================================================
ERROR: test_find_tests (unittest.test.test_discovery.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/cpython/Lib/unittest/test/test_discovery.py", line 72, in test_find_tests
    suite = list(loader._find_tests(top_level, 'test*.py'))
  File "/compile/cpython/Lib/unittest/loader.py", line 298, in _find_tests
    tests = self.loadTestsFromModule(package, use_load_tests=False)
TypeError: <lambda>() got an unexpected keyword argument 'use_load_tests'

======================================================================
FAIL: test_find_tests_with_package (unittest.test.test_discovery.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/compile/cpython/Lib/unittest/test/test_discovery.py", line 137, in test_find_tests_with_package
    ['load_tests', 'test_directory2' + ' module tests'])
AssertionError: Lists differ: ['a_directory module tests', '... != ['load_tests', 'test_directory...

First differing element 0:
a_directory module tests
load_tests

First list contains 1 additional elements.
First extra element 2:
test_directory2 module tests

- ['a_directory module tests', 'load_tests', 'test_directory2 module tests']
?  ----------------------------

+ ['load_tests', 'test_directory2 module tests']

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16662>
_______________________________________

From report at bugs.python.org  Sun Sep  8 01:55:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Sep 2013 23:55:38 +0000
Subject: [issue18964] test_tcl fails when _tkinter linked with Tcl 8.4
In-Reply-To: <1378590331.21.0.150230107781.issue18964@psf.upfronthosting.co.za>
Message-ID: <1378598138.43.0.142074184183.issue18964@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed. The dict command was added in 8.5. Thanks for reminder of this. Here is a patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31656/test_tcl_84.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18964>
_______________________________________

From report at bugs.python.org  Sun Sep  8 02:06:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 00:06:39 +0000
Subject: [issue18965] 2to3 can produce illegal bytes literals
Message-ID: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In Python 2 string literals are allowed to contain non-ascii characters. In Python 3 bytes literals can contains only ascii characters, non-ascii characters should be escaped with \xXX. However 2to3 doesn't change b'...' literals and produces illegal code.

I propose new fixer which escapes non-ascii bytes in bytes literals. Here is a patch (without tests yet).

----------
components: 2to3 (2.x to 3.x conversion tool)
files: 2to3_nonascii_bytes.patch
keywords: patch
messages: 197205
nosy: serhiy.storchaka, vinay.sajip
priority: normal
severity: normal
stage: patch review
status: open
title: 2to3 can produce illegal bytes literals
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31657/2to3_nonascii_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18965>
_______________________________________

From report at bugs.python.org  Sun Sep  8 02:25:50 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Sep 2013 00:25:50 +0000
Subject: [issue18964] test_tcl fails when _tkinter linked with Tcl 8.4
In-Reply-To: <1378590331.21.0.150230107781.issue18964@psf.upfronthosting.co.za>
Message-ID: <1378599950.94.0.666467818501.issue18964@psf.upfronthosting.co.za>


Ned Deily added the comment:

LGTM. And, with the patch, test_tcl no longer fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18964>
_______________________________________

From report at bugs.python.org  Sun Sep  8 02:42:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 00:42:24 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378600944.04.0.0822031010447.issue18808@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Slavek - one you may want to take a look at this. Antoine and Tim are trying to fix a race condition with the destruction of thread state objects, but the current fix isn't playing nice on older Linux kernels (including the one in RHEL 6).

----------
nosy: +bkabrda
stage: committed/rejected -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 02:52:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 00:52:47 +0000
Subject: [issue18033] Example for Profile Module shows incorrect method
In-Reply-To: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za>
Message-ID: <3cXYrX5kLWz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 93018d47793f by Senthil Kumaran in branch '2.7':
Correct Profile class usage example. Addresses issue #18033 .
http://hg.python.org/cpython/rev/93018d47793f

New changeset ab4d3ccb92e6 by Senthil Kumaran in branch '3.3':
Correct Profile class usage example. Addresses issue #18033.
http://hg.python.org/cpython/rev/ab4d3ccb92e6

New changeset 88182b388bae by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/88182b388bae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18033>
_______________________________________

From report at bugs.python.org  Sun Sep  8 02:53:55 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Sep 2013 00:53:55 +0000
Subject: [issue18033] Example for Profile Module shows incorrect method
In-Reply-To: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za>
Message-ID: <1378601635.25.0.0324123635186.issue18033@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I consolidated the patches and example and have committed them to 2.7, 3.3 and 3.4. Thanks for your contributions.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18033>
_______________________________________

From report at bugs.python.org  Sun Sep  8 03:20:27 2013
From: report at bugs.python.org (Piet van Oostrum)
Date: Sun, 08 Sep 2013 01:20:27 +0000
Subject: [issue18966] Threads within multiprocessing Process terminate early
Message-ID: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za>


New submission from Piet van Oostrum:

When a process started as a multiprocessing Process spawns a thread, it doesn't wait until the thread terminates. It terminates the thread early when the main thread of the process terminates, as if the thread would be daemonic (it isn't).

It may sound a bit weird to start a Thread within multiprocessing, but it isn't prohibited. Neither is this behavior documented.

In the attached program the thread doesn't complete. However when the mythread.join() statement is uncommented it does run to completion.

----------
components: Library (Lib)
files: processthread.py
messages: 197210
nosy: pietvo
priority: normal
severity: normal
status: open
title: Threads within multiprocessing Process terminate early
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file31658/processthread.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18966>
_______________________________________

From report at bugs.python.org  Sun Sep  8 04:04:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 02:04:41 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
Message-ID: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

We keep muttering about coming up with a less conflict-prone approach to Misc/NEWS updates, without ever settling on a concrete solution.

For the last big discussion on this, see the subthread starting at https://mail.python.org/pipermail/python-committers/2013-May/002554.html

----------
messages: 197211
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Find a less conflict prone approach to Misc/NEWS
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Sun Sep  8 04:13:32 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 08 Sep 2013 02:13:32 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1378606412.68.0.590105230336.issue18937@psf.upfronthosting.co.za>


Michael Foord added the comment:

The patch and approach look good to me (with docs needed).

Note, personally I would not use a leading underscore for the assertion methods (in the tests) _assertNoStderr and _assertLogRecords.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18937>
_______________________________________

From report at bugs.python.org  Sun Sep  8 04:23:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 02:23:24 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <3cXbs71d88z7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 5cfd7b2eb994 by Tim Peters in branch 'default':
Issue 18808:  blind attempt to repair some buildbot failures.
http://hg.python.org/cpython/rev/5cfd7b2eb994

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 04:24:14 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 02:24:14 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378607053.99.0.758336786203.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Just pushed 5cfd7b2eb994 in a poke-and-hope blind attempt to repair the annoying ;-) buildbot failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 04:51:19 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 02:51:19 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378608679.24.0.379120697112.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Doesn't look like 5cfd7b2eb994 is going to fix it :-(  So I'll revert it.  Attaching the patch as blind.patch.  After that patch, is_alive() only looks at Thread data members, where ._is_stopped "is obviously" True, and ._tstate_lock "is obviously" None, both forced by threading.py's _after_fork() function.  No theory as to how that can be screwed up.

----------
Added file: http://bugs.python.org/file31659/blind.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 04:51:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 02:51:23 +0000
Subject: [issue18952] Fix test.support.open_urlresource (support package
 regression)
In-Reply-To: <1378527733.08.0.636104620502.issue18952@psf.upfronthosting.co.za>
Message-ID: <3cXcTP6sG7z7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 23770d446c73 by Nick Coghlan in branch '3.3':
Close #18952: correctly download test support data
http://hg.python.org/cpython/rev/23770d446c73

New changeset cb8dabc113b8 by Nick Coghlan in branch 'default':
Merge #18952 fix from 3.3
http://hg.python.org/cpython/rev/cb8dabc113b8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18952>
_______________________________________

From report at bugs.python.org  Sun Sep  8 05:01:11 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 03:01:11 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378609271.01.0.93680085188.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Weird!  The Ubuntu box passed test_is_alive_after_fork on its /second/ run with the patch:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/8564/steps/test/logs/stdio

The other box passed all tests:

http://buildbot.python.org/all/builders/x86%20RHEL%206%203.x/builds/2667

So I won't revert it after all - but the Ubuntu box's behavior is still major mystery :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 05:05:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 03:05:35 +0000
Subject: [issue18968] Find a way to detect regressions in test execution
Message-ID: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 18952 (fixed in http://hg.python.org/cpython/rev/23770d446c73) was another case where a test suite change resulted in tests not be executed as expected, but this wasn't initially noticed since it didn't *fail* the tests, it just silently skipped them.

We've had similar issues in the past, due to test name conflicts (so the second test shadowed the first), to old regrtest style test discovery missing a class name from the test list, and to incorrect skip conditions on platform specific tests.

Converting "unexpected skips" to a failure isn't enough, since these errors occur at a narrower scope than entire test modules.

I'm not sure on what *would* work, though. Perhaps collecting platform specific coverage stats for the test suite itself and looking for regressions?

----------
messages: 197218
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Find a way to detect regressions in test execution
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Sun Sep  8 05:05:57 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 03:05:57 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1378609557.02.0.578260864342.issue18968@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Find a way to detect regressions in test execution -> Find a way to detect incorrectly skipped tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Sun Sep  8 05:34:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 03:34:23 +0000
Subject: [issue14971] (unittest) loadTestsFromName does not work on method
 with a decorator
In-Reply-To: <1338490939.51.0.536223048687.issue14971@psf.upfronthosting.co.za>
Message-ID: <3cXdR26FQNz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 78a5de507f19 by Michael Foord in branch '2.7':
Closes issue 14971.
http://hg.python.org/cpython/rev/78a5de507f19

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14971>
_______________________________________

From report at bugs.python.org  Sun Sep  8 05:53:43 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 08 Sep 2013 03:53:43 +0000
Subject: [issue18915] ssl.wrap_socket,
 pass in certfile and keyfile as PEM strings
In-Reply-To: <1378250119.17.0.25988823326.issue18915@psf.upfronthosting.co.za>
Message-ID: <1378612423.39.0.75314994336.issue18915@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

This issue is duplicate for #16487

----------
nosy: +asvetlov
resolution:  -> duplicate
status: open -> closed
superseder:  -> Allow ssl certificates to be specified from memory rather than files.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18915>
_______________________________________

From report at bugs.python.org  Sun Sep  8 06:06:16 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 04:06:16 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378613176.75.0.650210017633.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Well, the next time the Ubuntu box ran the tests, it was clean all the way. So it's fixed!  Despite that it isn't ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 06:51:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 04:51:41 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378615901.42.0.388327364883.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

For what it is worth, I haven't had a non-trivial merge conflict on Misc/NEWS for quite some time now.  It seems to me that they are much rarer than they were with svn.  (By 'trivial' I mean that the conflicts I see is that there's a new entry on 3.4 that wasn't in 3.3, and the conflict is just the addition of the new entry in the merge, which is trivial to fix.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Sun Sep  8 06:53:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 04:53:50 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378616030.4.0.0970628240792.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

Then, again, I pretty much only do Library fixes.  Maybe 'Core and builtins' fixes get messier because of the proximity of the date and version-specific header?  That should be easy enough to fix....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Sun Sep  8 06:56:15 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 08 Sep 2013 04:56:15 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378616175.88.0.162537148742.issue18962@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sun Sep  8 06:58:56 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Sep 2013 04:58:56 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378616336.77.0.222471624334.issue18962@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

At first glance, this looks reasonable.  I'll give it a more thorough look shortly.

----------
assignee:  -> rhettinger
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sun Sep  8 07:59:47 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 08 Sep 2013 05:59:47 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378619987.43.0.202447023646.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

Changing the test from

    if argument_values is not action.default:

to 

    if argument_values is not action.default and \
        (action.default is None or argument_values != action.default):

makes the behavior more consistent.  Strings and large ints behave like small ints, matching the default and not counting as "present"

Simply using `argument_values != action.default` was not sufficient, since it raised errors in existing test cases (such as ones involving Nones).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Sun Sep  8 08:20:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 06:20:14 +0000
Subject: [issue18438] Obsolete url in comment inside decimal module
In-Reply-To: <1373686911.48.0.750703855786.issue18438@psf.upfronthosting.co.za>
Message-ID: <3cXj6Q1xnmz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 44ed0cd3dc6d by Senthil Kumaran in branch '2.7':
Fix the dead link of IEEE_854-1987 standard with the Wikipedia entry.
http://hg.python.org/cpython/rev/44ed0cd3dc6d

New changeset 0eef1670f316 by Senthil Kumaran in branch '3.3':
Fix the dead link of IEEE_854-1987 standard with the Wikipedia entry.
http://hg.python.org/cpython/rev/0eef1670f316

New changeset 44fa59286012 by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/44fa59286012

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18438>
_______________________________________

From report at bugs.python.org  Sun Sep  8 08:21:09 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Sep 2013 06:21:09 +0000
Subject: [issue18438] Obsolete url in comment inside decimal module
In-Reply-To: <1373686911.48.0.750703855786.issue18438@psf.upfronthosting.co.za>
Message-ID: <1378621269.08.0.689448715937.issue18438@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed that in 2.7,3.3 and 3.4

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18438>
_______________________________________

From report at bugs.python.org  Sun Sep  8 08:55:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 Sep 2013 06:55:01 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1378623301.68.0.713762244503.issue18968@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Run the test suite both with and without the patch, and compare the results.  Additional skipped tests, additional failed tests, or less than the number of expected additional tests signal a problem.

The first two should be automatable, the last depends on the human paying attention.  ;)

This should at least deal with problems created by a patch.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Sun Sep  8 09:24:48 2013
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Sun, 08 Sep 2013 07:24:48 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1378625088.49.0.379275710994.issue9974@psf.upfronthosting.co.za>


Dwayne Litzenberger added the comment:

@amk: I'd appreciate it if you did. :)

I ran into this bug while writing some code that converts b"..." into "..." in PyCrypto's setup.py script (for backward compatibility with Python 2.5 and below).

----------
nosy: +DLitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Sun Sep  8 09:37:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 07:37:00 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378616030.4.0.0970628240792.issue18967@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e7X1zFsgdGmdWFsL2xt1Jq17gJou2sfJzOr+fXOSQzuw@mail.gmail.com>


Nick Coghlan added the comment:

The one I ran into earlier today tried to merge the entirety of the
3.3.x RC NEWS into the 3.4 NEWS :P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Sun Sep  8 10:37:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 08:37:38 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <1378593141.55.0.388686838068.issue18963@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0rv+YZTQdjWz4dC-YwobsMFjOGVNqnRD5aikc429w=Xg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> R. David Murray added the comment:
>
> See also issue issue 17409.
>
> The code isn't setting it to RLIM_INFINITY explicitly, though, so this must mean that OSX is reporting an infinite hard limit when the hard limit is not in fact infinite.  Seems like this is an OSX bug that we will have to work around somehow.

Indeed.
I saw this while testing on "custom" buildbots, and opted for the
simplest solution: I added a @require_mac_version decorator, hoping
this would be solved in recent OSX versions. Apparently not :)

As a simple check, does the following work on OSX ?
>>> limit = resource.getrlimit(resource.RLIMIT_NOFILE)
>>> resource.setrlimit(resource.RLIMIT_NOFILE, limit)

Does the attached patch solve this?

----------
keywords: +patch
Added file: http://bugs.python.org/file31660/selectors_osx.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________
-------------- next part --------------
diff -r 14972c999e80 Lib/test/test_selectors.py
--- a/Lib/test/test_selectors.py	Fri Sep 06 21:12:22 2013 +0200
+++ b/Lib/test/test_selectors.py	Sun Sep 08 10:28:48 2013 +0200
@@ -301,7 +301,6 @@
 
 class ScalableSelectorMixIn:
 
-    @support.requires_mac_ver(10, 5)
     @unittest.skipUnless(resource, "Test needs resource module")
     def test_above_fd_setsize(self):
         # A scalable implementation should have no problem with more than
@@ -313,7 +312,7 @@
             self.addCleanup(resource.setrlimit, resource.RLIMIT_NOFILE,
                             (soft, hard))
             NUM_FDS = hard
-        except OSError:
+        except (OSError, ValueError):
             NUM_FDS = soft
 
         # guard for already allocated FDs (stdin, stdout...)

From report at bugs.python.org  Sun Sep  8 10:59:14 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Sep 2013 08:59:14 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>
Message-ID: <1378630754.24.0.501183554425.issue18963@psf.upfronthosting.co.za>


Ned Deily added the comment:

"As a simple check, does the following work on OSX ?
 >>> limit = resource.getrlimit(resource.RLIMIT_NOFILE)
 >>> resource.setrlimit(resource.RLIMIT_NOFILE, limit)"

It doesn't produce an exception.

"Does the attached patch solve this?"

With the patch, test_selectors no longer fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:35:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 09:35:10 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <3cXnRK57qHz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 0e52b9f77dbf by Charles-Fran?ois Natali in branch 'default':
Issue #18934: Use poll/select-based selectors for multiprocessing.Connection,
http://hg.python.org/cpython/rev/0e52b9f77dbf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18934>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:35:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 09:35:11 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>
Message-ID: <3cXnRL3NBHz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 9ba1432fdc5a by Charles-Fran?ois Natali in branch 'default':
Issue #18963: Fix test_selectors.test_above_fd_setsize on OS X, where the
http://hg.python.org/cpython/rev/9ba1432fdc5a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:36:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 09:36:47 +0000
Subject: [issue18957] PYTHONFAULTHANDLER enables faulthandler when the
 variable is empty
In-Reply-To: <1378542841.95.0.330646753662.issue18957@psf.upfronthosting.co.za>
Message-ID: <3cXnTB4HXcz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 5c2cf4349adc by Victor Stinner in branch 'default':
Close #18957: The PYTHONFAULTHANDLER environment variable now only enables the
http://hg.python.org/cpython/rev/5c2cf4349adc

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18957>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:37:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Sep 2013 09:37:17 +0000
Subject: [issue18957] PYTHONFAULTHANDLER enables faulthandler when the
 variable is empty
In-Reply-To: <1378542841.95.0.330646753662.issue18957@psf.upfronthosting.co.za>
Message-ID: <1378633037.68.0.570306277447.issue18957@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Do you mean something like *this*?
> this -> the patch, pythonfaulthandler_env_var.patch.

Thanks for the patch, I combined it with other changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18957>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:48:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 09:48:10 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <3cXnkK4h09z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset b13cec63b495 by Victor Stinner in branch 'default':
Issue #18904: Improve os.get/set_inheritable() tests
http://hg.python.org/cpython/rev/b13cec63b495

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18904>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:48:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Sep 2013 09:48:52 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <1378633732.56.0.0772251897041.issue18904@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the report and the patch. I removed the duplicate test, but I also added new tests using fcntl and FD_CLOEXEC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18904>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:52:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 09:52:48 +0000
Subject: [issue18969] test suite: enable faulthandler timeout in assert_python
Message-ID: <1378633968.54.0.772886567193.issue18969@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, the test suite, as well as processes spawned by the script_helper.assert_python family, are run with faulthandler enabled.
That's great to debug crashes, but it would be even better if those processes were started with faulthandler's timeout:

1) Most deadlock-prone tests are run in child processes, so in case of deadlock, you don't get any trace:

http://buildbot.python.org/all/builders/AMD64 FreeBSD 10.0 3.x/builds/353/steps/test/logs/stdio
"""
[269/380] test_threading
Timeout (1:00:00)!
Thread 0x0000000801c06400:
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 1615 in _communicate_with_poll
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 1535 in _communicate
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/subprocess.py", line 945 in communicate
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/script_helper.py", line 36 in _assert_python
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/script_helper.py", line 55 in assert_python_ok
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 617 in assertScriptHasOutput
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 692 in test_4_joining_across_fork_in_worker_thread
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 496 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 535 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 79 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 1649 in _run_suite
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1683 in run_unittest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1275 in <lambda>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1276 in runtest_inner
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 965 in runtest
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 761 in main
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/regrtest.py", line 1560 in main_in_temp_cwd
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1
"""

Here, we just see that the main process is waiting for its child to complete, but we don't know anything about the child process stack.

2) As an added benefit, this would prevent dangling child processes: when the parent is killed, they're reparented to init, and can keep running arbitrarily long, consuming memory/CPU/process table entry (well, maybe the buildbot scripts kill the whole process group, I don't know).

----------
components: Tests
messages: 197239
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: test suite: enable faulthandler timeout in assert_python
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18969>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:54:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 09:54:00 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <3cXns32sk8z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset b7f6f6f59e91 by Victor Stinner in branch 'default':
Issue #18904: test_socket: add inheritance tests using fcntl and FD_CLOEXEC
http://hg.python.org/cpython/rev/b7f6f6f59e91

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18904>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:54:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 09:54:55 +0000
Subject: [issue18935] test_regrtest.test_timeout failure
In-Reply-To: <1378400398.96.0.0580722992203.issue18935@psf.upfronthosting.co.za>
Message-ID: <1378634095.16.0.435249347557.issue18935@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Anyone? (The patch is trivial, but I'm not familiar with regrtest).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18935>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:58:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Sep 2013 09:58:36 +0000
Subject: [issue18969] test suite: enable faulthandler timeout in assert_python
In-Reply-To: <1378633968.54.0.772886567193.issue18969@psf.upfronthosting.co.za>
Message-ID: <1378634316.58.0.44278594571.issue18969@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I see two options:

* faulthandler calls killpg(SIGABRT) on timeout to kill child processes (but it should ignore temporary the signal to not kill itself)
* use a timeout, but shorter than the global timeout, for child processes

Not all tests use script_helper. But this is probably a different issue ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18969>
_______________________________________

From report at bugs.python.org  Sun Sep  8 11:59:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Sep 2013 09:59:03 +0000
Subject: [issue18935] test_regrtest.test_timeout failure
In-Reply-To: <1378400398.96.0.0580722992203.issue18935@psf.upfronthosting.co.za>
Message-ID: <1378634343.0.0.139163634339.issue18935@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18935>
_______________________________________

From report at bugs.python.org  Sun Sep  8 12:21:36 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 10:21:36 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <3cXnRL3NBHz7LjR@mail.python.org>
Message-ID: <CAH_1eM2i6u2-8nLtiYa_0Z-KPz2qvhES08nhFSQKvTEdV58QHg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I knew this wouldn't be so easy with OS X...

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6916/steps/test/logs/stdio

======================================================================
ERROR: test_above_fd_setsize (test.test_selectors.PollSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py",
line 56, in testPartExecutor
    yield
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/case.py",
line 528, in doCleanups
    function(*args, **kwargs)
ValueError: not allowed to raise maximum limit

----------------------------------------------------------------------

Basically, we can't restore RLIMIT_NOFILE to its original value (from
the cleanup callback): since this works on Ned's machine, I assume
this has been fixed in recent OS X versions.
So I'll restore the requires_mac_vers() decorator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sun Sep  8 12:36:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 10:36:14 +0000
Subject: [issue18935] test_regrtest.test_timeout failure
In-Reply-To: <1378400398.96.0.0580722992203.issue18935@psf.upfronthosting.co.za>
Message-ID: <3cXpnn526xz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 2982ac8b45bc by Charles-Fran?ois Natali in branch 'default':
Issue #18935: Fix test_regrtest.test_timeout when built --without-threads (the
http://hg.python.org/cpython/rev/2982ac8b45bc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18935>
_______________________________________

From report at bugs.python.org  Sun Sep  8 12:36:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 10:36:15 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>
Message-ID: <3cXpnp3NC1z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset fa735675e485 by Charles-Fran?ois Natali in branch 'default':
Issue #18963: skip test_selectors.test_above_fd_setsize on older OS X versions.
http://hg.python.org/cpython/rev/fa735675e485

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sun Sep  8 12:42:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 10:42:52 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378636972.03.0.387118139573.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed the Ubuntu Shared buildbot started failing again. There's probably a timing-dependent behaviour here (which is why test_is_alive_after_fork() tries several times, after all).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:08:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 11:08:14 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378638494.85.0.0355846143947.issue18808@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think I've found the answer: the thread is sometimes already stopped by the time the child is forked, so it doesn't appear in _enumerate() anymore (it left the _active dict). Therefore its locks are not reset in _after_fork().

Oh, I also get the following sporadic failure which is triggered by slight change in semantics with Thread.join(timeout) :-)

======================================================================
FAIL: test_various_ops (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 113, in test_various_ops
    self.assertTrue(not t.is_alive())
AssertionError: False is not true

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:10:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Sep 2013 11:10:45 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378638645.09.0.66397100474.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Well, what about None?

$ python3 -c 'import csv; reader = csv.reader("foo", delimiter=None)'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: delimiter must be set

English grammatically speaking, we should get this kind of error:
ValueError: "delimiter" must be string, not None

But computer science-ly speaking, the exception message "delimiter must be set" is correct because setting null or None value to a variable can be considered as same as unsetting that variable, hence error message "must be set".

And I would argue the empty string can be considered as one of a kind with None in this case.

But we'll see other people's opinions. I am also not sure about this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:11:25 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 11:11:25 +0000
Subject: [issue18935] test_regrtest.test_timeout failure
In-Reply-To: <1378400398.96.0.0580722992203.issue18935@psf.upfronthosting.co.za>
Message-ID: <1378638685.09.0.198673156017.issue18935@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Committed.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18935>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:19:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 11:19:13 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <3cXqlN42Rcz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 74dc664ad699 by Antoine Pitrou in branch 'default':
Issue #18808 again: fix the after-fork logic for not-yet-started or already-stopped threads.
http://hg.python.org/cpython/rev/74dc664ad699

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:37:04 2013
From: report at bugs.python.org (koobs)
Date: Sun, 08 Sep 2013 11:37:04 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1378640224.48.0.419161815409.issue18418@psf.upfronthosting.co.za>


koobs added the comment:

For reference, this test is successfuly identifying failures on koobs-freebsd and koobs-freebsd10 buildbots:

======================================================================
FAIL: test_is_alive_after_fork (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 478, in test_is_alive_after_fork
    self.assertEqual(0, status)
AssertionError: 0 != 256

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:39:01 2013
From: report at bugs.python.org (koobs)
Date: Sun, 08 Sep 2013 11:39:01 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378640341.76.0.0600729189701.issue18808@psf.upfronthosting.co.za>


koobs added the comment:

Adding reference to failing tests on koobs-freebsd9 and koobs-freebsd10 buildbots:

======================================================================
FAIL: test_is_alive_after_fork (test.test_threading.ThreadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_threading.py", line 478, in test_is_alive_after_fork
    self.assertEqual(0, status)
AssertionError: 0 != 256

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:40:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 11:40:19 +0000
Subject: [issue18418] Thread.isAlive() sometimes True after fork
In-Reply-To: <1373408030.66.0.77258289483.issue18418@psf.upfronthosting.co.za>
Message-ID: <1378640419.54.0.354562841192.issue18418@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've identified a possible cause (and fix) for the sporadic test failures in 74dc664ad699. If the solution holds, it should be backported to 3.3 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18418>
_______________________________________

From report at bugs.python.org  Sun Sep  8 13:54:57 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 Sep 2013 11:54:57 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
In-Reply-To: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>
Message-ID: <1378641297.6.0.0370012960112.issue18903@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A possible complication is that at least in part, the same code (AutoComplete.py) is used for both attribute completion and filename completion. Attribute completion is always case sensitive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18903>
_______________________________________

From report at bugs.python.org  Sun Sep  8 14:14:44 2013
From: report at bugs.python.org (Wouter Bolsterlee)
Date: Sun, 08 Sep 2013 12:14:44 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378642484.2.0.326348227301.issue18962@psf.upfronthosting.co.za>


Wouter Bolsterlee added the comment:

An additional speedup would be to add a "if len(h) == 1" check inside the while loop, and just yield from the remaining iterator if a single iterable remains. This would also speed up merges with multiple inputs, as it doesn't do the whole heapreplace() loop for the last remaining iterable. Example: merge([], [], [], range(100000). This would involve some more refactoring inside the function though, since the current implementation only stores the .next() function for each iterable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sun Sep  8 14:14:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 12:14:52 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <3cXrzb3y9mz7Ljx@mail.python.org>


Roundup Robot added the comment:

New changeset aea58e1cae75 by Victor Stinner in branch 'default':
Issue #18904: test_os and test_socket use unittest.skipIf() to check if fcntl
http://hg.python.org/cpython/rev/aea58e1cae75

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18904>
_______________________________________

From report at bugs.python.org  Sun Sep  8 14:58:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Sep 2013 12:58:53 +0000
Subject: [issue18963] test_selectors test_above_fd_setsize cases fail on OS X
 due to infinite hard limit
In-Reply-To: <1378589520.51.0.514840120494.issue18963@psf.upfronthosting.co.za>
Message-ID: <1378645133.01.0.933345574512.issue18963@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Alright, it should be fixed now, thanks for the report.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18963>
_______________________________________

From report at bugs.python.org  Sun Sep  8 15:00:14 2013
From: report at bugs.python.org (Ben Finney)
Date: Sun, 08 Sep 2013 13:00:14 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1378645214.09.0.909458069395.issue12916@psf.upfronthosting.co.za>


Changes by Ben Finney <ben+python at benfinney.id.au>:


----------
nosy: +bignose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Sun Sep  8 15:36:31 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Sun, 08 Sep 2013 13:36:31 +0000
Subject: [issue18970] run_setup() behavior differs from cli invocation of
 setup.py
Message-ID: <1378647391.64.0.940770484425.issue18970@psf.upfronthosting.co.za>


New submission from Lukas Wunner:

The principle of least surprise suggests that run_setup() should behave equivalently to a command line invocation of setup.py. However there are currently (at least) two issues preventing this:


(a) When calling exec(), both a globals and a locals dict is passed.

According to the documentation: "If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition." [1] Consequence: "The scope of names defined in a class block is limited to the class block; it does not extend to the code blocks of methods". [2]

One example where this is relevant is the "MarkupSafe" PyPI package [3]: Its setup.py defines a class BuildFailed which is used in other methods defined in setup.py. Calling run_setup() with this setup.py will therefore fail. Calling setup.py from the command line works.

Solution: Only pass a globals dict to exec().


(b) The globals dict does not contain '__name__':'__main__'.

Many setup.py scripts use the idiomatic 'conditional script' stanza "if __name__ == '__main__'". An example is the "PyYAML" PyPI package. [4] In these cases, run_setup() will raise a RuntimeError exception ("'distutils.core.setup()' was never called").

Solution: Add '__name__':'__main__' to the globals dict.


Attached are patches to fix these issues in Python 2.6 to 3.4.


[1] http://docs.python.org/3/library/functions.html#exec
[2] http://docs.python.org/reference/executionmodel.html#naming-and-binding
[3] https://pypi.python.org/pypi/MarkupSafe
[4] https://pypi.python.org/pypi/PyYAML

----------
assignee: eric.araujo
components: Distutils
files: run_setup-py32-py33-py34.diff
keywords: patch
messages: 197259
nosy: eric.araujo, l, tarek
priority: normal
severity: normal
status: open
title: run_setup() behavior differs from cli invocation of setup.py
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31661/run_setup-py32-py33-py34.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18970>
_______________________________________

From report at bugs.python.org  Sun Sep  8 15:37:23 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Sun, 08 Sep 2013 13:37:23 +0000
Subject: [issue18970] run_setup() behavior differs from cli invocation of
 setup.py
In-Reply-To: <1378647391.64.0.940770484425.issue18970@psf.upfronthosting.co.za>
Message-ID: <1378647443.6.0.663134152127.issue18970@psf.upfronthosting.co.za>


Changes by Lukas Wunner <lukas at wunner.de>:


Added file: http://bugs.python.org/file31662/run_setup-py31.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18970>
_______________________________________

From report at bugs.python.org  Sun Sep  8 15:37:48 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Sun, 08 Sep 2013 13:37:48 +0000
Subject: [issue18970] run_setup() behavior differs from cli invocation of
 setup.py
In-Reply-To: <1378647391.64.0.940770484425.issue18970@psf.upfronthosting.co.za>
Message-ID: <1378647468.59.0.507956014543.issue18970@psf.upfronthosting.co.za>


Changes by Lukas Wunner <lukas at wunner.de>:


Added file: http://bugs.python.org/file31663/run_setup-py27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18970>
_______________________________________

From report at bugs.python.org  Sun Sep  8 15:38:06 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Sun, 08 Sep 2013 13:38:06 +0000
Subject: [issue18970] run_setup() behavior differs from cli invocation of
 setup.py
In-Reply-To: <1378647391.64.0.940770484425.issue18970@psf.upfronthosting.co.za>
Message-ID: <1378647486.12.0.873131470153.issue18970@psf.upfronthosting.co.za>


Changes by Lukas Wunner <lukas at wunner.de>:


Added file: http://bugs.python.org/file31664/run_setup-py26.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18970>
_______________________________________

From report at bugs.python.org  Sun Sep  8 16:20:18 2013
From: report at bugs.python.org (Andrea Corbellini)
Date: Sun, 08 Sep 2013 14:20:18 +0000
Subject: [issue18454] distutils crashes when uploading to PyPI having only the
 username (no pw) defined
In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za>
Message-ID: <1378650018.51.0.350298197681.issue18454@psf.upfronthosting.co.za>


Changes by Andrea Corbellini <corbellini.andrea at gmail.com>:


----------
versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18454>
_______________________________________

From report at bugs.python.org  Sun Sep  8 16:23:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 14:23:11 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378650191.13.0.485314574281.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

Were you changing something in core/builtins?  I'm wondering if just making some same-between-versions space between the version header/date and the beginning of that section would be enough to solve 99% of the problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Sun Sep  8 16:28:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 14:28:18 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378650498.37.0.384518784992.issue18829@psf.upfronthosting.co.za>


R. David Murray added the comment:

"delimiter must be a 1 character string" would cover it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Sep  8 16:48:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 14:48:55 +0000
Subject: [issue18971] Use argparse in the profile/cProfile modules
Message-ID: <1378651735.34.0.106872134579.issue18971@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the profile and cProfile modules.

----------
components: Library (Lib)
files: profile_argparse.patch
keywords: patch
messages: 197262
nosy: bethard, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the profile/cProfile modules
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31665/profile_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18971>
_______________________________________

From report at bugs.python.org  Sun Sep  8 16:53:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 14:53:49 +0000
Subject: [issue18972] Use argparse in email example scripts
Message-ID: <1378652028.96.0.621116344908.issue18972@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the Doc/includes/email-dir.py and Doc/includes/email-unpack.py scripts.

----------
assignee: docs at python
components: Documentation, email
files: email_examples_argparse.patch
keywords: patch
messages: 197263
nosy: barry, docs at python, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in email example scripts
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31666/email_examples_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18972>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:06:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 15:06:16 +0000
Subject: [issue18973] Use argparse in the calendar module
Message-ID: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the calendar modules.

----------
components: Library (Lib)
messages: 197264
nosy: bethard, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the calendar module
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:10:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Sep 2013 15:10:16 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378653016.86.0.490493070032.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

David R. Murray said, '"delimiter must be a 1 character string" would cover it.'

You mean

$ ./python -c 'import csv; reader = csv.reader("foo", delimiter="")' 

should give this error '"delimiter" must be a 1 character string'?

Attached the patch to accommodate your request.

I found out that:

$ ./python -c 'import csv; reader = csv.reader("foo", quotechar="")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: quotechar must be set if quoting enabled

This is not consistent with the cure. But since this ticket is about delimiter, we keep the status-quo about quotechar for now. After the patch is committed, we can open the ticket about the quotechar inconsistency.

The fix for this quotechar is not straightforward, though, because of the quoting condition.

----------
Added file: http://bugs.python.org/file31667/fix_error_message_reader_csv_alternative_1_v8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:12:27 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Sep 2013 15:12:27 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378653147.31.0.226471896605.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Sorry for typing your name wrongly.

s/David R. Murray/R. David Murray/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:20:08 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 08 Sep 2013 15:20:08 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1378653608.83.0.793181454135.issue1565525@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Here's a patch implementing traceback.clear_tb_frames().  (Feel free to bikeshed about the name.)

One more substantial question: the top frame of the traceback is possibly still running.  Currently the code skips it by doing an initial 'tb = tb.tb_next'.  Would it be better to catch and ignore the RuntimeError 
from frame.clear()?

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31668/clear-tb-frames.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:24:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Sep 2013 15:24:02 +0000
Subject: [issue18973] Use argparse in the calendar module
In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>
Message-ID: <1378653842.42.0.745665565823.issue18973@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I don't see any patches. You forgot to upload the patch?

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:28:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 15:28:01 +0000
Subject: [issue18974] Use argparse in the diff script
Message-ID: <1378654081.42.0.0708536053784.issue18974@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the Tools/scripts/diff.py script.

----------
components: Demos and Tools
files: diff_argparse.patch
keywords: patch
messages: 197269
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the diff script
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31669/diff_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18974>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:28:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 15:28:40 +0000
Subject: [issue18974] Use argparse in the diff script
In-Reply-To: <1378654081.42.0.0708536053784.issue18974@psf.upfronthosting.co.za>
Message-ID: <1378654120.01.0.128563671694.issue18974@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18974>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:30:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 15:30:15 +0000
Subject: [issue18973] Use argparse in the calendar module
In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>
Message-ID: <1378654215.42.0.400128187587.issue18973@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> You forgot to upload the patch?

Again.

----------
keywords: +patch
Added file: http://bugs.python.org/file31670/calendar_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:39:49 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Sep 2013 15:39:49 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378654789.03.0.658667938133.issue18829@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

After contemplating for a while, I am not sure that we should treat empty string for delimiter with error message: '"delimiter" must be an 1-character string'.

The reason is to keep consistency with quotechar keyword.

[sky at localhost cpython]$ ./python -c 'import csv; reader = csv.reader("foo", quotechar="")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: quotechar must be set if quoting enabled

[sky at localhost cpython]$ ./python -c 'import csv; reader = csv.reader("foo", quotechar="", quoting=csv.QUOTE_NONE)'
# No error, so implicitly quotechar is not set, but it is okay since we use "quote none" quoting.
# In other word, quotechar is not set by giving empty string to quotechar.

We could not change the behaviour of csv module, which is unsetting quotechar by giving empty string to quotechar and let it be if we use "quote none" quoting, to preserve backward compatibility.

So the error message should be, "The delimiter must be set" for empty string for delimiter, I suppose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:45:24 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Sep 2013 15:45:24 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378655124.4.0.401620068092.issue18962@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Try this patch.

----------
Added file: http://bugs.python.org/file31671/merge.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sun Sep  8 17:57:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 15:57:21 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1378655841.21.0.764824517272.issue18829@psf.upfronthosting.co.za>


R. David Murray added the comment:

Parsing a csv file with no delimiter would seem to be meaningless, unless I'm misunderstanding what 'delimeter' controls.  So the error messages for delimiter and quotechar are necessarily different.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:00:31 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Sep 2013 16:00:31 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
Message-ID: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>


New submission from Jakub Stasiak:

This patch includes:
* making code more PEP8-compatible and refactoring it a bit
* printing number of loops per second when using command line interface
* using thousands separators when printing numbers of loops (also in command line interface)
* changing examples in the module documentation

The output is changed from this:

    10000 loops, best of 3: 40.3 usec per loop

to that:

    10,000 loops, best of 3: 34.6 usec per loop, 28,870.783/s

I'm still not sure about details of "28,870.783/s" part:
* whether it should always include the fractional part (in this example it doesn't make any sense)
* maybe it should say "loops/s" rather than just "/s"

----------
components: Library (Lib)
files: timeit.patch
keywords: patch
messages: 197274
nosy: jstasiak
priority: normal
severity: normal
status: open
title: timeit: Use thousands separators and print number of loops per second
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31672/timeit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:10:25 2013
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 08 Sep 2013 16:10:25 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>
Message-ID: <1378656625.98.0.358272617428.issue12317@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12317>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:12:22 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 08 Sep 2013 16:12:22 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378656742.04.0.132317284171.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

A possibly unintended consequence to this `seen_non_default_actions` testing is that default values do not qualify as 'present' when testing for a required mutually exclusive group.

    p=argparse.ArgumentParser()
    g=p.add_mutually_exclusive_group(required=True)
    g.add_argument('--foo',default='test')
    g.add_argument('--bar',type=int,default=42)
    p.parse_args('--bar 42'.split())

raises an `error: one of the arguments --foo --bar is required`

In the original code

    p.parse_args('--foo test'.split())

does not raise an error because 'test' does not qualify as default.  But with the change I proposed, it does raise the error.

This issue may require adding a `failures_when_required` category to the test_argparse.py MEMixin class.  Currently nothing in test_argparse.py tests for this issue.

Note that this contrasts with the handling of ordinarily required arguments.

    p.add_argument('--baz',type=int,default=42,required=True)

'--baz 42' does not raise an error.  It is 'present' regardless of whether its value matches the default or not.

This argues against tightening the `seen_non_default_actions` test.  Because the current testing only catches a few defaults (None and small ints) it is likely that no user has come across the required group issue.  There might actually be fewer compatibility issues if we simply drop the default test (or limit it to the case where the default=None).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:16:11 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Sep 2013 16:16:11 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378656971.78.0.850128311409.issue18975@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

Oops, forgot to patch the tests, please find correct patch attached.

----------
Added file: http://bugs.python.org/file31673/timeit-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:20:20 2013
From: report at bugs.python.org (Benedikt Morbach)
Date: Sun, 08 Sep 2013 16:20:20 +0000
Subject: [issue18976] distutils/command/build_ext passes wrong linker flags
Message-ID: <1378657220.2.0.111053625387.issue18976@psf.upfronthosting.co.za>


New submission from Benedikt Morbach:

At http://hg.python.org/cpython/file/1043cc2cb0ff/Lib/distutils/command/build_ext.py#l247
build_ext.py compares sys.executable against sys.exec_prefix.

When cross compiling cpython, it notices that the interpreter running the build is located at exec_prefix and concludes that it is building a third-party module.
Thus, it passes '-L{HOST_LIBDIR}', instead of '-L.', which breaks the build.

The attached patch reverses the logic, checking if sys.executable resides in ${PWD} and assuming a third-party module otherwise.

This should also fix http://bugs.python.org/issue16326

----------
assignee: eric.araujo
components: Cross-Build, Distutils, Extension Modules, Library (Lib)
files: 0001-make-sure-to-pass-L.-when-building-standard-extensio.patch
keywords: patch
messages: 197277
nosy: Benedikt.Morbach, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils/command/build_ext passes wrong linker flags
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31674/0001-make-sure-to-pass-L.-when-building-standard-extensio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18976>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:22:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 16:22:51 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
In-Reply-To: <1378653608.83.0.793181454135.issue1565525@psf.upfronthosting.co.za>
Message-ID: <1378657348.3251.1.camel@fsol>


Antoine Pitrou added the comment:

> One more substantial question: the top frame of the traceback is
> possibly still running.  Currently the code skips it by doing an
> initial 'tb = tb.tb_next'.  Would it be better to catch and ignore the
> RuntimeError 
> from frame.clear()?

Yes, I think it would be better.
Other than that, the doc lacks a "versionadded" tag.
Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:28:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 16:28:44 +0000
Subject: [issue18977] The -t option has no effect in for uu command-line
Message-ID: <1378657724.77.0.882529649295.issue18977@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The uu module can be run as command-line tool. In Python 2, "uu -t infile outfile" opens input file in text mode, i.e. convert '\r\n' to '\n' on Windows and '\r' to '\n' on Mac Classic, and "uu -d -t infile outfile" opens output file in text mode, i.e. convert '\n' to '\r\n' on Windows and '\n' to '\r' on Mac Classic. In Python 3 this option has no effect.

The proposed patch restores former behavior and extends it. Encoding with -t option now uses universal newlines for reading, and decoding with -t option now converts '\n' to os.linesep for writing. In additional text mode now works with standard input/output.

This change perhaps is too large for the fix of such  insignificant bug and that is why I propose it as a new feature.

----------
assignee: serhiy.storchaka
components: Demos and Tools, Library (Lib)
files: uu_text_mode.patch
keywords: patch
messages: 197279
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: The -t option has no effect in for uu command-line
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31675/uu_text_mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18977>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:35:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 16:35:47 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378658147.07.0.488052066863.issue18975@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:39:36 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 Sep 2013 16:39:36 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378658376.75.0.951636721817.issue18929@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, taking a step back.

It seems that currently inspect is geared towards instances and classes, not metaclasses.  Consequently, so is help.

So, how do we enhance inspect so that help can be metaclass aware?

classify_class_attrs seems like an obvious choice, and it's docstring currently says this:

def classify_class_attrs(cls):
    """Return list of attribute-descriptor tuples.

    For each name in dir(cls), the return list contains a 4-tuple
    with these elements:

        0. The name (a string).

        1. The kind of attribute this is, one of these strings:
               'class method'    created via classmethod()
               'static method'   created via staticmethod()
               'property'        created via property()
               'method'          any other flavor of method
               'data'            not a method

        2. The class which defined this attribute (a class).

        3. The object as obtained directly from the defining class's
           __dict__, not via getattr.  This is especially important for
           data attributes:  C.data is just a data object, but
           C.__dict__['data'] may be a data descriptor with additional
           info, like a __doc__ string.
    """

We could add additional 'kind' of 'hidden class method', and 'hidden class attributes' and then have classify_class_attrs explicitly search metaclasses.

Or, since we have to make a new getmembers (getmetaclassmembers?), we could also make a new classify_metaclass_attrs that handled both class and metaclass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:41:28 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 16:41:28 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
Message-ID: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

In Python 2.x and 3.2, I used to use a Request subclass I created for overriding the method used:

class MethodRequest(request.Request):
	def __init__(self, *args, **kwargs):
		"""
		Construct a MethodRequest. Usage is the same as for
		`urllib.request.Request` except it also takes an optional `method`
		keyword argument. If supplied, `method` will be used instead of
		the default.
		"""
		if 'method' in kwargs:
			self.method = kwargs.pop('method')
		return request.Request.__init__(self, *args, **kwargs)

	def get_method(self):
		return getattr(self, 'method', request.Request.get_method(self))

In Python 3.3, which now supports a method parameter, it broke this paradigm (because the method is stored in the instance and is always set to None in __init__ if not specified).

I believe a paradigm where the method is stored as a class attribute and possibly overridden in an instance would be much better, allowing for subclasses to simply and directly override the method. For example:

class HeadRequest(MethodRequest):
	method = 'HEAD'

That straightforward example works very well if method is allowed to be a class attribute, but won't work at all if 'method' is always set as an instance attribute in __init__.

And while it's possible for HeadRequest to override __init__, that requires HeadRequest to override that entire signature, which is less elegant than simply setting a class attribute.

For Python 3.4, I'd like to adapt the Request class to allow the Method to be defined at the class level (while still honoring customization at the instance level).

----------
components: Library (Lib)
messages: 197281
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: Allow urllib.request.Request subclasses to override method
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:41:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 Sep 2013 16:41:53 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378658513.89.0.182862560813.issue18975@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I personally dislike the "," as thousands separator, and if a separator is added at all I would prefer a space as defined in the SI standard[0].

The PEP8 changes should also me moved to a separate patch IMHO; the other changes are OK grouped together.

[0]: http://en.wikipedia.org/wiki/ISO_31-0#Numbers

----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:43:00 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 08 Sep 2013 16:43:00 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1378658580.09.0.320395190773.issue18978@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Hi Jason, 

Agree with you. This design change could be valuable in extending urllib.request.Request

Thanks!

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:49:04 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 16:49:04 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1378658944.69.0.489604162133.issue18978@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've created a clone in which to draft this work.

----------
hgrepos: +208

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:49:33 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 16:49:33 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1378658973.03.0.0392526246924.issue18978@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31676/6d6d68c068ad.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:49:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 16:49:38 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378658376.75.0.951636721817.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378658975.3251.8.camel@fsol>


Antoine Pitrou added the comment:

> It seems that currently inspect is geared towards instances and
> classes, not metaclasses.  Consequently, so is help.

I'm afraid I don't really understand what you're talking about. A
metaclass is just a slightly different kind of class :-)

> def classify_class_attrs(cls):
>     """Return list of attribute-descriptor tuples.
> 
>     For each name in dir(cls), the return list contains a 4-tuple
>     with these elements:
[...]
> We could add additional 'kind' of 'hidden class method', and 'hidden
> class attributes' and then have classify_class_attrs explicitly search
> metaclasses.

The docstring is clear: "For each name in dir(cls)". If you want stuff
that hidden's in the cls.__class__ (and, consequently, not in dir(cls)),
then you are not looking for the right function, I think.

I can understand wanting to better automate lookup of methods on
classes, rather than on instances, but it would probably deserve another
function.

But I have another question first: doesn't calling
classify_class_attrs() on the metaclass already do what you want?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:53:03 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Sep 2013 16:53:03 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378659183.78.0.447934913997.issue18975@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

I agree with both notes. Splitting the patch won't be a problem.

As much as I don't fancy "," as thousands separator either - I just used what's in the standard library but I'll think about the best way of putting spaces there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 18:55:01 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 16:55:01 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1378659301.2.0.449602749831.issue18978@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file31677/2b2744cfb08f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:03:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 17:03:01 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378659781.52.0.4604625704.issue18975@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I personally dislike the "," as thousands separator, and if a
> separator is added at all I would prefer a space as defined in the SI 
> standard[0].

Then you really want a non-breaking space ;-)

(as a French person who's used to commas as decimal points, count me in the "commas as thousands separators are confusing" camp ;-))

> * whether it should always include the fractional part (in this
> example it doesn't make any sense)

Indeed, it probably doesn't make sense unless the number is < 100.
I would also put that information inside parentheses, as it is redundant with the per-loop timing.

> * maybe it should say "loops/s" rather than just "/s"

Yeah.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:05:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 17:05:18 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>
Message-ID: <1378659918.01.0.197428798133.issue12317@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12317>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:07:37 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 17:07:37 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1378660057.07.0.804641669518.issue18978@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've added tests to capture the new behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:07:53 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 17:07:53 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1378660073.32.0.0455213376616.issue18978@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file31678/061eb75339e2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:23:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 17:23:44 +0000
Subject: [issue18979] Use argparse in the uu module
Message-ID: <1378661024.73.0.529726485343.issue18979@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which replaces optparse to argparse in the uu module.

----------
components: Demos and Tools, Library (Lib)
files: uu_argparse.patch
keywords: patch
messages: 197289
nosy: bethard, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use argparse in the uu module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31679/uu_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18979>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:25:09 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 08 Sep 2013 17:25:09 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378661109.86.0.738418876044.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

I should add that defaults with required arguments (or groups?) doesn't make much sense.  Still there's nothing in the code that prevents it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:30:36 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 17:30:36 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378661436.56.0.375027467336.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

[Antoine]
> Oh, I also get the following sporadic failure
> which is triggered by slight change in semantics
> with Thread.join(timeout) :-)
> ======================================================================
> FAIL: test_various_ops (test.test_threading.ThreadTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 113, in test_various_ops
>    self.assertTrue(not t.is_alive())
> AssertionError: False is not true

Really!  In context, the test does:

            t.join()
            self.assertTrue(not t.is_alive())

(BTW, that would be clearer as self.assertFalse(t.is_alive()) ;-) )

It was the intent that this continue to work - the only intended change in Python-visible semantics had to do with join'ing with a timeout.

Without a timeout, I confess I don't see how this can fail.  join() is join(timeout=None), which does:

        self._stopped.wait(timeout)
        if self._stopped.is_set():
            self._wait_for_tstate_lock(timeout is None)

which is

        self._stopped.wait(None)
        if self._stopped.is_set():
            self._wait_for_tstate_lock(True)

which should be the same as

        self._stopped.wait()
        self._wait_for_tstate_lock(True)

after which _stopped should be set and _tstate_lock should be None.  The subsequent is_alive() should then return False, via its

        return self._tstate_lock is not None

What's going wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:34:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 17:34:46 +0000
Subject: [issue18964] test_tcl fails when _tkinter linked with Tcl 8.4
In-Reply-To: <1378590331.21.0.150230107781.issue18964@psf.upfronthosting.co.za>
Message-ID: <3cY04j2L1Cz7Ljx@mail.python.org>


Roundup Robot added the comment:

New changeset 03ee22236465 by Serhiy Storchaka in branch '3.3':
Fixed tests with Tcl/Tk <8.5 (closes #18964).
http://hg.python.org/cpython/rev/03ee22236465

New changeset 138e086e187d by Serhiy Storchaka in branch 'default':
Fixed tests with Tcl/Tk <8.5 (closes #18964).
http://hg.python.org/cpython/rev/138e086e187d

New changeset a22cfd0bdc9a by Serhiy Storchaka in branch '2.7':
Fixed tests with Tcl/Tk <8.5 (closes #18964).
http://hg.python.org/cpython/rev/a22cfd0bdc9a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18964>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:40:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 17:40:56 +0000
Subject: [issue18966] Threads within multiprocessing Process terminate early
In-Reply-To: <1378603227.91.0.146993702012.issue18966@psf.upfronthosting.co.za>
Message-ID: <1378662056.15.0.916424691722.issue18966@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That's because multiprocessing exits child processes with os._exit(), not sys.exit().

The fix would be trivial (call threading._shutdown() before os._exit()), but I don't know if that's something we want to do. After all there are many things in the Python shutdown procedure that we may want to similarly replicate in multiprocessing children, such as calling atexit handlers. This screams for a more general solution, IMHO.

----------
nosy: +neologix, pitrou, sbt
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18966>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:42:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 17:42:26 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1378661436.56.0.375027467336.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378662143.3251.9.camel@fsol>


Antoine Pitrou added the comment:

Le dimanche 08 septembre 2013 ? 17:30 +0000, Tim Peters a ?crit :
> Really!  In context, the test does:
> 
>             t.join()
>             self.assertTrue(not t.is_alive())

Ah, no, the failing test did `t.join(something)`. I removed the timeout
to remove the failure :-)

> (BTW, that would be clearer as self.assertFalse(t.is_alive()) ;-) )

Yes, old coding style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:44:06 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 08 Sep 2013 17:44:06 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378662246.73.0.969472398555.issue18943@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Fwiw I agree with you :-)  I'm just relaying a bug report that originates on PyPy (https://bugs.pypy.org/issue1595).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:45:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 17:45:41 +0000
Subject: [issue18953] Typo in NEWS about fixed format specifiers for
 Py_ssize_t in debugging output in the _sre module
In-Reply-To: <1378528822.12.0.535842380939.issue18953@psf.upfronthosting.co.za>
Message-ID: <3cY0KJ48K9zSYh@mail.python.org>


Roundup Robot added the comment:

New changeset c08e92529f62 by Serhiy Storchaka in branch '3.3':
Fix a typo. (closes #18953)
http://hg.python.org/cpython/rev/c08e92529f62

New changeset 9dc5bdab157e by Serhiy Storchaka in branch 'default':
Fix a typo. (closes #18953)
http://hg.python.org/cpython/rev/9dc5bdab157e

New changeset 6ecdf5de6252 by Serhiy Storchaka in branch '2.7':
Fix a typo. (closes #18953)
http://hg.python.org/cpython/rev/6ecdf5de6252

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18953>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:50:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 17:50:11 +0000
Subject: [issue18953] Typo in NEWS about fixed format specifiers for
 Py_ssize_t in debugging output in the _sre module
In-Reply-To: <1378528822.12.0.535842380939.issue18953@psf.upfronthosting.co.za>
Message-ID: <1378662611.39.0.62578589165.issue18953@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Vajrasky. Actually there was no need to open a new issue for such minor bug. You can report on the same issue which caused this bug. I'm afraid there are a lot of more grave syntax and grammatic errors in my Misc/NEWS entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18953>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:50:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Sep 2013 17:50:21 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1378662621.28.0.898722740194.issue18606@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a combined patch. Hopefully it will code review properly.

----------
nosy: +gvanrossum
Added file: http://bugs.python.org/file31680/statistics_combined.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:54:07 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Sep 2013 17:54:07 +0000
Subject: [issue18936] 2.7 distutils getopt chokes on unicode option names
In-Reply-To: <1378411388.86.0.748005801735.issue18936@psf.upfronthosting.co.za>
Message-ID: <1378662847.21.0.976331393096.issue18936@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

oh. My mistake. I didn't realize the error was in 'distutils.fancy_getopt' and not in the getopt module itself. Indeed, the problem doesn't exist under getopt itself, so is specific to distutils and fancy_getopt.

>>> from __future__ import unicode_literals
>>> import getopt
>>> getopt.getopt('-x', 'x', ('--longx',))
([], u'-x')
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18936>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:54:49 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Sep 2013 17:54:49 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1378662888.98.0.754113288906.issue18606@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Nice docstrings, but those aren't automatically included in the Doc tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:57:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 17:57:44 +0000
Subject: [issue18973] Use argparse in the calendar module
In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>
Message-ID: <1378663064.01.0.39491057026.issue18973@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it is highly inadvisable to make changes like this without also adding tests.  We broke compileall by doing this even though we *did* add tests.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:58:10 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 17:58:10 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378663090.23.0.57317703333.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Ah - the test used to do t.join(NUMTASKS)!  That's just bizarre ;-)

I believe I can repair that too (well - there was never a _guarantee_ that waiting 10 seconds would be long enough), but I'll wait until this all settles down.

join() and is_alive() are too complicated now, because of the 2-step dance to check whether the thread is done:  we have both an Event (_stopped) and a lock (_tstate_lock) to check now.  The Event doesn't serve a purpose anymore:  it's almost always uninteresting to know _just_ that the Python part of the thread has ended.  The only exception I can see is the perverse case of joining the main thread done in some of the tests (in that case we have to claim the main thread is done even though its tstate is still active).

Anyway, after getting rid of the Event it should be dead easy to make join(10) "appear to work the same as before, despite that it never really worked ;-)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 19:59:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 17:59:03 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378663143.68.0.316263722083.issue18975@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm afraid the adding any separators will make some people angry. With a comma or space it no more a valid number in Python and many other languages and can't be copy/pasted and parsed.

Actually I sometimes use small shell scripts to run "python -m timeit" and parsing results with grep, sed and awk. It is easer in simplest cases than writing it on Python (especially when different Python binaries used).

I'm -0,1.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:01:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 18:01:51 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1378663090.23.0.57317703333.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378663304.3251.12.camel@fsol>


Antoine Pitrou added the comment:

> join() and is_alive() are too complicated now, because of the 2-step
> dance to check whether the thread is done:  we have both an Event
> (_stopped) and a lock (_tstate_lock) to check now.  The Event doesn't
> serve a purpose anymore:  it's almost always uninteresting to know
> _just_ that the Python part of the thread has ended.

Yes, that crossed my mind too. The difficulty is that only plain lock
objects are available from C code, not Events. But if the first join()er
releases the lock just after taking it, it will be enough to make the
code correct?

(after all, it's an event that's never reset, which simplifies things)

(also, why is the current Event implementation based on Condition? isn't
an Event actually simpler than a Condition?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:02:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 18:02:56 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378663376.47.0.318930450603.issue18975@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm with Serhiy on this.  So if separators are added, I would say they *must* be optional.  Presumably if they are added they should be locale dependent :)  All of which may well make it more complicated than it is worth.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:16:22 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 18:16:22 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378664182.39.0.963065546725.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

Without _stopped, join() can simply wait to acquire _tstate_lock (with or without a timeout, and skipping this if _tstate_lock is already None).  Etc ;-)  Of course details matter, but it's easy.  I did it once, but the tests joining the main thread failed and I put the code on hold.  I'll dust it off when the buildbots are all happy with the current changes.

> (also, why is the current Event implementation based
> on Condition?

We'd have to ask Guido ;-)  Best guess is that Condition supplied all the machinery to make Event.wait() work correctly, including waking all waiters up when the Event gets set.

> isn't an Event actually simpler than a Condition?)

Events are indeed simple :-)  There are many ways to implement them, but "ain't broke, don't fix" seems the right approach to me here.  In effect, if we get rid of _stopped, the code remaining will be much like an Event implementation built on the plain _tstate_lock lock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:18:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 18:18:53 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1378664182.39.0.963065546725.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378664329.3251.14.camel@fsol>


Antoine Pitrou added the comment:

> Without _stopped, join() can simply wait to acquire _tstate_lock (with
> or without a timeout, and skipping this if _tstate_lock is already
> None).  Etc ;-)  Of course details matter, but it's easy.  I did it
> once, but the tests joining the main thread failed and I put the code
> on hold.

Ah, of course. The main thread needs the event, since the thread state
will only be deleted at the end of Py_Finalize().
The MainThread class could override is_alive() and join(), then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:22:16 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 18:22:16 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378664536.01.0.690201820185.issue18975@psf.upfronthosting.co.za>


Tim Peters added the comment:

-1 from me, and I'm a comma-loving American ;-)

I'm sure lots of code in the wild parses this output - Serhiy isn't the only one doing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:26:14 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 08 Sep 2013 18:26:14 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1378664774.35.0.422806183056.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

While refactoring the iterparse() implementation in lxml to support this new interface, I noticed that the close() method of the XMLPullParser does not behave like the close() method of the XMLParser. Instead of setting some .root attribute on the parser instance, the method should return the root element that the tree builder generated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:27:16 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 18:27:16 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378664836.76.0.428986590025.issue18808@psf.upfronthosting.co.za>


Tim Peters added the comment:

> The MainThread class could override is_alive() and join(), then.

I think it will be easier than that, but we'll see ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:55:32 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Sep 2013 18:55:32 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378666532.43.0.272740742426.issue18962@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file31681/merge2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sun Sep  8 20:55:47 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Sep 2013 18:55:47 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378666547.57.0.353423994068.issue18962@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: http://bugs.python.org/file31671/merge.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Sun Sep  8 21:15:00 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Sep 2013 19:15:00 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
In-Reply-To: <1377260394.63.0.429867593592.issue18821@psf.upfronthosting.co.za>
Message-ID: <1378667700.26.0.114538791872.issue18821@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Oscar, the solution proposed by Serhiy looks like a better choice.

I'm wary of increasing the API complexity of the itertools.  Right now, their learnability is aided by having simple signatures and no side-values.

The itertools are modeled on functional tools in other languages with mature APIs.  I look to those languages to provide an indication of whether proposed features are needed in practice.  AFAICT, there is no precedent for a takewhile-with-failed-value combo.

I appreciate your request (especially because it was accompanied by a use case) but am going to decline.  IMO, the module as a whole is better served by keeping the tools simple and clean. 

If an individual itertool doesn't have an exact fit to a particular use case, it may indicate that the programmer would be better served by a simple generator which can express the logic more cleanly than a tricked-out itertool with side-values.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18821>
_______________________________________

From report at bugs.python.org  Sun Sep  8 21:16:26 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Sun, 08 Sep 2013 19:16:26 +0000
Subject: [issue18980] Docs: enum - ReST format
Message-ID: <1378667786.26.0.0622956462221.issue18980@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

in http://docs.python.org/3.4/library/enum.html :
"..note: Nomenclature"
and 
".:meth:__format__"

visible in the html.

----------
assignee: docs at python
components: Documentation
files: enum_minor.patch
keywords: patch
messages: 197312
nosy: docs at python, elazar
priority: normal
severity: normal
status: open
title: Docs: enum - ReST format
versions: Python 3.4
Added file: http://bugs.python.org/file31682/enum_minor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18980>
_______________________________________

From report at bugs.python.org  Sun Sep  8 21:36:38 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Sep 2013 19:36:38 +0000
Subject: [issue17862] itertools.chunks(iterable, size, fill=None)
In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za>
Message-ID: <1378668998.91.0.548064166447.issue17862@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If this is to go forward, it needs to be more interesting, useful, and general than what was has been discussed so far.  I would be open to some kind of reshape() itertool than can ungroup, flatten, and regroup in at least two dimensions.  

Ideally, it should be inspired by a successful general-purpose tool from another functional or data manipulation language (perhaps APL, Mathematica, Matlab, Numpy, or somesuch).

Ideally, the proposal will be accompanied by some non-trivial real-world use cases to help validate the design.

Ideally, there should be demonstrations of reshape() interacting effectively with the other itertools (i.e. a criterion for adding new Lego bricks is whether they work well with all the existing Lego bricks -- that is what makes a good Lego set).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17862>
_______________________________________

From report at bugs.python.org  Sun Sep  8 21:48:10 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Sep 2013 19:48:10 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378669690.56.0.399778915455.issue18975@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

To me the point of this patch is adding number of loops per second information - using thousands separators was just an addition which I'm happy to drop.

Please find attached 2 patches:
- one containing actual changes - loops per second added, fractional part is printed when the number is less than 100, space is used as thousands separator; old part of the message is not affected
- one containing PEP8 reformatting

So:

    10000 loops, best of 3: 34.6 usec per loop (28 870 loops/s)

----------
Added file: http://bugs.python.org/file31683/timeit-v3-actual-changes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 21:48:27 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 08 Sep 2013 19:48:27 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378669707.26.0.759530183812.issue18975@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


Added file: http://bugs.python.org/file31684/timeit-v3-pep8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 21:50:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 19:50:05 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378669690.56.0.399778915455.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378669802.3251.15.camel@fsol>


Antoine Pitrou added the comment:

> So:
> 
>     10000 loops, best of 3: 34.6 usec per loop (28 870 loops/s)

Looks fine to me (though having a decimal space at the right and not at
the left looks a bit weird).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 22:04:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 Sep 2013 20:04:19 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1378670659.73.0.402400543216.issue18975@psf.upfronthosting.co.za>


R. David Murray added the comment:

I do not find a space to be an acceptable separator, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Sun Sep  8 22:16:03 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Sun, 08 Sep 2013 20:16:03 +0000
Subject: [issue18821] Add .lastitem attribute to takewhile instances
In-Reply-To: <1378667700.26.0.114538791872.issue18821@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxQ+bQeNPtJQ76-jGxsJTKZhBCSWPyF=5gPhZsQLua8veg@mail.gmail.com>


Oscar Benjamin added the comment:

Thank you Claudiu very much for writing a patch; I was expecting to
have to do that myself!

Serhiy, you're right groupby is a better fit for this. It does mean a
bit of reworking for the (more complicated) sum function I'm working
on but I've just checked with timeit and it performs very well using
the type function as a predicate. I think it might make the function a
few times faster than takewhile in my common cases for reasons that
are particular to this problem.

Raymond, thanks for taking the time to consider this. I agree that it
should now be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18821>
_______________________________________

From report at bugs.python.org  Sun Sep  8 22:55:41 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Sun, 08 Sep 2013 20:55:41 +0000
Subject: [issue18981] Typo in the ctypes tests
Message-ID: <1378673741.26.0.448771285371.issue18981@psf.upfronthosting.co.za>


New submission from Anoop Thomas Mathew:

Comment in the test_number.py in ctypes test hold a typo bug. Instead of superseeded, it should be superseded. Patch attached.

----------
assignee: docs at python
components: Documentation, Tests
files: ctypes_test_typo.patch
keywords: patch
messages: 197318
nosy: Anoop.Thomas.Mathew, docs at python
priority: normal
severity: normal
status: open
title: Typo in the ctypes tests
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31685/ctypes_test_typo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18981>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:02:24 2013
From: report at bugs.python.org (bruno Piguet)
Date: Sun, 08 Sep 2013 21:02:24 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1378674144.02.0.503982676969.issue14984@psf.upfronthosting.co.za>


bruno Piguet added the comment:

I missed the 3.3 window, may I re-propose the same minimal patch against 3.4.0a1 ?
I'm not sure I follow any python standard lib coding style but the general idea is quite simple and easy to get.

I chose to ignore the backward compatibility concern, since I agree that the security aspect overrides that.

I followed your suggestion : my patch raises OSError instead of NetrcParseError.

----------
versions: +Python 3.4 -Python 3.2
Added file: http://bugs.python.org/file31686/patch_netrc_3.4.0a1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:08:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 21:08:40 +0000
Subject: [issue18982] Add tests for CLI of the calendar module
Message-ID: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds tests for command-line interface of the calendar module. It also makes calendar tests discoverable and makes some existing tests more strong.

----------
components: Tests
files: test_calendar_cli.patch
keywords: patch
messages: 197320
nosy: r.david.murray, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for CLI of the calendar module
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31687/test_calendar_cli.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18982>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:09:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 21:09:31 +0000
Subject: [issue18973] Use argparse in the calendar module
In-Reply-To: <1378652776.38.0.50139824268.issue18973@psf.upfronthosting.co.za>
Message-ID: <1378674571.44.0.501996271914.issue18973@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good point. See issue18982.

----------
dependencies: +Add tests for CLI of the calendar module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18973>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:15:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Sep 2013 21:15:56 +0000
Subject: [issue18983] Specify time unit for timeit CLI
Message-ID: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Just an idea. Currently the timeit module in command line automatically choice most appropriate time unit for human readable output. But this makes the output less machine readable. I propose to add new option which specifies fixed time unit (usec, msec, sec).

----------
components: Library (Lib)
keywords: easy
messages: 197322
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Specify time unit for timeit CLI
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:24:44 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 08 Sep 2013 21:24:44 +0000
Subject: [issue12704] Language Reference: Clarify behaviour of yield when
 generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1378675484.07.0.133277491795.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

I've attached an updated patch.

I agree with Tim that the docs on the yield expression are already very good, so instead of extending the yield statement documentation I have shortened it to instead reduce the overlap that already exists.

In the yield expression documentation, I have replaced :keyword:`yield` with an un-tagged "yield" (because the former results in a link to the yield statement) and added '.. or yield statement' to the parts that apply to both yield expressions and statements.

I have also added hyperlinks to the relevant descriptions of the generator methods.

----------
Added file: http://bugs.python.org/file31688/yield-docpatch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12704>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:25:23 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Sun, 08 Sep 2013 21:25:23 +0000
Subject: [issue18815] DOCUMENTATION: "mmap .close()" doesn't close the
 underlying file
In-Reply-To: <1377231601.59.0.456805422296.issue18815@psf.upfronthosting.co.za>
Message-ID: <1378675523.31.0.904790444372.issue18815@psf.upfronthosting.co.za>


Anoop Thomas Mathew added the comment:

Made it explicit that close() will close only the mmap, and file will not be closed. Patch attached.

----------
keywords: +patch
nosy: +Anoop.Thomas.Mathew
Added file: http://bugs.python.org/file31689/mmap_close_documentation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18815>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:46:26 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 21:46:26 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
Message-ID: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>


New submission from Tim Peters:

As discussed in issue 18808, now that we're checking for a tstate lock, the Thread._stopped Event has become an "attractive nuisance".  The attached patch removes it.

This simplifies .join() and .is_alive(), and restores pre-18808 .join(timeout) endcase behavior (i.e., if join returns before the timeout expires, .is_alive() will always be False).

Since this doesn't add any new locks, I hope it won't create more problems with fork tests - but running on Windows I wouldn't know ;-)

----------
assignee: tim.peters
components: Library (Lib)
files: remove_stopped
keywords: needs review, patch
messages: 197325
nosy: pitrou, tim.peters
priority: normal
severity: normal
stage: patch review
status: open
title: Remove .stopped Event from Thread internals
versions: Python 3.4
Added file: http://bugs.python.org/file31690/remove_stopped

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:47:44 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 21:47:44 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378676864.49.0.573628173003.issue18984@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
dependencies: +Thread.join returns before PyThreadState is destroyed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:50:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 21:50:11 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378677011.97.0.720978826061.issue18984@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hmm.. I'm getting the following failures:

======================================================================
FAIL: test_4_joining_across_fork_in_worker_thread (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 726, in test_4_joining_across_fork_in_worker_thread
    self.assertScriptHasOutput(script, "end of main\n")
  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 651, in assertScriptHasOutput
    rc, out, err = assert_python_ok("-c", script)
  File "/home/antoine/cpython/default/Lib/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/antoine/cpython/default/Lib/test/script_helper.py", line 46, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Traceback (most recent call last):
  File "<string>", line 29, in <module>
AttributeError: 'Thread' object has no attribute '_stopped'

======================================================================
FAIL: test_5_clear_waiter_locks_to_avoid_crash (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 784, in test_5_clear_waiter_locks_to_avoid_crash
    self.assertScriptHasOutput(script, output)
  File "/home/antoine/cpython/default/Lib/test/test_threading.py", line 651, in assertScriptHasOutput
    rc, out, err = assert_python_ok("-c", script)
  File "/home/antoine/cpython/default/Lib/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/antoine/cpython/default/Lib/test/script_helper.py", line 46, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Traceback (most recent call last):
  File "<string>", line 29, in <module>
AttributeError: 'Thread' object has no attribute '_stopped'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Sun Sep  8 23:52:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 21:52:35 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378677155.03.0.123405817421.issue18984@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks like it's mostly the tests trying to check an implementation detail that doesn't exist anymore :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:01:21 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 22:01:21 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378677681.74.0.701827501602.issue18984@psf.upfronthosting.co.za>


Tim Peters added the comment:

I agree with your diagnosis.  Unfortunately, I can't test the fork stuff.  Well, OK, I actually think that's fortunate (for me ;-) ).

If you can see a quick way to fix these, please do.  I'm going to vanish for about 2 hours now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:02:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Sep 2013 22:02:30 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378650191.13.0.485314574281.issue18967@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cSB=pmhpWZhOjbSJ8m9kQ75m5zuh-6r5YDpOqrX1z3gA@mail.gmail.com>


Nick Coghlan added the comment:

No, way down in Tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:13:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Sep 2013 22:13:53 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>
Message-ID: <1378678433.41.0.542504854633.issue12317@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Move to absolute file paths for module.__file__

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12317>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:14:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 22:14:06 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378678446.35.0.844811032188.issue18984@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think the fix is simply to remove the outdated tests.

I've been running test_threading in a loop with the (attached) updated patch, and there hasn't been a single failure.

----------
type:  -> resource usage
Added file: http://bugs.python.org/file31691/remove_stopped_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:19:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 Sep 2013 22:19:24 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
In-Reply-To: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>
Message-ID: <1378678764.65.0.534392505811.issue18903@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The initial difficulty I am having is that the edit menu, help file, code, and behavior do not seem to match up, so this whole feature set needs more review. For one thing, the AutoCompleteWindow (ACW) often comes up empty initially. Sometimes it fills in a couple of seconds later, sometimes not. Or it only fills in if I enter or delete a char.

However, I did manage to reproduce the issue. (Westley, your ambiguous report cannot be exactly correct. If you typed 3 chars (no quotes) and tab, you should get a list of python names, not filenames. If you typed 5 chars (two quotes) and tab, you should get a literal tab. You would have to type 4 chars (open quote only) and tab to get filenames.)

Reviewing the code, I see the following.
AutoComplete.open_completions calls .fetch_completions to get a sorted list of possible completions, according to the mode. It then makes an ACW and calls .show_window.  ACW.show_window receives the mode and stores it as self.mode. That is used in the logic of ACW.keypress_event for handling 'special' characters. It is currently not used for matching normal characters to completions. ACW.show_window also allocates a tk.Listbox with
self.listbox = listbox = Listbox(acw, yscrollcommand=scrollbar.set,
                           exportselection=False, bg="white")
As near as I can tell, the matching of what the user types with entries in the ACW listbox is done in ACS._binary_search as items in the listbox seem to be set with
            self.listbox.select_set(self._binary_search(self.start))

For this issue, we need two things.

1. .fetch_completions should sort filenames disregarding case on Windows.  Perhaps key = str.lower will be sufficient, but I do not know what 'case-insensitive' actually means on Windows with respect to general Unicode file names. 

2. A case-insensitive version of _binary_search -- perhaps an instance function (closure) defined in .show_window using a list of lower-cased entries. Both the original and replacement should probably use the bisect module, which has a C accelerator.

There is a third thing: tests. I am reluctant to continue patching Idle without tests for the issue, but writing one for this will probably be harder than the patch itself. My main concern is not to make things worse.

It would to easier to document that one should start with one letter and if there is no desired match, backspace and try the other case ;-).

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18903>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:21:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 22:21:22 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>
Message-ID: <1378678882.43.0.709567864511.issue12317@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This shouldn't be a dependency. The function is already implemented, it just needs to be documented.

----------
dependencies:  -Move to absolute file paths for module.__file__
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12317>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:36:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Sep 2013 22:36:32 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1378679792.39.0.46072786608.issue18983@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If you want the output to be machine readable, better go the full way and add a --json option, IMO.

----------
nosy: +pitrou, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Sep  9 00:49:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Sep 2013 22:49:34 +0000
Subject: [issue12317] inspect.getabsfile() is not documented
In-Reply-To: <1308351508.86.0.88677303291.issue12317@psf.upfronthosting.co.za>
Message-ID: <1378680574.09.0.250419389225.issue12317@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It technically doesn't need to be a dependency, but if __file__ goes absolute then the point of the function becomes moot and thus shouldn't get documented as it is then pointless (and honestly I don't trust any code that tries to guess at what the cwd was when a module was imported).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12317>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:21:09 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 Sep 2013 23:21:09 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378682469.18.0.446932744268.issue18929@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Antoine, to answer all your questions at once, and using an Enum as the example:

--> dir(Color)
['__class__', '__doc__', '__members__', '__module__', 'blue', 'green', 'red']

--> Color.__members__
mappingproxy(OrderedDict([('red', <Color.red: 1>), ('green', <Color.green: 2>), ('blue', <Color.blue: 3>)]))

-->help(Color)
========================================
Help on class Color in module __main__:

Color = <enum 'Color'>
========================================

Why?  Because __members__ is not in Color.__dict__

--> Color.__dict__.keys()
dict_keys(['_member_type_', '_member_names_', '__new__', '_value2member_map_', '__module__', '_member_map_', '__doc__'])

and inspect.classify_class_attrs doesn't look in metaclasses, instead assigning None as the class if it can't find it:

--> inspect.classify_class_attrs(Color) # output trimmed for brevity
Attribute(name='__members__', kind='data', defining_class=None, object= ... )

So, even though __members__ does show up in dir(Color), classify_class_attrs incorrectly assigns its class.

Can I use classify_class_attrs on Color.__class__? Sure, but then I get 50 items, only one of which was listed in dir(Color).

Interestingly, getmembers(Color) does return __members__, even though it is a metaclass attribute and the docs warn that it won't:

--> print('\n'.join([str(i) for i in inspect.getmembers(Color)]))
('__class__', <attribute '__class__' of 'object' objects>)
('__doc__', None)
('__members__', mappingproxy(OrderedDict([('red', <Color.red: 1>), ('green', <Color.green: 2>), ('blue', <Color.blue: 3>)])))
('__module__', '__main__')
('blue', <Color.blue: 3>)
('green', <Color.green: 2>)
('red', <Color.red: 1>)

So if getmembers() correctly reports it because it shows up in dir(), then classify_class_attrs should correctly identify it as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:33:41 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 08 Sep 2013 23:33:41 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378683221.9.0.37694010761.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

This `argument_values` comes from `_get_values()`.  Most of the time is derived from the `argument_strings`.  But in a few cases it is set to `action.default`, specifically when the action is an optional postional with an empty `argument_strings`.

test_argparse.TestMutuallyExclusiveOptionalAndPositional is such a case.  `badger` is an optional positional in a mutually exclusive group.  As such it can be 'present' without really being there (tricky).  Positionals are always processed - otherwise it raises an error.

If this is the case, what we need is a more reliable way of knowing whether `_get_values()` is doing this, one that isn't fooled by this small int caching.

We could rewrite the `is not` test as:

    if not argument_strings and action.nargs in ['*','?'] and  argument_values is action.default:
        pass # _get_values() has set: argument_values=action.default
    else:
        seen_non_default_actions.add(action)
        ...

is a little better, but still feels like a kludge.  Having `_get_values` return a flag that says "I am actually returning action.default" would be clearer, but, I think, too big of a change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:46:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 23:46:43 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <3cY8Kt5MwZz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset aff959a3ba13 by Tim Peters in branch 'default':
Issue 18984:  Remove ._stopped Event from Thread internals.
http://hg.python.org/cpython/rev/aff959a3ba13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:46:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Sep 2013 23:46:44 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <3cY8Kv3YS6z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset aff959a3ba13 by Tim Peters in branch 'default':
Issue 18984:  Remove ._stopped Event from Thread internals.
http://hg.python.org/cpython/rev/aff959a3ba13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:49:57 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 08 Sep 2013 23:49:57 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1378684197.87.0.828250193789.issue1565525@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Revised version of the patch: catches RuntimeError instead of skipping the first frame; adds versionadded tag; adds entry to NEWS and whatsnew files.

----------
Added file: http://bugs.python.org/file31692/clear-tb-frames-2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:50:25 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 23:50:25 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378684224.99.0.983131639355.issue18984@psf.upfronthosting.co.za>


Tim Peters added the comment:

Thanks, Antoine!  I pushed this change, figuring that even if some buildbots are still unhappy about 18808, getting rid of the Event can't make them more unhappy, and may make them happier.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:53:37 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 23:53:37 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378684417.0.0.428895373407.issue18984@psf.upfronthosting.co.za>


Tim Peters added the comment:

New changeset aff959a3ba13 by Tim Peters in branch 'default':
Issue 18984:  Remove ._stopped Event from Thread internals.
http://hg.python.org/cpython/rev/aff959a3ba13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 01:54:04 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 08 Sep 2013 23:54:04 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378684444.46.0.912036258763.issue18984@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
Removed message: http://bugs.python.org/msg197342

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 02:33:35 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 09 Sep 2013 00:33:35 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
In-Reply-To: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>
Message-ID: <1378686815.23.0.0453180364345.issue18903@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

My example was totally abstract and untested.  Sorry for any confusion.

After doing some research, I find that this issue is complicated further:
http://support.microsoft.com/kb/100625

I think we can assume that running into a situation where there are identical filenames except for case is quite rare.  The thing is, I don't even know how to make files like this on Windows.  Explorer doesn't work, and other Win32 apps won't do it (they all spit up errors).  I reckon I can do it with Python or some other language, since I assume they does these things at a low level.

I'll start looking at the code and see if I can come up with a patch.  My aim is to make it similar enough to how the Windows Terminal does it, (i.e. it corrects the typed name to the proper case) since that is what I'd imagine most Windows programmers are used to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18903>
_______________________________________

From report at bugs.python.org  Mon Sep  9 02:57:50 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 09 Sep 2013 00:57:50 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1378688270.18.0.229706225581.issue18800@psf.upfronthosting.co.za>


Madison May added the comment:

Simple and to the point.  Sounds good to me...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Mon Sep  9 03:11:05 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 09 Sep 2013 01:11:05 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1378689065.13.0.350380049403.issue18983@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

My 2 cents - I'd split timeit.main function into processing part and argument parsing + data printing part so that you could use Python to call the first one to get the actual results (timings, numbers of loops etc.) and then present the data to the outside world in any needed format - no text parsing needed.

----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Sep  9 05:17:22 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Sep 2013 03:17:22 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
 chain_iterable.
In-Reply-To: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>
Message-ID: <1378696642.11.0.275368026344.issue18752@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18752>
_______________________________________

From report at bugs.python.org  Mon Sep  9 06:58:27 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 04:58:27 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378702707.79.0.646502943389.issue18929@psf.upfronthosting.co.za>


Ethan Furman added the comment:

This is a more useful help() -- patch attached.

==============================================================================
Help on class Color in module __main__:

class Color(enum.Enum)
 |  Method resolution order:
 |      Color
 |      enum.Enum
 |      builtins.object
 |  
 |  Data and other attributes defined here:
 |  
 |  blue = <Color.blue: 3>
 |  
 |  green = <Color.green: 2>
 |  
 |  red = <Color.red: 1>
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.EnumMeta:
 |  
 |  __members__
 |      Returns a mapping of member name->value.
 |      
 |      This mapping lists all enum members, including aliases. Note that this
 |      is a read-only view of the internal mapping.

----------
keywords: +patch
Added file: http://bugs.python.org/file31693/issue18929.stoneleaf.03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Mon Sep  9 07:16:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Sep 2013 05:16:31 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
In-Reply-To: <1378684197.87.0.828250193789.issue1565525@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZZa+5gn8PeL759=G7bTCJ0FGzR=aMM-mjKc+OXj3wDpQ@mail.gmail.com>


STINNER Victor added the comment:

I would prefer a clear_frames() method on the traceback object rather than
a function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Sep  9 07:23:23 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 09 Sep 2013 05:23:23 +0000
Subject: [issue18980] Docs: enum - ReST format
In-Reply-To: <1378667786.26.0.0622956462221.issue18980@psf.upfronthosting.co.za>
Message-ID: <1378704203.45.0.579018153233.issue18980@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18980>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:16:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 Sep 2013 06:16:04 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
 chain_iterable.
In-Reply-To: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>
Message-ID: <1378707364.94.0.566981772583.issue18752@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll work on improving the docs to make this classmethod more discoverable in docs, but the API is going to stay the same.

----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18752>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:24:59 2013
From: report at bugs.python.org (bruno Piguet)
Date: Mon, 09 Sep 2013 06:24:59 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1378707899.1.0.594647140506.issue14984@psf.upfronthosting.co.za>


Changes by bruno Piguet <bruno.piguet at gmail.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:27:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 06:27:37 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1378708057.14.0.0947794927503.issue14984@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:30:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Sep 2013 06:30:14 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
 chain_iterable.
In-Reply-To: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>
Message-ID: <3cYKHT3DJ8z7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset fa1fa88b685b by Raymond Hettinger in branch 'default':
Issue 18752:  Make chain.from_iterable() more visible in the documentation.
http://hg.python.org/cpython/rev/fa1fa88b685b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18752>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:47:08 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 09 Sep 2013 06:47:08 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378709228.57.0.90355906386.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

At the very least the `is not action.default` needs to be changed.  Else where in argparse `is` is only used with `None` or constant like `SUPPRESS`.  So using it with a user defined parameter is definitely not a good idea.

Possible variations on how `is` behaves across implementations (pypy, ironpython) only complicates the issue.  I'm also familiar with a Javascript translation of argparse (that uses its `!==` in this context).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:48:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Sep 2013 06:48:49 +0000
Subject: [issue18980] Docs: enum - ReST format
In-Reply-To: <1378667786.26.0.0622956462221.issue18980@psf.upfronthosting.co.za>
Message-ID: <3cYKhx0Rxfz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 0e05b07a6f84 by Ethan Furman in branch 'default':
Close #18980: Enum doc fixes.  Patch from Elazar Gershuni.
http://hg.python.org/cpython/rev/0e05b07a6f84

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18980>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:55:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Sep 2013 06:55:43 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
 argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <3cYKrt2mx3z7Lkb@mail.python.org>


Roundup Robot added the comment:

New changeset 29fa1f418796 by Raymond Hettinger in branch '3.3':
Issue 18301:  The classmethod decorator didn't fit well with the rough-equivalent example code.
http://hg.python.org/cpython/rev/29fa1f418796

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18301>
_______________________________________

From report at bugs.python.org  Mon Sep  9 08:57:17 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 Sep 2013 06:57:17 +0000
Subject: [issue18301] In itertools.chain.from_iterable() there is no cls
 argument
In-Reply-To: <1372186723.21.0.67533324157.issue18301@psf.upfronthosting.co.za>
Message-ID: <1378709837.92.0.941998375493.issue18301@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18301>
_______________________________________

From report at bugs.python.org  Mon Sep  9 09:02:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Sep 2013 07:02:19 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
 chain_iterable.
In-Reply-To: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>
Message-ID: <3cYL0W0lTwz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset 23f77dc58979 by Raymond Hettinger in branch '3.3':
Issue 18752:  Make chain.from_iterable() more visible in the documentation.
http://hg.python.org/cpython/rev/23f77dc58979

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18752>
_______________________________________

From report at bugs.python.org  Mon Sep  9 09:10:18 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 Sep 2013 07:10:18 +0000
Subject: [issue18752] Make chain.from_iterable an alias for a new
 chain_iterable.
In-Reply-To: <1376600759.44.0.81483548171.issue18752@psf.upfronthosting.co.za>
Message-ID: <1378710618.62.0.140790999362.issue18752@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18752>
_______________________________________

From report at bugs.python.org  Mon Sep  9 09:34:57 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 Sep 2013 07:34:57 +0000
Subject: [issue18313] In itertools recipes repeatfunc() defines a non-keyword
 argument as keyword
In-Reply-To: <1372309261.95.0.7034101172.issue18313@psf.upfronthosting.co.za>
Message-ID: <1378712097.01.0.826633077192.issue18313@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

All of the proposed variants have their own issues.  

For example, the keyword-argument variant behaves badly if the user leaves off the keyword:

  >>> list(repeatfunc(ord, 'A', times=3))
  [65, 65, 65]
  >>> list(repeatfunc(ord, 'A', 3))
  Traceback (most recent call last):
    File "<pyshell#12>", line 1, in <module>
      list(repeatfunc(ord, 'A', 3))
  TypeError: ord() takes exactly one argument (2 given)

I prefer to leave the recipe as is.  The primary purpose of the recipe is to illustrate how starmap() and repeat() can be used together.  Will that knowledge, a user can easily cobble together in-line code for either the finite version or the infinite iterable version.

----------
priority: normal -> low
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18313>
_______________________________________

From report at bugs.python.org  Mon Sep  9 09:56:20 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 Sep 2013 07:56:20 +0000
Subject: [issue18577] lru_cache enhancement: lru_timestamp helper function
In-Reply-To: <1375014771.52.0.855210720887.issue18577@psf.upfronthosting.co.za>
Message-ID: <1378713380.37.0.100150912558.issue18577@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is a pretty interesting idea.

Ideally, it would be great if it could be a published as a recipe somewhere so that people could experiment with the API and try out variations.  If there were good uptake by users, it would help justify a proposal to be included in the standard library.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18577>
_______________________________________

From report at bugs.python.org  Mon Sep  9 10:34:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 08:34:17 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378682469.18.0.446932744268.issue18929@psf.upfronthosting.co.za>
Message-ID: <924009060.47344857.1378715651421.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> So, even though __members__ does show up in dir(Color),
> classify_class_attrs incorrectly assigns its class.
> 
[...]
> 
> So if getmembers() correctly reports it because it shows up in dir(),
> then classify_class_attrs should correctly identify it as well.

Ok, you got me convinced :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Mon Sep  9 11:50:40 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Sep 2013 09:50:40 +0000
Subject: [issue18606] Add statistics module to standard library
In-Reply-To: <1375258820.22.0.0684222529612.issue18606@psf.upfronthosting.co.za>
Message-ID: <1378720240.34.0.29855533332.issue18606@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18606>
_______________________________________

From report at bugs.python.org  Mon Sep  9 11:58:09 2013
From: report at bugs.python.org (Nicola Palumbo)
Date: Mon, 09 Sep 2013 09:58:09 +0000
Subject: [issue18622] reset_mock on mock created by mock_open causes infinite
 recursion
In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za>
Message-ID: <1378720689.69.0.535665313086.issue18622@psf.upfronthosting.co.za>


Nicola Palumbo added the comment:

Hi all,

I've fixed the infinite recursion in `reset_mock()`. It has been solved by tracking a set of visited ids as suggested.

>>> from unittest import mock
>>> a = mock.mock_open()
>>> a.reset_mock()
>>> a
<MagicMock name='open' spec='builtin_function_or_method' id='4449688192'>

----------
keywords: +patch
nosy: +npalumbo
Added file: http://bugs.python.org/file31694/issue18622.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18622>
_______________________________________

From report at bugs.python.org  Mon Sep  9 12:35:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Sep 2013 10:35:19 +0000
Subject: [issue18985] Improve the documentation in fcntl module
Message-ID: <1378722919.93.0.901392318122.issue18985@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

The attached patch fixed typos and improved the documentation to improve the clarity in Modules/fcntlmodule.c.

Please see the attached patch and feel free to disagree with the improvement.

----------
assignee: docs at python
components: Documentation
files: fix_documentation_on_fcntl_module.patch
keywords: patch
messages: 197358
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Improve the documentation in fcntl module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31695/fix_documentation_on_fcntl_module.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18985>
_______________________________________

From report at bugs.python.org  Mon Sep  9 13:22:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 11:22:02 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
Message-ID: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is a very common need when implementing network protocols. You want to match keys case-insensitively but also preserve the original casing (e.g. for presentation).

When searching on the Web, you see many people reimplementing their own variant (often incomplete, or buggy). For example, Twisted has its own, the email package has something resembling it, WebOb also.

Having an implementation in the stdlib would spare many people the effort, ensure the implementation is complete and well-tested, and perhaps also add some optimizations to mitigate the overhead compared to a plain dict.

Note this is an instance of a more general pattern, where they key used for matching is derived from the lookup key using a constant derivation function. So maybe we want to implement the more general pattern and let users specify str.lower as the key derivation function.

----------
components: Library (Lib)
messages: 197359
nosy: barry, pitrou, r.david.murray, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add a case-insensitive case-preserving dict
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 13:38:13 2013
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 09 Sep 2013 11:38:13 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378726693.58.0.205672993439.issue18986@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 13:50:59 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 09 Sep 2013 11:50:59 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378727459.44.0.55462032867.issue18986@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

Surely a case-insensitive dict should use str.casefold, not str.lower?

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 13:54:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 11:54:42 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378727459.44.0.55462032867.issue18986@psf.upfronthosting.co.za>
Message-ID: <1467643266.47830595.1378727676328.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Surely a case-insensitive dict should use str.casefold, not
> str.lower?

Perhaps. Network protocols will usually only allow ASCII in parts
where case is insensitive (e.g. header names), so it shouldn't make a
difference.

Implementing the generic pattern means this is left at the user's
discretion, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 15:02:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 13:02:44 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378731764.02.0.93101673016.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For the record, I have my own implementation here:
https://bitbucket.org/optiflowsrd/obelus/src/tip/obelus/casedict.py?at=default
https://bitbucket.org/optiflowsrd/obelus/src/tip/obelus/test/test_casedict.py?at=default

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 15:03:01 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Mon, 09 Sep 2013 13:03:01 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a
 64-bit machine
Message-ID: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>


New submission from Sam Ferencik:

distutils.util.get_platform() semantically differs on (a) Windows and OS X, and on (b) Linux.

Windows/OS X: the return value is derived from the architecture of the *interpreter*, hence for 32-bit Python running on a 64-bit system, get_platform() = 'win32'/'macosx-10.6-i386' (32-bit).

Linux: the return value is derived from the architecture of the *OS*, hence for 32-bit Python running on 64-bit Linux get_platform() = 'linux-x86_64' (64-bit).

Based on a discussion on distutils-sig, the Linux behaviour is probably wrong and should be changed. https://mail.python.org/pipermail/distutils-sig/2013-August/subject.html

My context (where this hit me): I was installing the 32-bit version of the Perforce API (compiled module) on 64-bit Windows and on 64-bit Linux. My command-line was

  python3.3-32 setup.py install --root FOO --install-platlib=lib.$PLAT

(note the '-32' and the '$PLAT')

On Windows, this installed the 32-bit version of the API into "FOO\lib.win32". On Linux, this installed the 64-bit version of the API into "FOO/lib.linux-x86_64".

----------
assignee: eric.araujo
components: Distutils
messages: 197363
nosy: eric.araujo, sferencik, tarek
priority: normal
severity: normal
status: open
title: distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Mon Sep  9 15:14:36 2013
From: report at bugs.python.org (Howitzer21)
Date: Mon, 09 Sep 2013 13:14:36 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
Message-ID: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>


New submission from Howitzer21:

In the IDLE program for Python 3.3.2, I've run across a situation where the tab key is not working.  I have attached a file that shows everything in IDLE's console.  At the very end of the file, you can see where I have typed in the word "queue" in IDLE without pressing enter.  At this point, if I press tab, nothing happens.  If I press space and then tab, suddenly it'll work just fine.  But then if I delete all the spaces and tabs and just go back to having nothing more than "queue" on the line, with no trailing whitespace, suddenly tab will go back to not working.

----------
components: IDLE
files: console.txt
messages: 197364
nosy: Howitzer21
priority: normal
severity: normal
status: open
title: Tab key doesn't work sometimes.
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31696/console.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Mon Sep  9 15:18:41 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 13:18:41 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378732721.75.0.241431973047.issue18986@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 15:53:19 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Mon, 09 Sep 2013 13:53:19 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378734799.6.0.677371394463.issue18945@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31697/tempfile_collision_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Mon Sep  9 16:53:45 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 09 Sep 2013 14:53:45 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1378738425.69.0.388222966863.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Looks like we missed the alpha2 release for the close() API fix. I recommend not letting yet another deadline go by.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Sep  9 16:59:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Sep 2013 14:59:57 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378738797.17.0.00965669844734.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

For the record, email is not a good argument for this, since email could not use this data structure (its data structure is *not* a dict, but a list with dict-like features grafted on).

I do think this would be useful, and the generic version (analogous to defaultdict) would seem to make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 18:49:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 Sep 2013 16:49:48 +0000
Subject: [issue18934] multiprocessing: use selectors module
In-Reply-To: <1378399585.11.0.596283488282.issue18934@psf.upfronthosting.co.za>
Message-ID: <1378745388.95.0.82335347569.issue18934@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18934>
_______________________________________

From report at bugs.python.org  Mon Sep  9 19:28:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Sep 2013 17:28:04 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
In-Reply-To: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>
Message-ID: <1378747684.7.0.61424443038.issue18988@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +kbk, roger.serwy, terry.reedy
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:11:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 18:11:10 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378750270.18.0.0457214495908.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, let's bikeshed this a bit. What should be the name?
- projectdict?
- normalizedict?
- normdict?
- derivedict?
- transformdict?
- any ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:19:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 18:19:01 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378750741.03.0.375917963499.issue18986@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I would say

- transformkeydict


Too bad we can't just add an extra 'transform_key' keyword to defaultdict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:34:26 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 09 Sep 2013 18:34:26 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378751666.66.0.233164395402.issue18986@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It would be nice to combine the behaviors that defaultdict and the case-insensitive comparisons.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:36:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 18:36:49 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378751666.66.0.233164395402.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378751806.2502.3.camel@fsol>


Antoine Pitrou added the comment:

> It would be nice to combine the behaviors that defaultdict and the case-insensitive comparisons.

Any use case? In my experience they are used in completely different
situations. defaultdict mostly to use the writing of some (internal)
algorithms, a case-insensitive dict to store user-visible data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:38:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 18:38:21 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1378751901.81.0.690510609756.issue1565525@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Revised version of the patch: catches RuntimeError instead of
> skipping the first frame; adds versionadded tag; adds entry to NEWS
> and whatsnew files.

Looks good to me, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:42:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Sep 2013 18:42:28 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
In-Reply-To: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>
Message-ID: <1378752148.51.0.860950849072.issue18988@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this patch should fix the bug.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file31698/idle_autocomplete_nochange.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:42:49 2013
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 09 Sep 2013 18:42:49 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a
 64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1378752169.32.0.0362571575125.issue18987@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:44:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Sep 2013 18:44:54 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
In-Reply-To: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>
Message-ID: <1378752294.19.0.784500603589.issue18988@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is simpler test case. Just enter "flo" and press <TAB>. Twice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:50:18 2013
From: report at bugs.python.org (Roger Serwy)
Date: Mon, 09 Sep 2013 18:50:18 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
In-Reply-To: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>
Message-ID: <1378752618.36.0.332560087793.issue18988@psf.upfronthosting.co.za>


Roger Serwy added the comment:

LGTM. I manually tested it by assigning "aaaaa = 1" and then pressing tab at after "a", "aa",  "aaa", and "aaaaa", and then pressing tab afterwards. Tab works to complete the name, and then afterwards when it has been replaced with "aaaaa".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Mon Sep  9 20:58:50 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 18:58:50 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
Message-ID: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Consider:

==================================================================================
-->from enum import Enum

-->class Color(Enum):
...   red = 1
...   green = 2
...   blue = 3
...   red = 4
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in Color
  File "/home/ethan/source/python/issue18924/Lib/enum.py", line 87, in __setitem__
    raise TypeError('Attempted to reuse key: %r' % key)
TypeError: Attempted to reuse key: 'red'
==================================================================================

versus

==================================================================================
-->class Color(Enum):
...   red = 1
...   green = 2
...   blue = 3
...   def red(self):
...     return 'fooled ya!'
... 

# no error
==================================================================================

or

==================================================================================
-->class Color(Enum):
...   red = 1
...   green = 2
...   blue = 3
...   @property
...   def red(self):
...     return 'fooled ya!'
... 

# no error
==================================================================================

In both of the latter two cases the redefinition of 'red' is allowed because the new definition is not an enum member.

This is inconsistent as well as confusing.

I know normal class creation semantics don't place any such limitations on names and allow redefining at will, but Enum is not a regular class.

----------
assignee: ethan.furman
files: no_reuse_of_enum_names.stoneleaf.01.patch
keywords: patch
messages: 197375
nosy: barry, eli.bendersky, eric.snow, ethan.furman, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: reuse of enum names in class creation inconsistent
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31699/no_reuse_of_enum_names.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:13:03 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 09 Sep 2013 19:13:03 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378753983.87.0.489425075397.issue18986@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Just today I was using a defaultdict where the keys are stock symbols. They're case insensitive (at least for this particular application).

In this case I just str.upper everything, but it would be a nice feature to case-preserve the keys that I pre-populate. I care less about the keys from user data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:14:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 19:14:12 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378753983.87.0.489425075397.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378754050.2502.4.camel@fsol>


Antoine Pitrou added the comment:

> In this case I just str.upper everything, but it would be a nice
> feature to case-preserve the keys that I pre-populate. I care less
> about the keys from user data.

Well, stock symbols are what I would call user data :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:15:12 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Sep 2013 19:15:12 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378754112.61.0.944926576577.issue18984@psf.upfronthosting.co.za>


Tim Peters added the comment:

Antoine, could I bother you to try the attached cleanup.patch?  It looks harmless to me, but when I checked it in the Unix-y buildbots failed the thread+fork tests again :-(  Two examples:

http://buildbot.python.org/all/builders/x86%20Gentoo%203.x/builds/4914/steps/test/logs/stdio

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/8581/steps/test/logs/stdio

Worse, the buildbot slaves appeared never to finish running then - I had to stop them (via the "stop build" button).

Maybe I'm just tired, but I've stared & stared at this and just don't see what's going wrong :-(

----------
Added file: http://bugs.python.org/file31700/cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:18:56 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 09 Sep 2013 19:18:56 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378754336.48.0.973750255859.issue18986@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

True enough!

I was trying to distinguish keys that I populate with initial values (mostly stock indexes) versus those where I just read values from a user-supplied file. When I populate the index values, I'd like to preserve the case I initially used. When I use user-supplied values, I don't know that the first value I use to populate the defaultdict has any more meaning that the last one I see.

It would just be a nice-to-have feature for which I have a real use case. It's not so critical that I can't work around it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:24:48 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 19:24:48 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378754688.16.0.794308959563.issue18986@psf.upfronthosting.co.za>


Ethan Furman added the comment:

To the point, however, Eric's example would make use of both the defaultdict portion and the transformkey portion in a single dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:26:38 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 09 Sep 2013 19:26:38 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378754798.33.0.176309204262.issue18986@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

mappeddict?

Re defaultdict, you could write a dict that does all of these things, called superdict! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:31:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 19:31:53 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378755113.39.0.169284726865.issue18984@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a fixed patch (works here, at least :-)).

----------
Added file: http://bugs.python.org/file31701/cleanup2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:32:33 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 09 Sep 2013 19:32:33 +0000
Subject: [issue18990] Remove unnecessary API inconsistency from
 ElementTree.XMLPullParser.close()
Message-ID: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The .close() method of the new XMLPullParser (see issue17741) in Py3.4 shows an unnecessarily complicated behaviour that is inconsistent with the .close() method of the existing XMLParser.

The attached patch removes some code to fix this.

----------
components: Library (Lib), XML
files: xmlpullparser_close.patch
keywords: patch
messages: 197383
nosy: scoder
priority: normal
severity: normal
status: open
title: Remove unnecessary API inconsistency from ElementTree.XMLPullParser.close()
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31702/xmlpullparser_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:33:03 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 09 Sep 2013 19:33:03 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1378755183.87.0.316463558335.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Created separate issue18990 to keep this one closed as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:33:39 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 09 Sep 2013 19:33:39 +0000
Subject: [issue18990] Remove unnecessary API inconsistency from
 ElementTree.XMLPullParser.close()
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1378755219.97.0.0657147781759.issue18990@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:37:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 19:37:09 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a
 64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1378755429.55.0.0338622226569.issue18987@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Do you want to upload a patch?

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:37:53 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Sep 2013 19:37:53 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378755473.3.0.652203522426.issue18984@psf.upfronthosting.co.za>


Tim Peters added the comment:

Well - I remain baffled, but am grateful for the patch - thanks :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:47:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Sep 2013 19:47:29 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378756049.56.0.0437208687849.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

coercekeydict

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:49:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Sep 2013 19:49:43 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1378756183.09.0.056863875637.issue18989@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I recall this was discussed at length and we decided that this was the behavior we wanted.  I could be wrong, of course; it was a long discussion.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:51:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 19:51:06 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378756266.69.0.338159790739.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would like to shorten the proposals to "transformdict" and "coercedict".
(after all, transforming the values would have little sense: you can do it yourself trivially)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 21:58:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Sep 2013 19:58:05 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378756685.55.0.611638892044.issue18986@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI os.environ uses something similar: keys and values are encoded and decoded using functions. So any transformation is supported.

http://hg.python.org/cpython/file/eac63e7ceb03/Lib/os.py#l636

On UNIX, the encoder and decoder are os.fsencode() and os.fsdecode() (not exactly, the real functions are more strict on the input type).

On Windows, the encoder converts the key to uppercase.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:00:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 20:00:06 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378756685.55.0.611638892044.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378756802.2502.7.camel@fsol>


Antoine Pitrou added the comment:

> FYI os.environ uses something similar: keys and values are encoded and
> decoded using functions. So any transformation is supported.

I don't think this is the same situation. os.environ has bijective
transformations, which don't pose any implementation challenge.

The whole point of a "transformdict" is to allow for multiple keys to
actually map to the same dict entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:00:18 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 09 Sep 2013 20:00:18 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378756818.02.0.797259779826.issue18986@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

+1 For the general idea
+1 For the more generic approach of which "lowercase" is just one special case

+10 to make this a PEP so that more people have a chance to express their opinion (currently only those who noticed it on the issues mailing list). I find the issue tracker a very bad medium for any kind of brain-storming or bikeshedding.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:02:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 20:02:54 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378756818.02.0.797259779826.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378756971.2502.10.camel@fsol>


Antoine Pitrou added the comment:

> +10 to make this a PEP so that more people have a chance to express
> their opinion (currently only those who noticed it on the issues
> mailing list). I find the issue tracker a very bad medium for any kind
> of brain-storming or bikeshedding.

Well, I don't think there is a lot of brainstorming to be done here: we
are talking about a single well-defined functionality. I don't mind
writing a PEP if other people ask for it, but I'd rather spend my time
on more important things.

As for bikeshedding, there is no "good medium" for it, really :-) At
worse we could ask python-dev for their naming contributions (a great
idea, surely).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:06:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 20:06:43 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378757203.4.0.931642469919.issue18984@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I suppose we can close this issue now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:08:46 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Sep 2013 20:08:46 +0000
Subject: [issue18808] Thread.join returns before PyThreadState is destroyed
In-Reply-To: <1377179797.68.0.40345735309.issue18808@psf.upfronthosting.co.za>
Message-ID: <1378757326.08.0.612922120517.issue18808@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18808>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:09:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Sep 2013 20:09:39 +0000
Subject: [issue18984] Remove .stopped Event from Thread internals
In-Reply-To: <1378676786.46.0.476510624211.issue18984@psf.upfronthosting.co.za>
Message-ID: <1378757379.59.0.749034010091.issue18984@psf.upfronthosting.co.za>


Tim Peters added the comment:

Yes - and I just closed 18808 :-)

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18984>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:20:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Sep 2013 20:20:37 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1378758037.76.0.250965571302.issue1565525@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I tried to implement the feature as a new traceback.clear_frames() method. I tried to follow the chain of frame objects (using frame.f_back), but it does not work as expected. The method needs to follow the chain of traceback objects (tb.tb_next). So it makes sense to define a function instead of a method (a method usually only affect the object, not a chain of objects).

clear-tb-frames-2.txt:

- I didn't see the "tb" abbreviation in other places in Python, except for traceback attributes. I prefer clear_traceback_frames(). The name clear_frames() is maybe better because traceback is already known by the context (the module is called "tracback". Example: traceback.clear_frames(tb) instead of traceback.clear_traceback_frames(tb).

- The documentation is wrong: frame.clear() does not guarantee to clear *all* locals, but only *most* locals:

"F.clear(): clear most references held by the frame");

So I suggest a more permissive documentation:

"Clear most reference held by frames."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:20:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Sep 2013 20:20:59 +0000
Subject: [issue18904] Unnecessary test in file descriptor inheritance test
In-Reply-To: <1378093174.83.0.0549924253558.issue18904@psf.upfronthosting.co.za>
Message-ID: <1378758059.22.0.811150034536.issue18904@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18904>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:27:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 20:27:49 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
In-Reply-To: <1378758037.76.0.250965571302.issue1565525@psf.upfronthosting.co.za>
Message-ID: <1378758467.2502.11.camel@fsol>


Antoine Pitrou added the comment:

> - The documentation is wrong: frame.clear() does not guarantee to
> clear *all* locals, but only *most* locals:
> 
> "F.clear(): clear most references held by the frame");

Actually, the documentation is right: "references" != "locals" ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:41:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Sep 2013 20:41:19 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378759279.34.0.459892033294.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed.  Although there was apparently some call for it, it doesn't sound from a quick google like defaultdict was deemed to require a PEP.  Presumably the informed audience should be wider than this issue, though.

I also note that defaultdict is implemented via a special method on dict itself (__missing__), and if this one was implemented the same way it would be easy to combine the features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:43:16 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Sep 2013 20:43:16 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378759396.45.0.79051788252.issue18986@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Precisely what I was thinking.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:44:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 20:44:59 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378759279.34.0.459892033294.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378759496.2502.14.camel@fsol>


Antoine Pitrou added the comment:

> I also note that defaultdict is implemented via a special method on
> dict itself (__missing__), and if this one was implemented the same
> way it would be easy to combine the features.

It's not that simple: to remember the original casing you need either a
second container, or to use (original_key, value) tuples as values. Both
approaches have non-trivial repercussions on the implementation of many
methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 22:46:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 20:46:24 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378759584.94.0.083136266364.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(as a sidenote, you might want a case-insensitive OrderedDict as well, I see no reason to make a special case for defaultdict here)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 23:12:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Sep 2013 21:12:53 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378761173.88.0.44551959003.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also discussion on a topic: http://comments.gmane.org/gmane.comp.python.ideas/18469 .

Proposed names: custom_dict, KeyedDictionary, Dictionary.

It will be confused if this dict will not be compatible with PyDict API. It is possible to add such feature directly into the dict class (I experimented with IdentityDict).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 23:16:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 21:16:12 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378761173.88.0.44551959003.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378761369.2502.16.camel@fsol>


Antoine Pitrou added the comment:

> Proposed names: custom_dict, KeyedDictionary, Dictionary.

Sounds much too vague and un-specific.

> It will be confused if this dict will not be compatible with PyDict
> API.

Why? Many custom dict-like classes aren't.

> It is possible to add such feature directly into the dict class (I
> experimented with IdentityDict).

Can you explain how?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 23:50:06 2013
From: report at bugs.python.org (Davi Post)
Date: Mon, 09 Sep 2013 21:50:06 +0000
Subject: [issue18991] Overriding OrderedDict.__getitem__() doesn't work
Message-ID: <1378763406.5.0.0321724375688.issue18991@psf.upfronthosting.co.za>


New submission from Davi Post:

class MyOrderedDict(OrderedDict):
   
    def __getitem__(self, key):
        OrderedDict.__getitem__(self, key)

After setting a key, getting it returns None. See attached.

Am I missing something?

Discovered this when trying to use the dict_type parameter of ConfigParser.RawConfigParser -- caused an AttributeError.

Possibly relevant to http://bugs.python.org/issue9534

----------
components: Library (Lib)
files: OrderedDictTest.py
messages: 197404
nosy: davipo
priority: normal
severity: normal
status: open
title: Overriding OrderedDict.__getitem__() doesn't work
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31703/OrderedDictTest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18991>
_______________________________________

From report at bugs.python.org  Mon Sep  9 23:51:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Sep 2013 21:51:20 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378763480.54.0.948242421873.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Why? Many custom dict-like classes aren't.

And this is weird (issue10977).

> Can you explain how?

By patching Objects/dictobject.c of course. I suppose it should require changing about 400 lines of code, a little more than for IdentityDict. When you provides the specification perhaps I will provide a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 23:54:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 21:54:18 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378763480.54.0.948242421873.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378763653.2502.18.camel@fsol>


Antoine Pitrou added the comment:

> By patching Objects/dictobject.c of course.

Am I stupid :-)

> I suppose it should require changing about 400 lines of code, a little
> more than for IdentityDict. When you provides the specification
> perhaps I will provide a patch.

Well, take a look at the code I've pointed to above. I'm curious to know
how you'll integrate it in dictobject.c without slowing down normal dict
objects, and without making them bigger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Mon Sep  9 23:56:42 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 09 Sep 2013 21:56:42 +0000
Subject: [issue18991] Overriding OrderedDict.__getitem__() doesn't work
In-Reply-To: <1378763406.5.0.0321724375688.issue18991@psf.upfronthosting.co.za>
Message-ID: <1378763802.25.0.668326495478.issue18991@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Your __getitem__ never returns the result of OrderedDict.__getitem__

----------
nosy: +alex
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18991>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:16:24 2013
From: report at bugs.python.org (Davi Post)
Date: Mon, 09 Sep 2013 22:16:24 +0000
Subject: [issue18991] Overriding OrderedDict.__getitem__() doesn't work
In-Reply-To: <1378763802.25.0.668326495478.issue18991@psf.upfronthosting.co.za>
Message-ID: <CAAfDULrCsP4j2k+mPEYu-kKyoyacndDGUMV2ozuHnyxRnBnCvQ@mail.gmail.com>


Davi Post added the comment:

Oops. Thanks.  :-{

On Mon, Sep 9, 2013 at 4:56 PM, Alex Gaynor <report at bugs.python.org> wrote:

>
> Alex Gaynor added the comment:
>
> Your __getitem__ never returns the result of OrderedDict.__getitem__
>
> ----------
> nosy: +alex
> resolution:  -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18991>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18991>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:18:34 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Sep 2013 22:18:34 +0000
Subject: [issue14937] IDLE's deficiency in the completion of file names
 (Python 32, Windows XP)
In-Reply-To: <1338225445.23.0.00208814754009.issue14937@psf.upfronthosting.co.za>
Message-ID: <1378765114.28.0.510656846315.issue14937@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am not currently seeing the problem I reported, so closing. If I type past / and hit ^space, I sometimes get an empty listbox, but I do not yet have a consistent failing case. Will open a new issue if/when I get one.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14937>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:22:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Sep 2013 22:22:29 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378765349.66.0.143534327782.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I'm curious to know how you'll integrate it in dictobject.c without slowing down normal dict objects, and without making them bigger.

It of course will make a size of source file bigger, but shouldn't affect a size or performance of normal dicts. A dict object contains dk_lookup. Constructor for keyed dict (subclass of ) should initialize it with specialized function which calls the "key" function and recalculate a hash (yes, with this simple approach a hash will be calculated twice, for original and for transformed keys). Hmm, actually it can be even simpler than for IdentityDict (for which not calculating a hash was important). Also some other methods which relies on dict implementation details (e.g. making a copy of dict) should be modified.

The most cumbersome part is the tests. Unfortunately I lost my tests for IdentityDict (used hg diff without --git). It will be good if your provide complete test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:25:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 22:25:26 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378765526.33.0.369775593614.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It of course will make a size of source file bigger, but shouldn't
> affect a size or performance of normal dicts. A dict object contains
> dk_lookup.

You need to keep both the original keys and the transformed keys. It's not only about transforming keys on lookup. Otherwise, yes, it's trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:27:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Sep 2013 22:27:00 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378765620.48.0.23018906699.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> It will be good if your provide complete test suite.

... Again, take a look at the code I've posted above ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:36:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Sep 2013 22:36:54 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378756183.09.0.056863875637.issue18989@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dk8OqJHF+4XF2c-d+kdBe=2p9UGGhatuu+GwGGr8kq2g@mail.gmail.com>


Nick Coghlan added the comment:

I don't recall this *particular* wrinkle being discussed. Silently failing
to define one of the requested enum members seems quite dubious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Tue Sep 10 00:38:23 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 09 Sep 2013 22:38:23 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378766303.38.0.188402321556.issue18943@psf.upfronthosting.co.za>


paul j3 added the comment:

This patch uses a narrow criteria - if `_get_values()` sets the value to `action.default`, then argument counts as 'not present'.  I am setting a `using_default` flag in `_get_values`, and return it for use by `take_action`.

In effect, the only change from previous behavior is that small ints (<257) now behave like large ints, strings and other objects.

It removes the nonstandard 'is not action.default' test, and should behave consistently across all platforms (including pypy).

----------
keywords: +patch
Added file: http://bugs.python.org/file31704/patch_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Tue Sep 10 03:02:26 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Sep 2013 01:02:26 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
Message-ID: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>


New submission from Tim Peters:

Don't know whether this is new.  Found it running the test suite under a 3.4.0a2 freshly installed from the python.org .msi installer:

== CPython 3.4.0a2 (v3.4.0a2:9265a2168e2c+, Sep 8 2013, 19:41:05) [MSC v.1600 32 bit (Intel)]
==   Windows-Vista-6.0.6002-SP2 little-endian

`regrtest -v test_sax` output attached.  Interestingly, test_sax passes under the tip HG Pythons I build myself.

Didn't we recently fix something like this???  Appears to be a line-end problem.  Ya!  Whoever builds the Windows installer needs to delete directory Lib\test\xmltestdata on their box, and then do "hg revert" on that directory to get fresh copies of the test data.  .hgeol was changed to treat those files as binary, but Mercurial doesn't replace the files automatically just because .hgeol changed.

----------
components: Tests
files: test_sax.out
messages: 197415
nosy: tim.peters
priority: normal
severity: normal
status: open
title: test_sax fails on Windows under 3.4.0a2
versions: Python 3.4
Added file: http://bugs.python.org/file31705/test_sax.out

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 03:48:59 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 10 Sep 2013 01:48:59 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378777739.77.0.795650345681.issue18992@psf.upfronthosting.co.za>


Ned Deily added the comment:

Martin builds the Windows installers.

----------
nosy: +loewis, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 04:53:39 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Sep 2013 02:53:39 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <1378781619.29.0.162390660375.issue18929@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Cool.  Latest patch has a slight doc fix for getmembers.

Will commit on Friday if no other pertinent feedback.

----------
assignee:  -> ethan.furman
stage:  -> patch review
Added file: http://bugs.python.org/file31706/issue18929.stoneleaf.04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Tue Sep 10 04:58:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Sep 2013 02:58:28 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <3cYrXg5TpMz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset fe5c03fb0ff6 by Senthil Kumaran in branch '3.3':
Document Fraction's numerator and denominator properties.
http://hg.python.org/cpython/rev/fe5c03fb0ff6

New changeset 5fb700ca3fd5 by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/5fb700ca3fd5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Tue Sep 10 04:59:58 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Sep 2013 02:59:58 +0000
Subject: [issue18800] Document Fraction's numerator and denominator properties
In-Reply-To: <1377104746.66.0.571132107535.issue18800@psf.upfronthosting.co.za>
Message-ID: <1378781998.63.0.381929678394.issue18800@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed in applicable versions 3.3 and 3.4.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18800>
_______________________________________

From report at bugs.python.org  Tue Sep 10 05:00:22 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 10 Sep 2013 03:00:22 +0000
Subject: [issue18734] Berkeley DB versions 4.4-4.9 are not discovered by
 setup.py
In-Reply-To: <1376450123.08.0.865805118992.issue18734@psf.upfronthosting.co.za>
Message-ID: <1378782022.01.0.391515659935.issue18734@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +benjamin.peterson
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18734>
_______________________________________

From report at bugs.python.org  Tue Sep 10 05:28:30 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Sep 2013 03:28:30 +0000
Subject: [issue18281] tarfile defines stat constants
In-Reply-To: <1371912078.43.0.227039082522.issue18281@psf.upfronthosting.co.za>
Message-ID: <1378783710.41.0.89177195055.issue18281@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Interestingly enough, the two constants that are used are prefixed with `stat`.

Patch attached.

Adios!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18281>
_______________________________________

From report at bugs.python.org  Tue Sep 10 05:29:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Sep 2013 03:29:01 +0000
Subject: [issue18281] tarfile defines stat constants
In-Reply-To: <1371912078.43.0.227039082522.issue18281@psf.upfronthosting.co.za>
Message-ID: <1378783741.95.0.0757051763982.issue18281@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31707/issue18281.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18281>
_______________________________________

From report at bugs.python.org  Tue Sep 10 07:15:46 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Sep 2013 05:15:46 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378790146.59.0.333540854581.issue18967@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Couple of strategies I thought for tacking this problem.

1) Documenting the resolution of NEWS specific merge conflict. Observing/recording when those arises and when it was there was no-conflict will be helpful.  This could help us in organizing NEWS file in a manner that less conflicts occur.

2) Automatic generation of NEWS file from commit logs. We can tag commit logs like #NEWS-Lib-2.7, #NEWS-Core-3.4 and NEWS file can be auto generated from the log. This could be interesting, it could also be error prone. That's probably the reason why we (or any other OSS project) has not adopted this method already.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Tue Sep 10 07:40:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Sep 2013 05:40:21 +0000
Subject: [issue18815] DOCUMENTATION: "mmap .close()" doesn't close the
 underlying file
In-Reply-To: <1377231601.59.0.456805422296.issue18815@psf.upfronthosting.co.za>
Message-ID: <3cYw7S3v0gz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 443d12b61e5b by Senthil Kumaran in branch '2.7':
Clarify mmap.close method  behavior.  Addresses issue  #18815
http://hg.python.org/cpython/rev/443d12b61e5b

New changeset 373907ca13e0 by Senthil Kumaran in branch '3.3':
Clarify mmap.close method  behavior.  Addresses issue  #18815
http://hg.python.org/cpython/rev/373907ca13e0

New changeset 377bd6e0f61c by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/377bd6e0f61c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18815>
_______________________________________

From report at bugs.python.org  Tue Sep 10 07:41:08 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 Sep 2013 05:41:08 +0000
Subject: [issue18815] DOCUMENTATION: "mmap .close()" doesn't close the
 underlying file
In-Reply-To: <1377231601.59.0.456805422296.issue18815@psf.upfronthosting.co.za>
Message-ID: <1378791668.91.0.697711934137.issue18815@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

This is addressed. Thanks for the patch, Anoop.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18815>
_______________________________________

From report at bugs.python.org  Tue Sep 10 08:55:03 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Sep 2013 06:55:03 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
Message-ID: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/unittest/test/testmock/testmock.py, there are two test_attribute_deletion. One of them is overshadowed (not executed) by the other.

    def test_attribute_deletion(self):
        # this behaviour isn't *useful*, but at least it's now tested...
        for Klass in Mock, MagicMock, NonCallableMagicMock, NonCallableMock:
            m = Klass()
            original = m.foo
            m.foo = 3
            del m.foo
            self.assertEqual(m.foo, original)

            new = m.foo = Mock()
            del m.foo
            self.assertEqual(m.foo, new)

    def test_attribute_deletion(self):
        for mock in Mock(), MagicMock():
            self.assertTrue(hasattr(mock, 'm'))

            del mock.m
            self.assertFalse(hasattr(mock, 'm'))

            del mock.f
            self.assertFalse(hasattr(mock, 'f'))
            self.assertRaises(AttributeError, getattr, mock, 'f')

They are testing the same thing but with different expectations. The first one is invalid and should be removed. The patch altered a bit of the second test to incorporate more mock classes.

----------
components: Tests
files: remove_wrongly_test_in_testmock.patch
keywords: patch
messages: 197424
nosy: vajrasky
priority: normal
severity: normal
status: open
title: There is an overshadowed and invalid test in testmock.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31708/remove_wrongly_test_in_testmock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Tue Sep 10 09:08:30 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Sep 2013 07:08:30 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
Message-ID: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Modules/fcntlmodule.c, there is a code to insert symbolic constants to the module.

    all_ins(m);

But we don't check the return code of the function whether it is successful or not, unlike in posix module in which we check it.

    if (all_ins(m))
        return NULL;

Attached the patch to add checking of the return code of all_ins function in fcntl module file.

----------
components: Extension Modules
files: check_return_code_all_ins_in_fcntl.patch
keywords: patch
messages: 197425
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Inside fcntl module, we does not check the return code of all_ins function
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31709/check_return_code_all_ins_in_fcntl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18994>
_______________________________________

From report at bugs.python.org  Tue Sep 10 09:51:10 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Tue, 10 Sep 2013 07:51:10 +0000
Subject: [issue18903] IDLE file-completion is case-sensitive in Windows
In-Reply-To: <1378085615.28.0.091077723559.issue18903@psf.upfronthosting.co.za>
Message-ID: <1378799470.3.0.293320202738.issue18903@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I've written a patch that sort of implements the functionality that makes the most sense to me.  The problem is it only works right for the first entry.  It's kind of wonky and I'm not entirely sure how it behaves, nor do I know the cause of the bug, but it's a start.

----------
keywords: +patch
Added file: http://bugs.python.org/file31710/cpython-idle-18903-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18903>
_______________________________________

From report at bugs.python.org  Tue Sep 10 10:06:01 2013
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 10 Sep 2013 08:06:01 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1378800361.75.0.428719476146.issue18943@psf.upfronthosting.co.za>


Armin Rigo added the comment:

The patch looks good to me.  It may break existing code, though, as reported on https://bugs.pypy.org/issue1595.  I would say that it should only go to trunk.  We can always fix PyPy (at Python 2.7) in a custom manner, in a "bug-to-bug" compatibility mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18943>
_______________________________________

From report at bugs.python.org  Tue Sep 10 11:14:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Sep 2013 09:14:23 +0000
Subject: [issue18995] Enum does not work with reversed
Message-ID: <1378804463.14.0.741296151335.issue18995@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

cutecat at amiau:~/cpython$ cat /tmp/innerplanets.py 
from enum import Enum

class innerplanets(Enum):
    mercury = 1
    venus = 2
    earth = 3
    mars = 4

for planet in innerplanets:
    print(planet)
for planet in reversed(innerplanets):
    print(planet)
cutecat at amiau:~/cpython$ ./python /tmp/innerplanets.py 
innerplanets.mercury
innerplanets.venus
innerplanets.earth
innerplanets.mars
Traceback (most recent call last):
  File "/tmp/innerplanets.py", line 11, in <module>
    for planet in reversed(innerplanets):
  File "/home/cutecat/cpython/Lib/enum.py", line 255, in __getitem__
    return cls._member_map_[name]
KeyError: 3

Attached the patch to add support for reversed in enum.

----------
components: Library (Lib)
files: add_reversed_support_for_enum.patch
keywords: patch
messages: 197428
nosy: ethan.furman, vajrasky
priority: normal
severity: normal
status: open
title: Enum does not work with reversed
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31711/add_reversed_support_for_enum.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18995>
_______________________________________

From report at bugs.python.org  Tue Sep 10 11:28:42 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 10 Sep 2013 09:28:42 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1378805322.37.0.221018295822.issue1565525@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

I'm happy to change the function name, though I'll note that the traceback module does have print_tb(), format_tb() and extract_tb(). 

I'm OK with both of Victor's suggestions but personally slightly prefer traceback.clear_frames(tb).

Rationale: People who are keeping tracebacks around and want to save memory are probably using other functions from the traceback module, and the module has fairly short names (print_tb, format_exception) so I doubt they'll often do 'from traceback import clear_traceback_frames'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Tue Sep 10 11:35:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Sep 2013 09:35:11 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378805711.14.0.0331797895411.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(now relayed on python-dev)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 11:41:10 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Sep 2013 09:41:10 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378806070.31.0.257512521344.issue18992@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Is there an easy way to recheck the entire tree, possibly reverting any files that don't match the content that they should have? I'd rather not throw the tree away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 12:10:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Sep 2013 10:10:11 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378807811.76.0.429296328557.issue18992@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

hg update -C default

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 13:51:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Sep 2013 11:51:47 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
Message-ID: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Error message in assertEqual() is not vary useful when compared long strings with long common prefix. It looks as:

'For the first time in his life h [truncated]...' != 'For the first time in his life h [truncated]...'

With the proposed patch it will look as:

'For [25 chars]e he seemed to be vividly aware of his own existence.' != 'For [25 chars]e he felt humble. He perceived how misgui[105 chars]ers.'

New algorithm splits strings on common prefix and differing suffixes, shortens every part if it is too long, and concatenates them back. So user always see the start and the end of string, and the place of first difference with some characters before and after.

----------
components: Tests
files: assertEqual_shorten.patch
keywords: patch
messages: 197433
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: unittest: more helpful truncating long strings
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31712/assertEqual_shorten.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Tue Sep 10 14:38:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Sep 2013 12:38:08 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378816688.02.0.521979587817.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm uploading a pure Python transformdict implementation + tests, for Serhiy's benefits (and others') :-)

----------
keywords: +patch
Added file: http://bugs.python.org/file31713/transform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 14:44:40 2013
From: report at bugs.python.org (Alexander Kruppa)
Date: Tue, 10 Sep 2013 12:44:40 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1378817079.98.0.803619713736.issue16564@psf.upfronthosting.co.za>


Alexander Kruppa added the comment:

It seems to me that this issue is not fixed correctly yet. I've tried Python 3.3.2:
~/build/Python-3.3.2$ ./python --version
Python 3.3.2

When modifying the test case in Lib/test/test_email/test_email.py like this:

--- Lib/test/test_email/test_email.py	2013-05-15 18:32:55.000000000 +0200
+++ Lib/test/test_email/test_email_mine.py	2013-09-10 14:22:08.160089440 +0200
@@ -1461,17 +1461,17 @@
         # Issue 16564: This does not produce an RFC valid message, since to be
         # valid it should have a CTE of binary.  But the below works in
         # Python2, and is documented as working this way.
-        bytesdata = b'\xfa\xfb\xfc\xfd\xfe\xff'
+        bytesdata = b'\x0b\xfa\xfb\xfc\xfd\xfe\xff'
         msg = MIMEApplication(bytesdata, _encoder=encoders.encode_noop)
         # Treated as a string, this will be invalid code points.
-        self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
+        # self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
         self.assertEqual(msg.get_payload(decode=True), bytesdata)
         s = BytesIO()
         g = BytesGenerator(s)
         g.flatten(msg)
         wireform = s.getvalue()
         msg2 = email.message_from_bytes(wireform)
-        self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
+        # self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
         self.assertEqual(msg2.get_payload(decode=True), bytesdata)

then running:

./python ./Tools/scripts/run_tests.py test_email

results in:

======================================================================
FAIL: test_binary_body_with_encode_noop (test_email_mine.TestMIMEApplication)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/localdisk/kruppaal/build/Python-3.3.2/Lib/test/test_email/test_email_mine.py", line 1475, in test_binary_body_with_encode_noop
    self.assertEqual(msg2.get_payload(decode=True), bytesdata)
AssertionError: b'\x0b\n\xfa\xfb\xfc\xfd\xfe\xff' != b'\x0b\xfa\xfb\xfc\xfd\xfe\xff'

The '\x0b' byte is incorrectly translated to '\x0b\n', i.e., a New Line character is inserted.

Encoding the bytes array:
bytes(range(256))

results output data (MIME Header stripped):

0000000: 0001 0203 0405 0607 0809 0a0b 0a0c 0a0a  ................
0000010: 0e0f 1011 1213 1415 1617 1819 1a1b 1c0a  ................
0000020: 1d0a 1e0a 1f20 2122 2324 2526 2728 292a  ..... !"#$%&'()*
0000030: 2b2c 2d2e 2f30 3132 3334 3536 3738 393a  +,-./0123456789:
0000040: 3b3c 3d3e 3f40 4142 4344 4546 4748 494a  ;<=>?@ABCDEFGHIJ
0000050: 4b4c 4d4e 4f50 5152 5354 5556 5758 595a  KLMNOPQRSTUVWXYZ
0000060: 5b5c 5d5e 5f60 6162 6364 6566 6768 696a  [\]^_`abcdefghij
0000070: 6b6c 6d6e 6f70 7172 7374 7576 7778 797a  klmnopqrstuvwxyz
0000080: 7b7c 7d7e 7f80 8182 8384 8586 8788 898a  {|}~............
0000090: 8b8c 8d8e 8f90 9192 9394 9596 9798 999a  ................
00000a0: 9b9c 9d9e 9fa0 a1a2 a3a4 a5a6 a7a8 a9aa  ................
00000b0: abac adae afb0 b1b2 b3b4 b5b6 b7b8 b9ba  ................
00000c0: bbbc bdbe bfc0 c1c2 c3c4 c5c6 c7c8 c9ca  ................
00000d0: cbcc cdce cfd0 d1d2 d3d4 d5d6 d7d8 d9da  ................
00000e0: dbdc ddde dfe0 e1e2 e3e4 e5e6 e7e8 e9ea  ................
00000f0: ebec edee eff0 f1f2 f3f4 f5f6 f7f8 f9fa  ................
0000100: fbfc fdfe ff                             .....

That is, a '\n' is inserted after '\x0b', '\x1c', '\x1d', and '\x1e', 
and '\x0d' is replaced by '\n\n'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16564>
_______________________________________

From report at bugs.python.org  Tue Sep 10 14:57:51 2013
From: report at bugs.python.org (Dan Nicholson)
Date: Tue, 10 Sep 2013 12:57:51 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
 exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1378817871.17.0.0932630564436.issue4636@psf.upfronthosting.co.za>


Dan Nicholson added the comment:

It turns out this is pretty easy to fix by just changing the stub to import builtins or __builtin__ depending on the python install version. Attached are patches that fix this for both the default and 2.7 branches.

My test case is a pure python module with an install script. I've rebuilt the wininst stub for both default (3.3) with VS2010 Express and 2.7 with VS2008 Express. I then built installers and ran them in both directions: installer created with python-2.7 and installed into python-3.3, and an installer created with python-3.3 and installed into python-2.7. Both worked fine with no warnings.

I've attached the stubs I built in case they're helpful. wininst-10.0-compat.exe is the 32 bit stub for default/3.3. wininst-9.0-compat-2.7.exe is the 32 bit stub for 2.7.

----------
keywords: +patch
nosy: +dbn
Added file: http://bugs.python.org/file31714/wininst-compat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Tue Sep 10 14:58:31 2013
From: report at bugs.python.org (Dan Nicholson)
Date: Tue, 10 Sep 2013 12:58:31 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
 exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1378817911.39.0.0783426521727.issue4636@psf.upfronthosting.co.za>


Changes by Dan Nicholson <dbn.lists at gmail.com>:


Added file: http://bugs.python.org/file31715/wininst-compat-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Tue Sep 10 14:59:16 2013
From: report at bugs.python.org (Dan Nicholson)
Date: Tue, 10 Sep 2013 12:59:16 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
 exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1378817956.93.0.00579729280267.issue4636@psf.upfronthosting.co.za>


Changes by Dan Nicholson <dbn.lists at gmail.com>:


Added file: http://bugs.python.org/file31716/wininst-10.0-compat.exe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Tue Sep 10 14:59:37 2013
From: report at bugs.python.org (Dan Nicholson)
Date: Tue, 10 Sep 2013 12:59:37 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
 exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1378817977.71.0.752390309906.issue4636@psf.upfronthosting.co.za>


Changes by Dan Nicholson <dbn.lists at gmail.com>:


Added file: http://bugs.python.org/file31717/wininst-9.0-compat-2.7.exe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Tue Sep 10 15:30:43 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 10 Sep 2013 13:30:43 +0000
Subject: [issue18281] tarfile defines stat constants
In-Reply-To: <1371912078.43.0.227039082522.issue18281@psf.upfronthosting.co.za>
Message-ID: <1378819843.38.0.610073430306.issue18281@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

lgtm. kill 'em

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18281>
_______________________________________

From report at bugs.python.org  Tue Sep 10 15:37:48 2013
From: report at bugs.python.org (Daniel)
Date: Tue, 10 Sep 2013 13:37:48 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378820268.25.0.958656468254.issue17797@psf.upfronthosting.co.za>


Daniel added the comment:

After contacting Microsoft they answered that they cannot fix that within the VS2012 or VS2013 cycle. Very bad. Any ideas?

----------
nosy: +m_python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Tue Sep 10 15:38:58 2013
From: report at bugs.python.org (Dan Nicholson)
Date: Tue, 10 Sep 2013 13:38:58 +0000
Subject: [issue11598] missing afxres.h error when building bdist_wininst in
 Visual Studio 2008 Express
In-Reply-To: <1300472926.52.0.331223446631.issue11598@psf.upfronthosting.co.za>
Message-ID: <1378820338.48.0.299082287362.issue11598@psf.upfronthosting.co.za>


Dan Nicholson added the comment:

Like the previous users, I've only got VS Express, so I can't tell exactly what happens when you have VS Pro and it generates the install.rc file. However, I might as well post this fuller patch, which I think would do the right thing since it also fixes the part where the regeneration of the '#include "afxres.h"' would happen.

I've used this in the installer for both 3.3 and 2.7 and not seen any adverse effects.

----------
keywords: +patch
nosy: +dbn
Added file: http://bugs.python.org/file31718/wininst-no-afxres.h.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11598>
_______________________________________

From report at bugs.python.org  Tue Sep 10 15:49:20 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 13:49:20 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
Message-ID: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

On the tip of 3.3, I've found `Element.__getstate__` doesn't work and neither as `pickle.dumps(Element)` under certain circumstances.

This crashes:
  e1 = ElementTree().parse('houses.xml')
  e1.__getstate__()

This doesn't crash:
  e2 = ElementTree().parse('houses.xml')
  e2.text = 'some'
  e2.__getstate__()

But still, both of these crash:
  pickle.dumps(e1)
  pickle.dumps(e2)

----------
components: Extension Modules
files: houses.xml
messages: 197440
nosy: Kronuz, eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: Crash when using pickle and ElementTree
versions: Python 3.3
Added file: http://bugs.python.org/file31719/houses.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:37:01 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 14:37:01 +0000
Subject: [issue18998] iter() not working in ElementTree
Message-ID: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

The added iter/itertext methods in Element are not working under certain circumstances (crashes):

This crashes:
  e = ElementTree().parse('/Users/kronuz/Desktop/tests/houses.xml')
  e.iter()

But the problem is not there if I use bootstrapped iterators instead (from the previous commit to the one introducing Element iterator)

----------
components: Extension Modules
files: houses.xml
messages: 197441
nosy: Kronuz, eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: iter() not working in ElementTree
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file31720/houses.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18998>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:37:24 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 10 Sep 2013 14:37:24 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
 exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1378823844.85.0.145169476839.issue4636@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think the exe files are specific to one Python version, so the version check would not be necessary.  I may be wrong though, as I?m not a windows dev or user, so I?m adding Mark to this issue.

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:50:50 2013
From: report at bugs.python.org (irakli)
Date: Tue, 10 Sep 2013 14:50:50 +0000
Subject: [issue18998] iter() not working in ElementTree
In-Reply-To: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>
Message-ID: <1378824650.51.0.407225876355.issue18998@psf.upfronthosting.co.za>


irakli added the comment:

Can you clearify under which circumstances python 3.3 crashes?

----------
nosy: +iraklid94

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18998>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:53:41 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 14:53:41 +0000
Subject: [issue18999] Allow multiple calls to multiprocessing.set_start_method
Message-ID: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>


New submission from Lars Buitinck:

The new multiprocessing based on forkserver (issue8713) looks great, but it has two problems. The first:

"set_start_method() should not be used more than once in the program."

The documentation does not explain what the effect of calling it twice would be. Judging from the documentation, it should be possible to do

start_method = get_start_method()
if start_method is None:
    set_start_method('forkserver')

but this code shows the second problem: it always succeeds with the (undocumented!) side-effect of setting the start method in get_start_method, to the system default, if it hasn't been set already.

I was just going to forge a patch for joblib (http://pythonhosted.org/joblib/) to set the start method to forkserver at import time. But in the current state of affairs, it would be impossible for the user to safely override the start method before importing joblib, because joblib can't figure out if it's been set already without setting it.

The enclosed patch solves the problem by making the new functions more robust:

* get_start_method no longer sets anything, but returns None if the start method has not been set already;
* set_start_method raises a RuntimeError (for want of a better exception type) when resetting the start method is attempted.

Unfortunately, I had to hack up the tests a bit, because they were violating the set_start_method contract. There is a test for the new set_start_method behavior, though, and all {fork,forkserver,spawn} tests pass on Linux.

----------
components: Library (Lib)
files: mp_getset_start_method.patch
keywords: patch
messages: 197444
nosy: larsmans
priority: normal
severity: normal
status: open
title: Allow multiple calls to multiprocessing.set_start_method
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31721/mp_getset_start_method.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:53:59 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 10 Sep 2013 14:53:59 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378824839.65.0.814408486562.issue18986@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

With the current patch __repr__() will fail if the untransformed key is unhashable:

>>> d = collections.transformdict(id)
>>> L = [1,2,3]
>>> d[L] = None 
>>> d.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Repos\cpython-dirty\lib\collections\abc.py", line 444, in __repr__
    return '{0.__class__.__name__}({0._mapping!r})'.format(self)
  File "C:\Repos\cpython-dirty\lib\collections\__init__.py", line 944, in __repr__
    self._transform, repr(dict(self)))
TypeError: unhashable type: 'list'

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:56:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Sep 2013 14:56:48 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378824839.65.0.814408486562.issue18986@psf.upfronthosting.co.za>
Message-ID: <914855913.51107622.1378825002056.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> With the current patch __repr__() will fail if the untransformed key
> is unhashable:

Yeah, the __repr__() implementation will be a bit annoying to get right :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 16:59:57 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 14:59:57 +0000
Subject: [issue18999] Allow multiple calls to multiprocessing.set_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378825197.13.0.698622203319.issue18999@psf.upfronthosting.co.za>


Changes by Lars Buitinck <L.J.Buitinck at uva.nl>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:05:56 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 15:05:56 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378825556.55.0.866946260476.issue18999@psf.upfronthosting.co.za>


Changes by Lars Buitinck <larsmans at gmail.com>:


----------
title: Allow multiple calls to multiprocessing.set_start_method -> Robustness issues in multiprocessing.{get,set}_start_method

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:13:25 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Tue, 10 Sep 2013 15:13:25 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378826005.85.0.961206776246.issue18999@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

Related question: is there any good reason that would prevent to pass a custom `start_method` kwarg to the `Pool` constructor to make it use an alternative `Popen` instance (that is an instance different from the  `multiprocessing._Popen` singleton)?

This would allow libraries such as joblib to keep minimal side effect by try to impact the default multiprocessing runtime as low as possible.

----------
nosy: +Olivier.Grisel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:29:40 2013
From: report at bugs.python.org (Howitzer21)
Date: Tue, 10 Sep 2013 15:29:40 +0000
Subject: [issue19000] Alt + <Num> Does Not Work in IDLE.
Message-ID: <1378826980.96.0.574950615331.issue19000@psf.upfronthosting.co.za>


New submission from Howitzer21:

While Num Lock is in use, if I hold Alt, type 234, then release Alt, ? is supposed to be printed (and it is printed in most other programs).  If I try to do this in IDLE, however, IDLE will toggle its maximization along the y-axis and move the cursor to the beginning of the line, without printing anything.

----------
components: IDLE
messages: 197448
nosy: Howitzer21
priority: normal
severity: normal
status: open
title: Alt + <Num> Does Not Work in IDLE.
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19000>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:32:30 2013
From: report at bugs.python.org (Howitzer21)
Date: Tue, 10 Sep 2013 15:32:30 +0000
Subject: [issue19000] Alt + <Num> Does Not Work in IDLE.
In-Reply-To: <1378826980.96.0.574950615331.issue19000@psf.upfronthosting.co.za>
Message-ID: <1378827150.65.0.352522509682.issue19000@psf.upfronthosting.co.za>


Howitzer21 added the comment:

Sorry, it may be a UTF-8 issue.  I would delete this, but I don't see a way to do so.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19000>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:38:48 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 15:38:48 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378827528.45.0.103183867926.issue18999@psf.upfronthosting.co.za>


Changes by Lars Buitinck <larsmans at gmail.com>:


Removed file: http://bugs.python.org/file31721/mp_getset_start_method.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:39:13 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 15:39:13 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378827553.48.0.123574102484.issue18999@psf.upfronthosting.co.za>


Lars Buitinck added the comment:

Cleaned up the patch.

----------
Added file: http://bugs.python.org/file31722/mp_getset_start_method.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:48:30 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 15:48:30 +0000
Subject: [issue18998] iter() not working in ElementTree
In-Reply-To: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>
Message-ID: <1378828110.14.0.408692135777.issue18998@psf.upfronthosting.co.za>


Germ?n M. Bravo added the comment:

It crashes when I run that code snippet I posted (using the attached xml file) The problem was introduced by the commit that added iterator support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18998>
_______________________________________

From report at bugs.python.org  Tue Sep 10 17:52:49 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 15:52:49 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <1378828369.39.0.0464392888729.issue18997@psf.upfronthosting.co.za>


Germ?n M. Bravo added the comment:

The attached patch fixes the problem (there were some missing JOIN_OBJ())

----------
keywords: +patch
Added file: http://bugs.python.org/file31723/join_obj.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Tue Sep 10 18:04:40 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 10 Sep 2013 16:04:40 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378829080.62.0.248798712771.issue18999@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

With your patch, I think if you call get_start_method() without later calling set_start_method() then the helper process(es) will never be started.

With the current code, popen.Popen() automatically starts the helper processes if they have not already been started.

Also, set_start_method() can have the side-effect of starting helper process(es).  I do not really approve of new processes being started as a side-effect of importing a library.  But it is reasonable for a library to want a specific start method unless the user demands otherwise.

I will have to think this over.


BTW, the reason for discouraging using set_start_method() more than once is because some shared resources are created differently depending on what the current start method is.

For instance using the fork method semaphores are created and then immediately unlinked.  But with the other start methods we must not unlink the semaphore until we are finished with it (while being paranoid about cleanup).

Maybe it would be better to have separate contexts for each start method.  That way joblib could use the forkserver context without interfering with the rest of the user's program.

    from multiprocessing import forkserver_context as mp
    l = mp.Lock()
    p = mp.Process(...)
    with mp.Pool() as pool:
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 18:28:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Sep 2013 16:28:39 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378830519.57.0.77721709999.issue18992@psf.upfronthosting.co.za>


Tim Peters added the comment:

Serhiy, did you test "hg update -C default"?  Didn't work for me :-(

Martin, I don't know an easy way.  eol fiddling in Hg seems brittle :-(

I suppose you could get a fresh clone and then _compare_ the checked-out files to your old clone.  Then, from the old clone, delete the files that don't match.  Then "hg revert -a" in the old clone.  Then check again.  If they all match, throw away the new clone.  But, no, that's not really easy ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 18:31:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Sep 2013 16:31:06 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1378830666.41.0.11927436434.issue18996@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file31712/assertEqual_shorten.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Tue Sep 10 18:32:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Sep 2013 16:32:00 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1378830720.61.0.266643067581.issue18996@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31724/assertEqual_shorten.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Tue Sep 10 18:48:31 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 16:48:31 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <1378831711.78.0.0683776540807.issue18997@psf.upfronthosting.co.za>


Changes by Germ?n M. Bravo <german.mb at gmail.com>:


Removed file: http://bugs.python.org/file31723/join_obj.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Tue Sep 10 18:49:26 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Tue, 10 Sep 2013 16:49:26 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <1378831766.61.0.305661953557.issue18997@psf.upfronthosting.co.za>


Changes by Germ?n M. Bravo <german.mb at gmail.com>:


Added file: http://bugs.python.org/file31725/join_obj.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Tue Sep 10 19:38:02 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 10 Sep 2013 17:38:02 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <1378834682.6.0.374738847776.issue18997@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks for this report, Germ?n (and the other issue as well). I'll do my best to take a look later this week.

----------
assignee:  -> eli.bendersky
stage:  -> patch review
type:  -> behavior
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Tue Sep 10 19:43:59 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 10 Sep 2013 17:43:59 +0000
Subject: [issue18998] iter() not working in ElementTree
In-Reply-To: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>
Message-ID: <1378835039.92.0.783671603208.issue18998@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I'm having trouble reproducing the problem, Germ?n. Running with Python 3.3.2 from a couple of days ago:

Python 3.3.2+ (3.3:0eef1670f316, Sep  8 2013, 08:31:59) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import *
>>> e = ElementTree().parse('houses.xml')
>>> e.iter()
<_elementtree._element_iterator object at 0x7fac621d9aa0>
>>> list(e.iter())
[<Element '{http://dogs.house.local}group' at 0x7fac621e02b8>, <Element '{http://dogs.house.local}house' at 0x7fac621e0368>, <Element '{http://dogs.house.local}id' at 0x7fac621e0418>, <Element '{http://dogs.house.local}dogs' at 0x7fac621e0470>, <Element '{http://dogs.house.local}house' at 0x7fac621e04c8>, <Element '{http://dogs.house.local}id' at 0x7fac621e0520>, <Element '{http://dogs.house.local}dogs' at 0x7fac621e0578>]



Can you provide a patch for the ET tests that I can apply to tip of 3.3 and see this reproduced?

----------
assignee:  -> eli.bendersky
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18998>
_______________________________________

From report at bugs.python.org  Tue Sep 10 19:51:56 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 10 Sep 2013 17:51:56 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378835516.24.0.652586413091.issue18986@psf.upfronthosting.co.za>


?ric Araujo added the comment:

FTR this is one message from the previous thread about this: https://mail.python.org/pipermail/python-ideas/2010-June/007332.html

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 20:12:35 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Sep 2013 18:12:35 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378836755.19.0.465794322295.issue18992@psf.upfronthosting.co.za>


Tim Peters added the comment:

OK, "hg up -C" _can_ work, but it appears to require that "hg stat" shows that the files with the "bad" line endings are modified (M).  That may or may not be the case, depending on lots of things.

Martin, can you verify that (for example) test.xml.out does have \r\n line ends in your tree?  Maybe it doesn't, and the problem really lies elsewhere (unsure - some step in building the .msi, or maybe even the .msi changes line ends during installation - don't know).

I think bad line endings in the tree are most likely, though, since test_sax was failing in the same way for (at least) me and Terry Reddy when building our own Pythons on Windows, before changing .hgeol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 20:15:17 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Sep 2013 18:15:17 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378836917.72.0.716463215486.issue18992@psf.upfronthosting.co.za>


Tim Peters added the comment:

BTW, the reason I wonder whether you don't have bad line ends in your tree is this:  if you did, test_sax would have been failing for you too.  I assume you run the test suite before building the installer ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 20:29:14 2013
From: report at bugs.python.org (Wouter Bolsterlee)
Date: Tue, 10 Sep 2013 18:29:14 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378837754.66.0.00489422528592.issue18962@psf.upfronthosting.co.za>


Wouter Bolsterlee added the comment:

Thanks Raymond, that is exactly what I had in mind (see my previous comment).
Here's a slightly cleaned up version of the patch (stylistic/PEP8 cleanups),
with some benchmarks included below.

In case the two longest iterators have about the same size, no performance
difference can be measured:

$ ./python -m timeit -s 'from heapq import merge' 'for x in merge([], [], [1], range(100), range(100)): pass'

Without patch:

10000 loops, best of 3: 71.2 usec per loop
10000 loops, best of 3: 71.9 usec per loop
10000 loops, best of 3: 71.7 usec per loop

With patch:

10000 loops, best of 3: 71.4 usec per loop
10000 loops, best of 3: 76.7 usec per loop
10000 loops, best of 3: 72.1 usec per loop

As expected, the performance gain is very significant in case one of the
iterators is much longer than the others:

$ python -m timeit -n 100 -s 'from heapq import merge' 'for x in merge([], [], [1], range(100), range(100000)): pass'

Without path:

100 loops, best of 3: 27.8 msec per loop
100 loops, best of 3: 26.9 msec per loop
100 loops, best of 3: 27.7 msec per loop

With patch:

100 loops, best of 3: 6.26 msec per loop
100 loops, best of 3: 6.28 msec per loop
100 loops, best of 3: 6.03 msec per loop

----------
Added file: http://bugs.python.org/file31726/merge3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Tue Sep 10 20:40:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Sep 2013 18:40:47 +0000
Subject: [issue4832] IDLE does not supply a default ext of .py on Windows or
 OS X for new file saves
In-Reply-To: <1231082162.31.0.973834672616.issue4832@psf.upfronthosting.co.za>
Message-ID: <1378838447.56.0.680530833764.issue4832@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

With PEP 434, this can and I think should be backported. I should have done it for 2.7.5 and will try to do soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4832>
_______________________________________

From report at bugs.python.org  Tue Sep 10 21:07:48 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Sep 2013 19:07:48 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378840068.7.0.95568557923.issue18992@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

It turns out that TortoiseHg was showing the files as modified. I have now "reverted" my local changes, so this should be fine now. I was somewhat under time pressure when making the release, so I didn't notice then (and TortoiseHg seems to needs some time also to detect modifications and reversals).

And no, I don't run the test suite when making a release. If a test was failing, I would have to research what the problem is (or ignore the failure), which could easily delay the release by several days. I only verify that IDLE starts and the help file opens.

Thanks for your investigation.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 21:36:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Sep 2013 19:36:13 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
Message-ID: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is on Stefan's "Fedora without threads" buildbot, and it's the sets pretty-printing tests which fail:
http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5119

----------
components: Demos and Tools, Interpreter Core
messages: 197463
nosy: ncoghlan, pitrou, rhettinger, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb fails on Fedora buildbot
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Tue Sep 10 21:40:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Sep 2013 19:40:27 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378842027.58.0.263199526468.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch: fixes repr(), and retains the first key not the last.

----------
Added file: http://bugs.python.org/file31727/transformdict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 22:11:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Sep 2013 20:11:05 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1378843865.1.0.581711916775.issue16564@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's a different bug, and is probably due to the fact that \x0b is considered a line-ending character by the 'splitlines' method.

Could you please open a new issue for this?  It could be that this can't be fixed in Python3 until support for the 'binary' CTE is added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16564>
_______________________________________

From report at bugs.python.org  Tue Sep 10 22:14:12 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Sep 2013 20:14:12 +0000
Subject: [issue18992] test_sax fails on Windows under 3.4.0a2
In-Reply-To: <1378774946.1.0.877126635301.issue18992@psf.upfronthosting.co.za>
Message-ID: <1378844052.25.0.810095179048.issue18992@psf.upfronthosting.co.za>


Tim Peters added the comment:

No problems, Martin - thanks for following up on this! :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18992>
_______________________________________

From report at bugs.python.org  Tue Sep 10 22:59:16 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 20:59:16 +0000
Subject: [issue10977] Concrete object C API considered harmful to subclasses
 of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1378846756.56.0.857027555869.issue10977@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10977>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:00:42 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 21:00:42 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378846842.85.0.496995144184.issue18986@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:02:12 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 21:02:12 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <1378846932.03.0.886638692844.issue18997@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:14:48 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 21:14:48 +0000
Subject: [issue17477] update the bsddb module do build with db 5.x versions
In-Reply-To: <1363671295.4.0.641867038298.issue17477@psf.upfronthosting.co.za>
Message-ID: <1378847688.4.0.885784740045.issue17477@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17477>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:15:05 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 21:15:05 +0000
Subject: [issue18734] Berkeley DB versions 4.4-4.9 are not discovered by
 setup.py
In-Reply-To: <1376450123.08.0.865805118992.issue18734@psf.upfronthosting.co.za>
Message-ID: <1378847705.11.0.60726966512.issue18734@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18734>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:15:33 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Tue, 10 Sep 2013 21:15:33 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378847733.29.0.220318704303.issue18999@psf.upfronthosting.co.za>


Lars Buitinck added the comment:

In my patched version, the private popen.get_start_method gets a kwarg set_if_needed=True. popen.Popen calls that as before, so its behavior should not change, while the public get_start_method sets the kwarg to False.

I realise now that this has the side effect that get_start_method's output changes when multiprocessing has first been used, but then that reflects how the library works. Maybe this should be documented.

As for the contexts, those would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:17:56 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 21:17:56 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a
 64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1378847876.37.0.276978121645.issue18987@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:21:34 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Sep 2013 21:21:34 +0000
Subject: [issue18936] 2.7 distutils getopt chokes on unicode option names
In-Reply-To: <1378411388.86.0.748005801735.issue18936@psf.upfronthosting.co.za>
Message-ID: <1378848094.62.0.0432892972602.issue18936@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18936>
_______________________________________

From report at bugs.python.org  Tue Sep 10 23:48:54 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 10 Sep 2013 21:48:54 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378849734.11.0.787072392464.issue18999@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> In my patched version, the private popen.get_start_method gets a kwarg 
> set_if_needed=True. popen.Popen calls that as before, so its behavior 
> should not change, while the public get_start_method sets the kwarg to 
> False.

My mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Wed Sep 11 04:41:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Sep 2013 02:41:04 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378867264.23.0.534742403345.issue18986@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would *really* like for this to start outside the standard library.
It needs to mature with user feedback before being dumped
in the collections module (which was never intended to be a
giant pile of every collection a person could think of).  

Adding yet more dictionary variants is an example of
way-too-many-ways-to-do-it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Wed Sep 11 08:16:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Sep 2013 06:16:00 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <3cZXt73CQhz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 0e70bf1f32a3 by Raymond Hettinger in branch 'default':
Issue #18962:  Optimize the single iterator case for  heapq.merge()
http://hg.python.org/cpython/rev/0e70bf1f32a3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Wed Sep 11 08:17:32 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Sep 2013 06:17:32 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378880252.17.0.600011965358.issue18962@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Wed Sep 11 08:20:51 2013
From: report at bugs.python.org (David Halter)
Date: Wed, 11 Sep 2013 06:20:51 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
Message-ID: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>


New submission from David Halter:

I recently stumbled over the ``dir`` function not working correctly with classes. This means that ``dir(object)`` won't list ``object.__bases__`` or ``object.__subclasses`` (and many other useful methods).

I think that we should change that. The C function ``type_dir`` (in ``Objects/typeobject.c``) has a documentation entry which states:

"We deliberately don't suck up its __class__, as methods belonging to the metaclass would probably be more confusing than helpful."

I think that that's not true. The current behaviour of ``dir`` is way more confusing, since ``dir`` is typically the tool how we find out about magic methods.

I wrote about it in more details here: http://jedidjah.ch/code/2013/9/8/wrong_dir_function/

----------
components: Interpreter Core
messages: 197471
nosy: davidhalter
priority: normal
severity: normal
status: open
title: ``dir`` function does not work correctly with classes.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 08:50:53 2013
From: report at bugs.python.org (Wouter Bolsterlee)
Date: Wed, 11 Sep 2013 06:50:53 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378882253.61.0.220647773166.issue18962@psf.upfronthosting.co.za>


Wouter Bolsterlee added the comment:

Thanks for the quick response. 

Btw, do I understand correctly code cleanups are not welcome, even when touching the code anyway?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Wed Sep 11 08:51:56 2013
From: report at bugs.python.org (Wouter Bolsterlee)
Date: Wed, 11 Sep 2013 06:51:56 +0000
Subject: [issue18962] Add special case for single iterator in heapq.merge
 function
In-Reply-To: <1378578388.4.0.196112791647.issue18962@psf.upfronthosting.co.za>
Message-ID: <1378882316.96.0.710748940176.issue18962@psf.upfronthosting.co.za>


Wouter Bolsterlee added the comment:

(In case you missed it: my latest comment included a cleaned up version of an earlier patch.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18962>
_______________________________________

From report at bugs.python.org  Wed Sep 11 08:56:08 2013
From: report at bugs.python.org (Daniel)
Date: Wed, 11 Sep 2013 06:56:08 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378882568.09.0.32090295812.issue17797@psf.upfronthosting.co.za>


Daniel added the comment:

Here are some solutions which might help you until MS fixed the bug.

1) Even if the subsystem is Windows one solution is to call AllocConsole() before Py_Initialize() to create a console.

2) Second Solution: If you don't want to open a console and your application has its own output window you could redirect stdout/stderr/stdin with freopen to a temp file first. (e.g: freopen("file.txt","w",stdout);) Call freopen for all std handles before you call Py_Initialize(). You can keep the redirection to the file or after Py_Initialize() succeeded you change the redirection now in Python by redirect sys.stdout to the place you want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 09:26:48 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Wed, 11 Sep 2013 07:26:48 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a
 64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1378884408.91.0.207786386719.issue18987@psf.upfronthosting.co.za>


Sam Ferencik added the comment:

Unfortunately, I don't have a patch.

Some thoughts:

To discover a 32-bit interpreter running on a 64-bit system, we could use
platform.architecture(), which returns
    >>> platform.architecture()
    ('32bit', 'ELF')

What then, though? How do you turn '32bit' to 'linux-i386'? The naive solution
would be to hard-code this as an exception:
- if 32-on-64, use 'i386'
- otherwise, use os.uname()[4], i.e. 'i386' or 'x86_64'

I suspect that's ultra naive, though. The get_platform() code deals with a
number of Unix-like systems (Solaris, AIX, ...). Even if we accepted this
solution only for Linux, leaving the other OSs broken, is 'i386' always the
right answer, or would 'i586' or similar be appropriate in some cases?

We could also take inspiration from Mac OS (_osx_support.get_platform_osx()),
which basically ignores os.uname()[4] completely and constructs the return value
from a set of hard-coded values ('i386' being one of them).

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Wed Sep 11 09:34:21 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Sep 2013 07:34:21 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378884861.83.0.434144936748.issue19002@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 09:35:21 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Sep 2013 07:35:21 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378884921.27.0.597023768047.issue19002@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 09:47:20 2013
From: report at bugs.python.org (Alexander Kruppa)
Date: Wed, 11 Sep 2013 07:47:20 +0000
Subject: [issue19003] email.generator.BytesGenerator corrupts data by changing
 line endings
Message-ID: <1378885640.45.0.020973506597.issue19003@psf.upfronthosting.co.za>


New submission from Alexander Kruppa:

This is a follow-up to #16564. In that issue, BytesGenerator was changed to accept a bytes payload, however processing binary data that way leads to data corruption.

Repost of the update I posted in #16564:

***********************************************************
~/build/Python-3.3.2$ ./python --version
Python 3.3.2

When modifying the test case in Lib/test/test_email/test_email.py like this:

--- Lib/test/test_email/test_email.py	2013-05-15 18:32:55.000000000 +0200
+++ Lib/test/test_email/test_email_mine.py	2013-09-10 14:22:08.160089440 +0200
@@ -1461,17 +1461,17 @@
         # Issue 16564: This does not produce an RFC valid message, since to be
         # valid it should have a CTE of binary.  But the below works in
         # Python2, and is documented as working this way.
-        bytesdata = b'\xfa\xfb\xfc\xfd\xfe\xff'
+        bytesdata = b'\x0b\xfa\xfb\xfc\xfd\xfe\xff'
         msg = MIMEApplication(bytesdata, _encoder=encoders.encode_noop)
         # Treated as a string, this will be invalid code points.
-        self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
+        # self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
         self.assertEqual(msg.get_payload(decode=True), bytesdata)
         s = BytesIO()
         g = BytesGenerator(s)
         g.flatten(msg)
         wireform = s.getvalue()
         msg2 = email.message_from_bytes(wireform)
-        self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
+        # self.assertEqual(msg.get_payload(), '\uFFFD' * len(bytesdata))
         self.assertEqual(msg2.get_payload(decode=True), bytesdata)

then running:

./python ./Tools/scripts/run_tests.py test_email

results in:

======================================================================
FAIL: test_binary_body_with_encode_noop (test_email_mine.TestMIMEApplication)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/localdisk/kruppaal/build/Python-3.3.2/Lib/test/test_email/test_email_mine.py", line 1475, in test_binary_body_with_encode_noop
    self.assertEqual(msg2.get_payload(decode=True), bytesdata)
AssertionError: b'\x0b\n\xfa\xfb\xfc\xfd\xfe\xff' != b'\x0b\xfa\xfb\xfc\xfd\xfe\xff'

The '\x0b' byte is incorrectly translated to '\x0b\n', i.e., a New Line character is inserted.

Encoding the bytes array:
bytes(range(256))

results output data (MIME Header stripped):

0000000: 0001 0203 0405 0607 0809 0a0b 0a0c 0a0a  ................
0000010: 0e0f 1011 1213 1415 1617 1819 1a1b 1c0a  ................
0000020: 1d0a 1e0a 1f20 2122 2324 2526 2728 292a  ..... !"#$%&'()*
0000030: 2b2c 2d2e 2f30 3132 3334 3536 3738 393a  +,-./0123456789:
0000040: 3b3c 3d3e 3f40 4142 4344 4546 4748 494a  ;<=>?@ABCDEFGHIJ
0000050: 4b4c 4d4e 4f50 5152 5354 5556 5758 595a  KLMNOPQRSTUVWXYZ
0000060: 5b5c 5d5e 5f60 6162 6364 6566 6768 696a  [\]^_`abcdefghij
0000070: 6b6c 6d6e 6f70 7172 7374 7576 7778 797a  klmnopqrstuvwxyz
0000080: 7b7c 7d7e 7f80 8182 8384 8586 8788 898a  {|}~............
0000090: 8b8c 8d8e 8f90 9192 9394 9596 9798 999a  ................
00000a0: 9b9c 9d9e 9fa0 a1a2 a3a4 a5a6 a7a8 a9aa  ................
00000b0: abac adae afb0 b1b2 b3b4 b5b6 b7b8 b9ba  ................
00000c0: bbbc bdbe bfc0 c1c2 c3c4 c5c6 c7c8 c9ca  ................
00000d0: cbcc cdce cfd0 d1d2 d3d4 d5d6 d7d8 d9da  ................
00000e0: dbdc ddde dfe0 e1e2 e3e4 e5e6 e7e8 e9ea  ................
00000f0: ebec edee eff0 f1f2 f3f4 f5f6 f7f8 f9fa  ................
0000100: fbfc fdfe ff                             .....

That is, a '\n' is inserted after '\x0b', '\x1c', '\x1d', and '\x1e', 
and '\x0d' is replaced by '\n\n'.

***********************************************************

I suspect this is due to the use of self._write_lines(msg._payload) in BytesGenerator._handle_text(); since _write_lines() mangles line endings.

----------
components: email
messages: 197476
nosy: Alexander.Kruppa, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email.generator.BytesGenerator corrupts data by changing line endings
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19003>
_______________________________________

From report at bugs.python.org  Wed Sep 11 09:48:04 2013
From: report at bugs.python.org (Alexander Kruppa)
Date: Wed, 11 Sep 2013 07:48:04 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1378885684.62.0.616755252371.issue16564@psf.upfronthosting.co.za>


Alexander Kruppa added the comment:

Opened #19003.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16564>
_______________________________________

From report at bugs.python.org  Wed Sep 11 10:41:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 08:41:19 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378888879.75.0.722432525973.issue18967@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Automatic generation of NEWS file from commit logs.

Commit messages can't be modified after being published, this would be annoying to fix typos etc.

>From what I record of the ML discussions, the proposed solutions actually sounded more annoying than the occasional merge annoyance.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Wed Sep 11 10:41:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 08:41:30 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378888890.93.0.575709505304.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a preliminary C implementation.

----------
Added file: http://bugs.python.org/file31728/ctransformdict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Wed Sep 11 11:13:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 09:13:51 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378890830.99.0.904237166146.issue18986@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file31728/ctransformdict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Wed Sep 11 11:15:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 09:15:39 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378890939.64.0.141758476269.issue18986@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31729/ctransformdict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Wed Sep 11 11:20:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 09:20:52 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378891252.39.0.291736573037.issue17797@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, tim.golden, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 11:21:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 09:21:20 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378891280.7.0.143259369753.issue17797@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> high
resolution: out of date -> 
stage:  -> needs patch
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 11:26:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 09:26:17 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378891577.33.0.00214348349074.issue17797@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Which 3.2 version does this break with? As far as I can tell, it should be fixed in 3.2.3: see changeset f15943505db0, issue #7111.

----------
nosy: +pitrou
resolution:  -> fixed
stage: needs patch -> 
status: open -> pending
versions: +Python 3.2 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 12:04:29 2013
From: report at bugs.python.org (Mateusz Loskot)
Date: Wed, 11 Sep 2013 10:04:29 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378893869.88.0.72287607227.issue17797@psf.upfronthosting.co.za>


Mateusz Loskot added the comment:

@Antoine (Re msg197480)

I'm not sure which minor version of Python 3.2 it was, but in my comment in msg187362, I confirmed that I have tested the later version with added is_valid_fd function. As far as I understand, the changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce that is_valid_fd function, which does not seem to solve the problem.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 12:20:13 2013
From: report at bugs.python.org (Timothy Pederick)
Date: Wed, 11 Sep 2013 10:20:13 +0000
Subject: [issue19004] datetime: Read in isoformat() output
Message-ID: <1378894813.85.0.443530732743.issue19004@psf.upfronthosting.co.za>


New submission from Timothy Pederick:

At present, the datetime module does not provide the capability to parse its own output from the isoformat() methods.

strptime() can't handle timezones with colons in them (and anyway it seems to me you'd need to try several possible format strings depending on ' ' vs 'T' separators, presence/absence of microseconds, pres/abs timezone...). Adding this capability would be one option (%f already establishes a precedent for adding codes outside of what C supports).

Another, perhaps superior option would be a specific method for parsing the output of isoformat().

----------
components: Library (Lib)
messages: 197482
nosy: perey
priority: normal
severity: normal
status: open
title: datetime: Read in isoformat() output
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19004>
_______________________________________

From report at bugs.python.org  Wed Sep 11 12:22:22 2013
From: report at bugs.python.org (Evgeny Kapun)
Date: Wed, 11 Sep 2013 10:22:22 +0000
Subject: [issue19005] PyIter_Next crashes if passed a non-iterator
Message-ID: <1378894942.16.0.763585748614.issue19005@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

According to the documentation, PyIter_Next should raise TypeError if passed an object which is not an iterator as an argument. Instead, it calls a function through a null pointer, which leads to a crash.

----------
components: Interpreter Core
messages: 197483
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: PyIter_Next crashes if passed a non-iterator
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19005>
_______________________________________

From report at bugs.python.org  Wed Sep 11 12:36:56 2013
From: report at bugs.python.org (Daniel)
Date: Wed, 11 Sep 2013 10:36:56 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378895816.61.0.894543050399.issue17797@psf.upfronthosting.co.za>


Daniel added the comment:

Sorry, I used the latest Python3.4 branch, I haven't tested this with prior versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 12:51:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Sep 2013 10:51:31 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378896691.12.0.348843458847.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with Antoine, but then as I said I don't run into huge merge conflicts very often.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Wed Sep 11 13:02:26 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Wed, 11 Sep 2013 11:02:26 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378897346.02.0.289162285106.issue18999@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

> Maybe it would be better to have separate contexts for each start method.  That way joblib could use the forkserver context without interfering with the rest of the user's program.

Yes in general it would be great if libraries could customize the multiprocessing default options without impacting any of the module singletons. That also include the ForkingPickler registry for custom: now it's a class attribute. It would be great to be able to scope custom reducers registration to a given multiprocessing.Pool or multiprocessing.Process instance.

Now how to implement that kind of isolation: it could either be done by adding new constructor parameters or new public methods to the Process and Pool classes to be able to customize their behavior while sticking to the OOP paradigm if possible or by using a context manager as you suggested.

I am not sure which option is best. Prototyping both is probably the best way to feel the tradeoffs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Wed Sep 11 13:07:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 11 Sep 2013 11:07:46 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1378897666.92.0.906201368179.issue18967@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

IMHO the status quo is fine.
Most of the time HG gets the merge right on its own.  Some times kdiff3 pops up and asks me to solve the conflict [0].  Rarely something goes wrong so I just revert Misc/NEWS and re-add the entry manually.

> It seems to me that they are much rarer than they were with svn.

I agree -- I think many of us still see merges as something "bad" that should be avoided, while this is generally no longer true with HG (it was with SVN).
A similar argument is "whitespace/PEP8 changes on 3.4 should be avoided because it makes merging changes from 3.3 more difficult".  While it's true that it makes 3.4 diverge from 3.3, IME this doesn't really bother HG and merges usually goes smoothly (there are other arguments against that kind of changes, but I think this is not a very strong one).

[0]: this usually happens when there is an entry in 3.4 only and I'm merging from 3.3.  kdiff3 asks me if it should use the entry I added in 3.3 or the one that is in 3.4, and all I have to do is telling it to keep them both (ctrl+3/ctrl+2).

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Wed Sep 11 13:28:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Sep 2013 11:28:32 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378898912.0.0.884571121636.issue19002@psf.upfronthosting.co.za>


R. David Murray added the comment:

As far as I know dir has always worked this way with classes (certainly back as far as 2.4, which is the oldest python I have on my dev system).  So I doubt that this behavior can be open to change, whether or not we think the original decision was correct.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 13:32:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Sep 2013 11:32:41 +0000
Subject: [issue19004] datetime: Read in isoformat() output
In-Reply-To: <1378894813.85.0.443530732743.issue19004@psf.upfronthosting.co.za>
Message-ID: <1378899161.8.0.959086443466.issue19004@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> datetime: add ability to parse RFC 3339 dates and times
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19004>
_______________________________________

From report at bugs.python.org  Wed Sep 11 13:33:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Sep 2013 11:33:09 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1378899189.35.0.344085513568.issue15873@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +perey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Sep 11 13:34:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 11:34:50 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1378893869.88.0.72287607227.issue17797@psf.upfronthosting.co.za>
Message-ID: <1684239331.53513321.1378899284041.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I'm not sure which minor version of Python 3.2 it was, but in my
> comment in msg187362, I confirmed that I have tested the later
> version with added is_valid_fd function. As far as I understand, the
> changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce
> that is_valid_fd function, which does not seem to solve the problem.

Could you try to investigate this a bit further? Does is_valid_fd()
return true, and why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 14:08:21 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Sep 2013 12:08:21 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378897666.92.0.906201368179.issue18967@psf.upfronthosting.co.za>
Message-ID: <CADiSq7deRLzkwCbVhqKZD+RjHeFPAUG4uvr9J1SaY+zsZJi00w@mail.gmail.com>


Nick Coghlan added the comment:

I don't think I've *ever* had NEWS successfully merge when working on
a bug fix (even after the move to hg). It's one of the reasons I
prefer working on new features, or bugs where the fix is too intrusive
for a maintenance release :P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Wed Sep 11 15:36:11 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Sep 2013 13:36:11 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378906571.54.0.245834669073.issue19002@psf.upfronthosting.co.za>


Ethan Furman added the comment:

It's going to take more than "I think that that's not true," to get a change made.

>From http://docs.python.org/2/library/functions.html#dir :
> 
> Because dir() is supplied primarily as a convenience for use at an
> interactive prompt, it tries to supply an interesting set of names
> more than it tries to supply a rigorously or consistently defined
> set of names [...] .

Currently, `dir(cls)` returns information that tells us how instances of that class will behave.  Because metaclass methods have no direct effect on instance behavior, having dir return metaclass methods and attributes would be confusing.

If you want to know how a class is going to behave you need to `dir(cls.__class__)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 15:46:04 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 11 Sep 2013 13:46:04 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378907164.74.0.705821293126.issue18945@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31730/tempfile_collision_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Wed Sep 11 15:49:12 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Wed, 11 Sep 2013 13:49:12 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1378907352.43.0.169254518837.issue18945@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Removed file: http://bugs.python.org/file31697/tempfile_collision_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Wed Sep 11 16:06:51 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 11 Sep 2013 14:06:51 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1378908411.32.0.91339333325.issue15873@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Wed Sep 11 16:20:41 2013
From: report at bugs.python.org (Yuri Bochkarev)
Date: Wed, 11 Sep 2013 14:20:41 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
 sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1378909241.92.0.672358587192.issue3566@psf.upfronthosting.co.za>


Changes by Yuri Bochkarev <baltazar.bz at gmail.com>:


----------
nosy: +Yuri.Bochkarev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Wed Sep 11 17:45:35 2013
From: report at bugs.python.org (Roy Smith)
Date: Wed, 11 Sep 2013 15:45:35 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
Message-ID: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>


New submission from Roy Smith:

http://docs.python.org/2/library/unittest.html#assert-methods

The docs say, "The TestCase class provides a number of methods to check for and report failures, such as", and then when you scroll a couple of screens down, there's another list, "There are also other methods used to perform more specific checks, such as".  These should be merged into a single list.  There's nothing fundamentally different about the two lists and breaking them into two parts just makes it harder to find what you want.

----------
assignee: docs at python
components: Documentation
messages: 197492
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: UnitTest docs should have a single list of assertions
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19006>
_______________________________________

From report at bugs.python.org  Wed Sep 11 17:55:27 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 11 Sep 2013 15:55:27 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378914927.38.0.621507745568.issue19002@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

-1 classes themselves are objects, so dir should list the attributes/methods of the class object, not the instances.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 18:01:54 2013
From: report at bugs.python.org (Mateusz Loskot)
Date: Wed, 11 Sep 2013 16:01:54 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1684239331.53513321.1378899284041.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CABUeae9NOv_AmMjuMApsb052x+LnUy-UqSLQPMwQgJ5o8dDCAw@mail.gmail.com>


Mateusz Loskot added the comment:

On 11 September 2013 12:34, Antoine Pitrou <report at bugs.python.org> wrote:
>> I'm not sure which minor version of Python 3.2 it was, but in my
>> comment in msg187362, I confirmed that I have tested the later
>> version with added is_valid_fd function. As far as I understand, the
>> changes in http://hg.python.org/cpython/rev/f15943505db0/ introduce
>> that is_valid_fd function, which does not seem to solve the problem.
>
> Could you try to investigate this a bit further? Does is_valid_fd()
> return true, and why?

I have already checked that (see msg187362)

Shortly, is_valid_fd always returns true because fd < 0 is always
false as my tests with Visual Studio 2012 (Visual C++ 11.0 (1700)
confirmed (see also bug report linked in msg188117)

    assert(fdi == 0);
    assert(fdo == 1);
    assert(fde == 2);

IOW, fd is always larger than 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Wed Sep 11 18:10:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 11 Sep 2013 16:10:16 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1378915816.54.0.0360063061436.issue19006@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> There's nothing fundamentally different about the two lists

I made that division because the ones in the first table are the most common and widely used, and are quite general too.
The second table contains assert methods about catching exceptions and warnings, and, while still common, they are different from the first group. 
The third table has additional assertions that are quite specific and not used too often, and many of these have been added later on.
There's also a fourth table with additional type-specific assertions, but they shouldn't be used directly.

Also note that the list of methods is different on 3.x, even though I kept the same division on all the branches.

> These should be merged into a single list.

Having a table with all the assert methods would indeed provide a better overview, but it would be quite a big table (25 assert methods on 3.4, excluding the type-specific ones) and might make navigation more difficult while scrolling through the methods.  Something could be done to make clear that there are other tables down below though (e.g. adding links or using sub-sections with an index).

----------
nosy: +ezio.melotti, michael.foord
type:  -> enhancement
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19006>
_______________________________________

From report at bugs.python.org  Wed Sep 11 18:11:46 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Sep 2013 16:11:46 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378915906.5.0.266916421254.issue19002@psf.upfronthosting.co.za>


Ethan Furman added the comment:

So when you do a `dir(int)` you don't want to know what you can call on 7?  You'd rather know what you can call on 'type'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 18:13:54 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 11 Sep 2013 16:13:54 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378915906.5.0.266916421254.issue19002@psf.upfronthosting.co.za>
Message-ID: <CAExgZOhcpkkzcVj=+et_ffAyenPp3KsB8rCpk12A40qmH3-FNQ@mail.gmail.com>


Ramchandra Apte added the comment:

On 11 September 2013 21:41, Ethan Furman <report at bugs.python.org> wrote:

>
> Ethan Furman added the comment:
>
> So when you do a `dir(int)` you don't want to know what you can call on 7?
>  You'd rather know what you can call on 'type'?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue19002>
> _______________________________________
>

Yes, as that is more consistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 19:22:10 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Sep 2013 17:22:10 +0000
Subject: [issue19002] ``dir`` function does not work correctly with classes.
In-Reply-To: <1378880451.82.0.998683899119.issue19002@psf.upfronthosting.co.za>
Message-ID: <1378920130.75.0.201457355521.issue19002@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's not how people use it at the interactive prompt, though.  I call dir(str) to find what methods I can call on an str object, not what methods I can call on the str class object. Same goes for my own classes.  Yes, I also call it on instances, but it would be very surprising, especially at this point in Python's history, for this to change.

It would also screw up pydoc and inspect.  Screwing up inspect is an issue Ethan has already brought up as a possible problem regardless, but that doesn't really enter into this discussion, because those two examples indicate how badly such a change would break existing python code outside the stdlib.

I'm going to close this issue as rejected.  The provision of a differently named builtin with the alternate semantics requested here could be raised on python-ideas, but I doubt it will get much traction since you can just do dir(xxx.__class__ for the rare cases where you want that info.

Aside: I haven't looked at what jedi is, but perhaps you need to rethink your dependence on dir, just as we (may be?) rethinking inspect's dependence on dir.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19002>
_______________________________________

From report at bugs.python.org  Wed Sep 11 19:49:03 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Sep 2013 17:49:03 +0000
Subject: [issue18995] Enum does not work with reversed
In-Reply-To: <1378804463.14.0.741296151335.issue18995@psf.upfronthosting.co.za>
Message-ID: <1378921743.17.0.723598386849.issue18995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Cool, I didn't even know __reversed__ existed!

----------
assignee:  -> ethan.furman
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18995>
_______________________________________

From report at bugs.python.org  Wed Sep 11 20:03:41 2013
From: report at bugs.python.org (purplezephyr)
Date: Wed, 11 Sep 2013 18:03:41 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1378922621.17.0.087051258962.issue11163@psf.upfronthosting.co.za>


purplezephyr added the comment:

This does not seem to have been changed in any version, per msg135246.  If it's not going to be replaced, there's another issue, which is that the link to readline() in the text is incorrect - it goes to the readline module, not file.readline().

----------
nosy: +purplezephyr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11163>
_______________________________________

From report at bugs.python.org  Wed Sep 11 20:29:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 18:29:49 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1378924189.52.0.539631703454.issue18818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nick, could you help me with documentation? I'm sure my wording needs improving.

And there is one question left. Is this change appropriate for 2.7 and 3.3, or only for 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Wed Sep 11 20:42:17 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Wed, 11 Sep 2013 18:42:17 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1378924937.36.0.446878154526.issue13107@psf.upfronthosting.co.za>


Elazar Gershuni added the comment:

ok. how about argparse_ugly.patch? below some width it simply won't do any wrapping.

(I hadn't touch optparse yet)

----------
Added file: http://bugs.python.org/file31731/argparse_ugly.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Wed Sep 11 21:28:28 2013
From: report at bugs.python.org (Roy Smith)
Date: Wed, 11 Sep 2013 19:28:28 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1378927708.68.0.536370814303.issue19006@psf.upfronthosting.co.za>


Roy Smith added the comment:

Adding a note that there are more methods in the tables below would be useful.  Otherwise, you assume you've seen them all when you've read the first table.

I agree that the assertions about exceptions and warnings belong in a different group, but I don't see any fundamental reason to put assertGreater in a different table from assertEqual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19006>
_______________________________________

From report at bugs.python.org  Wed Sep 11 21:41:06 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 11 Sep 2013 19:41:06 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1378928466.69.0.465481501704.issue19006@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

One reason is that if I list all those assert methods first and keep the assertRaises/Warns in a separate group, they will be pushed way down, and people might miss them.
I'll try to prepare a patch that adds links to the other tables and/or changes the wording to make it clear that there are more assert methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19006>
_______________________________________

From report at bugs.python.org  Wed Sep 11 21:47:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Sep 2013 19:47:47 +0000
Subject: [issue11163] iter() documentation code doesn't work
In-Reply-To: <1297284045.4.0.795458647498.issue11163@psf.upfronthosting.co.za>
Message-ID: <1378928867.4.0.695390996409.issue11163@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In the current 3.3.2 docs, 'STOP' has been replaced by '', so there is a change, and no infinite loop. However, this is still does not strike me as an example of 'useful' as 
  for line in iter(fp.readline, "STOP"): # is a bad version of
  for line in fp:
It does illustrate the behavior though.

----------
stage:  -> needs patch
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11163>
_______________________________________

From report at bugs.python.org  Wed Sep 11 21:56:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 19:56:42 +0000
Subject: [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1378929402.48.0.988790542718.issue18911@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18911>
_______________________________________

From report at bugs.python.org  Wed Sep 11 22:00:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Sep 2013 20:00:17 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
In-Reply-To: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>
Message-ID: <3cZv9C66Kkz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset c882395e8ed8 by Serhiy Storchaka in branch '3.3':
Issue #18988: The "Tab" key now works when a word is already autocompleted.
http://hg.python.org/cpython/rev/c882395e8ed8

New changeset 7d38784092d8 by Serhiy Storchaka in branch 'default':
Issue #18988: The "Tab" key now works when a word is already autocompleted.
http://hg.python.org/cpython/rev/7d38784092d8

New changeset 8d320204d5d6 by Serhiy Storchaka in branch '2.7':
Issue #18988: The "Tab" key now works when a word is already autocompleted.
http://hg.python.org/cpython/rev/8d320204d5d6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Thu Sep 12 00:00:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 22:00:25 +0000
Subject: [issue18988] Tab key doesn't work sometimes.
In-Reply-To: <1378732476.83.0.954740499881.issue18988@psf.upfronthosting.co.za>
Message-ID: <1378936825.72.0.590691310541.issue18988@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18988>
_______________________________________

From report at bugs.python.org  Thu Sep 12 00:29:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 22:29:41 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378938581.71.0.936432714568.issue18844@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The proposed patch add two methods to the Random class and two module level functions: weighted_choice() and weighted_choice_generator().

weighted_choice(data) accepts either mapping or sequence and returns a key or index x with probability which is proportional to data[x].

If you need several elements with same distribution, use weighted_choice_generator(data) which returns an iterator which produces random keys or indices of the data. It is more faster than calling weighted_choice(data) repeatedly and is more flexible than generating a list of random values at specified size (as in NumPy).

----------
Added file: http://bugs.python.org/file31732/weighted_choice_generator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Thu Sep 12 00:29:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 22:29:56 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378938596.92.0.435188819744.issue18844@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Thu Sep 12 00:34:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Sep 2013 22:34:21 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1378938861.13.0.52176686943.issue18730@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Thu Sep 12 01:06:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 23:06:19 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1378940779.37.0.366976705889.issue17797@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Shortly, is_valid_fd always returns true because fd < 0 is always
> false as my tests with Visual Studio 2012

Well, that's not all there is, is_valid_fd() does other checks before returning true.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Thu Sep 12 01:06:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Sep 2013 23:06:36 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1378940796.39.0.429979901104.issue18730@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Thu Sep 12 01:49:27 2013
From: report at bugs.python.org (Mateusz Loskot)
Date: Wed, 11 Sep 2013 23:49:27 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1378940779.37.0.366976705889.issue17797@psf.upfronthosting.co.za>
Message-ID: <CABUeae8ivnk+RW6snfQaMS6z1LU-9q3GBW9KzYHqcV-YCStVrA@mail.gmail.com>


Mateusz Loskot added the comment:

On 12 September 2013 00:06, Antoine Pitrou <report at bugs.python.org> wrote:
>> Shortly, is_valid_fd always returns true because fd < 0 is always
>> false as my tests with Visual Studio 2012
>
> Well, that's not all there is, is_valid_fd() does other checks before returning true.

Given the function:

is_valid_fd(int fd)
{
    int dummy_fd;
    if (fd < 0 || !_PyVerify_fd(fd))
        return 0;
    dummy_fd = dup(fd);
    if (dummy_fd < 0)
        return 0;
    close(dummy_fd);
    return 1;
}

for fd values of 0, 1 or 2

1. fd < 0 is always false
2. _PyVerify_fd(fd) is always true. Given the current definition:
#define _PyVerify_fd(fd) (_get_osfhandle(fd) >= 0)
for those values of fd _get_osfhandle(fd) >= 0, always.
3. for those fd values, dup() never returns fd < 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Thu Sep 12 04:25:36 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 12 Sep 2013 02:25:36 +0000
Subject: [issue18995] Enum does not work with reversed
In-Reply-To: <1378804463.14.0.741296151335.issue18995@psf.upfronthosting.co.za>
Message-ID: <1378952736.89.0.866362318866.issue18995@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Simplified unit test. I reused enum Season in the test class.

By the way, there is another way to add support for enum without implementing __reversed__ method, which is adding support indexing by number (in __getitem__ method), e.g. Season[1] => Season.SPRING. But I prefer using __reversed__ method.

----------
Added file: http://bugs.python.org/file31733/add_reversed_support_for_enum_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18995>
_______________________________________

From report at bugs.python.org  Thu Sep 12 04:32:42 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 12 Sep 2013 02:32:42 +0000
Subject: [issue18995] Enum does not work with reversed
In-Reply-To: <1378804463.14.0.741296151335.issue18995@psf.upfronthosting.co.za>
Message-ID: <1378953162.28.0.18794649089.issue18995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Yes, I was aware of that method (not that we would add it that way).  __reversed__ is definitely better for Enum.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18995>
_______________________________________

From report at bugs.python.org  Thu Sep 12 04:57:46 2013
From: report at bugs.python.org (Neil Girdhar)
Date: Thu, 12 Sep 2013 02:57:46 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1378954666.54.0.586644776617.issue18844@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Should this really be implemented using the cumulative distribution and binary search algorithm?  Vose's Alias Method has the same initialization and memory usage cost (O(n)), but is constant time to generate each sample.

An excellent tutorial is here: http://www.keithschwarz.com/darts-dice-coins/

----------
nosy: +neil.g

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Thu Sep 12 07:57:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Sep 2013 05:57:22 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>
Message-ID: <3cb8Q93TCjz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 82bdd5fc7a71 by Senthil Kumaran in branch '2.7':
Improve the docstring of random.shuffle. Inform users not to provide int arg.
http://hg.python.org/cpython/rev/82bdd5fc7a71

New changeset 4782faf29480 by Senthil Kumaran in branch '3.3':
Improve the docstring of random.shuffle. Inform users not to provide int arg.
http://hg.python.org/cpython/rev/4782faf29480

New changeset 15096b93ae5a by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/15096b93ae5a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Thu Sep 12 07:58:59 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 12 Sep 2013 05:58:59 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>
Message-ID: <1378965539.96.0.587361301306.issue14927@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

This is fixed in all versions. Thank you!

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Thu Sep 12 09:17:46 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Sep 2013 07:17:46 +0000
Subject: [issue19005] PyIter_Next crashes if passed a non-iterator
In-Reply-To: <1378894942.16.0.763585748614.issue19005@psf.upfronthosting.co.za>
Message-ID: <1378970266.72.0.00672047257595.issue19005@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19005>
_______________________________________

From report at bugs.python.org  Thu Sep 12 09:30:51 2013
From: report at bugs.python.org (Sam Lai)
Date: Thu, 12 Sep 2013 07:30:51 +0000
Subject: [issue14894] distutils.LooseVersion fails to compare number and a word
In-Reply-To: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za>
Message-ID: <1378971051.52.0.771088489892.issue14894@psf.upfronthosting.co.za>


Sam Lai added the comment:

I have a more realistic example of this bug. In the docstring for distutils.LooseVersion, it says '1.5.1' and '3.2.p10' are both valid version numbers. If instead of '3.2.p10', we use '1.5.p10', the following occurs -

>>> v1 = LooseVersion('1.5.1')
>>> v2 = LooseVersion('1.5.p10')
>>> v1>v2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python33\Lib\distutils\version.py", line 70, in __gt__
    c = self._cmp(other)
  File "C:\Python33\Lib\distutils\version.py", line 343, in _cmp
    if self.version < other.version:
TypeError: unorderable types: int() < str()
>>> v1.version
[1, 5, 1]
>>> v2.version
[1, 5, 'p', 10]

The reason it occurs is pretty clear when the .version list is printed. (That's also explains why I had to use 1.5.p10 instead because otherwise the comparison would not proceed past the first element of both lists.)

In my real-life example, I'm trying to compare '1.1.0-3' and '1.1.0-beta-10'.

>>> v3=LooseVersion(ll[0])
>>> v4=LooseVersion(ll[1])
>>> v3>v4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python33\Lib\distutils\version.py", line 70, in __gt__
    c = self._cmp(other)
  File "C:\Python33\Lib\distutils\version.py", line 343, in _cmp
    if self.version < other.version:
TypeError: unorderable types: int() < str()
>>> v3.version
[1, 1, 0, '-', 3]
>>> v4.version
[1, 1, 0, '-', 'beta', '-', 10]

----------
nosy: +samuel.lai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14894>
_______________________________________

From report at bugs.python.org  Thu Sep 12 10:00:39 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Thu, 12 Sep 2013 08:00:39 +0000
Subject: [issue18981] Typo in the ctypes tests
In-Reply-To: <1378673741.26.0.448771285371.issue18981@psf.upfronthosting.co.za>
Message-ID: <1378972839.04.0.767637330785.issue18981@psf.upfronthosting.co.za>


Changes by Anoop Thomas Mathew <atmb4u at gmail.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18981>
_______________________________________

From report at bugs.python.org  Thu Sep 12 12:14:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 10:14:58 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378980898.94.0.315614264687.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Serhiy, any benchmarks for your implementation? Does it slow down regular dicts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 12:32:38 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 12 Sep 2013 10:32:38 +0000
Subject: [issue18683] Core dumps on CentOS
In-Reply-To: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>
Message-ID: <1378981958.81.0.305257331017.issue18683@psf.upfronthosting.co.za>


Marc Schlaich added the comment:

Yes, I could reproduce segfaults on Python 2.7 (looks like it is even worse than on 2.6 where it appeared only randomly).

I was not quite accurate in my initial comment. I don't use any custom C extensions but I'm using pygtk/gobject so it might be a bug there. 

However, my library contains a coroutine scheduler similar to tulip so it is very likely that this is related to #14432.

I'll try that patch and keep you posted.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Thu Sep 12 12:33:26 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Thu, 12 Sep 2013 10:33:26 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378982006.31.0.677858086319.issue18999@psf.upfronthosting.co.za>


Changes by Lars Buitinck <larsmans at gmail.com>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Thu Sep 12 12:51:26 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Thu, 12 Sep 2013 10:51:26 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378983086.93.0.224350993638.issue18999@psf.upfronthosting.co.za>


Lars Buitinck added the comment:

I don't really see the benefit of a context manager over an argument. It's a power user feature anyway, and context managers (at least to me) signal cleanup actions, rather than construction options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Thu Sep 12 13:33:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Sep 2013 11:33:53 +0000
Subject: [issue18683] Core dumps on CentOS
In-Reply-To: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>
Message-ID: <1378985632.99.0.694298994543.issue18683@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I'll try that patch and keep you posted.

Cool, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Thu Sep 12 13:34:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Sep 2013 11:34:14 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 C	thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <1378985654.65.0.725142221093.issue14432@psf.upfronthosting.co.za>


STINNER Victor added the comment:

ping? (for myself :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Thu Sep 12 14:09:03 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 12 Sep 2013 12:09:03 +0000
Subject: [issue18683] Core dumps on CentOS
In-Reply-To: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>
Message-ID: <1378987743.33.0.492525994561.issue18683@psf.upfronthosting.co.za>


Marc Schlaich added the comment:

The generator.patch from #14432 didn't help. The other couldn't be applied to 2.7.

I have a core dump, should I upload it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Thu Sep 12 14:19:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Sep 2013 12:19:44 +0000
Subject: [issue18683] Core dumps on CentOS
In-Reply-To: <1375962081.45.0.433865344111.issue18683@psf.upfronthosting.co.za>
Message-ID: <1378988384.44.0.0619020657682.issue18683@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I have a core dump, should I upload it?

The coredump is not useful if we cannot analyze it. Please open it in gdb, type "thread all apply where" and copy/paste in a file and attach the file.

You may use "set pagination off" for easier copy/paste.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18683>
_______________________________________

From report at bugs.python.org  Thu Sep 12 14:37:02 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 12 Sep 2013 12:37:02 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378989422.44.0.888589228272.issue18999@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

By "context" I did not really mean a context manager.  I just meant an object (possibly a singleton or module) which implements the same interface as multiprocessing.

(However, it may be a good idea to also make it a context manager whose __enter__() method starts the helper processes, and whose __exit__() method shuts them down.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Thu Sep 12 14:54:11 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Thu, 12 Sep 2013 12:54:11 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378990451.99.0.922599868114.issue18999@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

The process pool executor [1] from the concurrent futures API would be suitable to explicitly start and stop the helper process for the `forkserver` mode.

[1] http://docs.python.org/3.4/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor

The point would be to have as few state as possible encoded in the multiprocessing module (and its singletons) and move that state information to be directly managed by multiprocessing Process and Pool class instances so that libraries could customize the behavior (start_method, executable, ForkingPIckler reducers registry and so on) without mutating the state of the multiprocessing module singletons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Thu Sep 12 16:08:37 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 12 Sep 2013 14:08:37 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378994917.07.0.563977426606.issue18986@psf.upfronthosting.co.za>


Ethan Furman added the comment:

On 09/11/2013 02:39 PM, Tim Delaney wrote on PyDev:
> 
> I would think that retrieving the keys from the dict would return the transformed keys (I'd 
> call them canonical keys).

The more I think about this the more I agree.  A canonicaldict with a key function that simply stored the transformed key and it's value would seem to be a lot simpler:

  - no need to store a separate "presentation" key
  - no confusion about which of the first key/last key seen is stored
  - no mistakes with the "first" key not being added before real data
    and getting the presentation key wrong

Further, in order to store the non-canonical keys a separate list must be kept of the keys to preseed the canonicaldict; if we store the canonical keys a separate list must be kept for presentation purposes -- so worst case scenario we're keeping the same amount of information and best-case scenario the presentation of the keys doesn't matter and we just saved ourselves an extra data structure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 16:16:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Sep 2013 14:16:01 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378995361.84.0.636697264666.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

It would be simpler, but it would also be useless for the actual use case for which this issue was opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 16:34:57 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 12 Sep 2013 14:34:57 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378996497.95.0.85205523285.issue18986@psf.upfronthosting.co.za>


Ethan Furman added the comment:

True, but how big a deal is that?

For one, it seems questionable to have the presentation portion of the data be part of the key.

For two, when presentation is important a separate list must be kept anyway to preseed the dict; so just use that list to cycle through the canonicaldict:

--> some_dict = some_function_that_returns_a_conanicaldict()
--> presentation_list = ['IBM','Intel','AMD']
--> for company in presentation_list:
...     key = some_dict.key[company]  # demo purposes only
...     value = some_dict[company]
...     print(key, company, value)
ibm IBM 2172
intel Intel 3210
amd AMD 4399

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 16:50:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 14:50:56 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378996497.95.0.85205523285.issue18986@psf.upfronthosting.co.za>
Message-ID: <558241591.56995461.1378997450181.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

Ethan, please don't post the same message *both* on the tracker
and on the mailing-list. I'm sure most people here also read
the ML thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 16:53:24 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 12 Sep 2013 14:53:24 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378997604.12.0.850348506471.issue18986@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Right, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 16:53:48 2013
From: report at bugs.python.org (Lukas Wunner)
Date: Thu, 12 Sep 2013 14:53:48 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1378997628.62.0.848060245336.issue1424152@psf.upfronthosting.co.za>


Lukas Wunner added the comment:

*ping*

Anybody, please consider applying the patch I've submitted August 8th so that this issue gets fixed in Python 2.7's urllib.py.

Thanks so much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Thu Sep 12 17:02:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Sep 2013 15:02:39 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1378998159.21.0.983330087002.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are conceptualizing this very differently.  In our view, this data structure is for cases where the original key is the most important piece of information (about the keys).  The transformation in the lookup process is entirely in the service of looking up the value paired with that original key when there is more than one possible representation of that key.  It is the original key that is critical when re-serializing the data or otherwise making use of the keys for anything other than lookup.  So this is about making the data structure succinctly model the problem domain, which is what OO is supposed to be good at :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 17:10:24 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 12 Sep 2013 15:10:24 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378998624.44.0.00225935087647.issue18999@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

There are lots of things that behave differently depending on the currently set start method: Lock(), Semaphore(), Queue(), Value(), ...  It is not just when creating a Process or Pool that you need to know the start method.

Passing a context or start_method argument to all of these constructors would be very awkward, which is why I think it is better to treat the context as an object with methods Process(), Pool(), Lock(), Semaphore(), etc.

Unfortunately, I do not have time to work on this just now...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Thu Sep 12 17:12:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 15:12:57 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378998159.21.0.983330087002.issue18986@psf.upfronthosting.co.za>
Message-ID: <2070353657.57060183.1378998771110.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> R. David Murray added the comment:
> 
> You are conceptualizing this very differently.  In our view, this
> data structure is for cases where the original key is the most
> important piece of information (about the keys).  The transformation
> in the lookup process is entirely in the service of looking up the
> value paired with that original key when there is more than one
> possible representation of that key.  It is the original key that is
> critical when re-serializing the data or otherwise making use of the
> keys for anything other than lookup.  So this is about making the
> data structure succinctly model the problem domain, which is what OO
> is supposed to be good at :)

Thanks for putting it much more convincingly than my python-dev
response :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Sep 12 17:16:57 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Thu, 12 Sep 2013 15:16:57 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1378999017.13.0.7902974083.issue18999@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

Richard Oudkerk: thanks for the clarification, that makes sense. I don't have the time either in the coming month, maybe later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Thu Sep 12 17:18:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 15:18:52 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on
 a	64-bit machine
In-Reply-To: <1378884408.91.0.207786386719.issue18987@psf.upfronthosting.co.za>
Message-ID: <587470009.57075374.1378999126384.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

Hello,

> To discover a 32-bit interpreter running on a 64-bit system, we could
> use
> platform.architecture(), which returns
>     >>> platform.architecture()
>     ('32bit', 'ELF')

Just use (sys.maxsize < 2**32).

> What then, though? How do you turn '32bit' to 'linux-i386'?

I don't know. How does distutils normally do? :-)

----------
title: distutils.utils.get_platform() for 32-bit Python on a 64-bit machine -> distutils.utils.get_platform() for 32-bit Python on a	64-bit machine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Thu Sep 12 18:37:48 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 12 Sep 2013 16:37:48 +0000
Subject: [issue18990] Remove unnecessary API inconsistency from
 ElementTree.XMLPullParser.close()
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379003868.67.0.740252113495.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

ping - I would like to see this fixed for alpha3, which is due in two weeks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Thu Sep 12 19:02:31 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Sep 2013 17:02:31 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1379005351.22.0.956993704389.issue15873@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Thu Sep 12 19:36:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 17:36:33 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379007393.5.0.876287655996.issue18993@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Thu Sep 12 20:35:51 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 Sep 2013 18:35:51 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1379010951.64.0.085933212259.issue17797@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

> 2. _PyVerify_fd(fd) is always true. Given the current definition:
> #define _PyVerify_fd(fd) (_get_osfhandle(fd) >= 0)
> for those values of fd _get_osfhandle(fd) >= 0, always.

Hum, are you sure this is the selected implementation?
- this code is only in 2.7
  http://hg.python.org/cpython/file/v2.7/Include/fileobject.h#l73
- it's protected by #if statements. In your case the first case should be selected, can you verify if it's the case, and if not, why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Thu Sep 12 21:44:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 19:44:34 +0000
Subject: [issue19007] precise time.time() under Windows 8
Message-ID: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

For whoever is interested: Windows 8 apparently has a new API named GetSystemTimePreciseAsFileTime which returns the system API with a much better resolution than GetSystemTimeAsFileTime does ("The GetSystemTimePreciseAsFileTime function retrieves the current system date and time with the highest possible level of precision (<1us)").
http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx

(spawned from this topic on the tulip mailing-list: https://groups.google.com/forum/#!topic/python-tulip/vX9vOZB1FOI )

----------
components: Library (Lib), Windows
messages: 197538
nosy: belopolsky, haypo, lemburg, pitrou, tim.peters
priority: low
severity: normal
status: open
title: precise time.time() under Windows 8
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19007>
_______________________________________

From report at bugs.python.org  Thu Sep 12 22:29:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Sep 2013 20:29:32 +0000
Subject: [issue19007] precise time.time() under Windows 8
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1379017772.1.0.528643400437.issue19007@psf.upfronthosting.co.za>


STINNER Victor added the comment:

time.time() is sometimes used in performance critical code. Is GetSystemTimePreciseAsFileTime() as fast as GetSystemTimeAsFileTime()?

Linux has the opposite: CLOCK_REALTIME_COARSE. This clock is less accurate but may be faster.
http://lwn.net/Articles/342018/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19007>
_______________________________________

From report at bugs.python.org  Thu Sep 12 22:32:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Sep 2013 20:32:18 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1379017938.89.0.68957368481.issue18844@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Neil. It is interesting.

Vose's alias method has followed disadvantages (in comparison with the roulette wheel selection proposed above):

1. It operates with probabilities and uses floats, therefore it can be a little less accurate.

2. It consumes two random number (an integer and a float) for generating one sample. It can be fixed however (in the cost of additional precision lost).

3. While it has same time and memory O(n) cost for initialization, it has larger multiplication, Vose's alias method requires several times larger time and memory for initialization.

4. It requires more memory in process of generating samples.

However it has an advantage. It really has constant time cost to generate each sample.

Here are some benchmark results. "Roulette Wheel" is proposed above implementation. "Roulette Wheel 2" is its modification with normalized cumulative sums. It has twice more initialization time, but 1.5-2x faster generates each sample. "Vose's Alias" is an implementation of Vose's alias method directly translated from Java. "Vose's Alias 2" is optimized implementation which uses Python specific.

Second column is a size of distribution, third column is initialization time (in milliseconds), fourth column is time to generate each sample (in microseconds), fifth column is a number of generated samples after which this method will overtake "Roulette Wheel" (including initialization time).

Roulette Wheel          10     0.059     7.165         0
Roulette Wheel 2        10     0.076     4.105         5
Vose's Alias            10     0.129    13.206         -
Vose's Alias 2          10     0.105     6.501        69
Roulette Wheel         100     0.128     8.651         0
Roulette Wheel 2       100     0.198     4.630        17
Vose's Alias           100     0.691    12.839         -
Vose's Alias 2         100     0.441     6.547       148
Roulette Wheel        1000     0.719    10.949         0
Roulette Wheel 2      1000     1.458     5.177       128
Vose's Alias          1000     6.614    13.052         -
Vose's Alias 2        1000     3.704     6.531       675
Roulette Wheel       10000     7.495    13.249         0
Roulette Wheel 2     10000    14.961     6.051      1037
Vose's Alias         10000    69.937    13.830         -
Vose's Alias 2       10000    37.017     6.746      4539
Roulette Wheel      100000    73.988    16.180         0
Roulette Wheel 2    100000   148.176     8.182      9275
Vose's Alias        100000   690.099    13.808    259716
Vose's Alias 2      100000   391.367     7.095     34932
Roulette Wheel     1000000   743.415    19.493         0
Roulette Wheel 2   1000000  1505.409     8.930     72138
Vose's Alias       1000000  7017.669    13.798   1101673
Vose's Alias 2     1000000  4044.746     7.152    267507

As you can see Vose's alias method has very large initialization time. Non-optimized version will never overtake "Roulette Wheel" with small distributions (<100000), and even optimized version will never overtake "Roulette Wheel" with small distributions (<100000). Only with very large distributions Vose's alias method has an advantage (when you needs very larger number of samples).

Because for generating only one sample we need a method with fastest initialization we need "Roulette Wheel" implementation. And because large distributions are rare, I think there is no need in alternative implementation. In worst case for generating 1000000 samples from 1000000-elements distribution the difference between "Roulette Wheel" and "Vose's Alias 2" is a difference between 20 and 11 seconds.

----------
Added file: http://bugs.python.org/file31734/wcg_bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Thu Sep 12 22:32:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Sep 2013 20:32:23 +0000
Subject: [issue19007] precise time.time() under Windows 8
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1379017943.08.0.186775912136.issue19007@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

"GetSystemTimePreciseAsFileTime() has very little overhead; the new function is even a little faster than GetSystemTimeAsFileTime(), a call takes a few ten nanoseconds."

from http://www.windowstimestamp.com/description#C_2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19007>
_______________________________________

From report at bugs.python.org  Thu Sep 12 23:28:36 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 12 Sep 2013 21:28:36 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379021316.21.0.84078384932.issue18993@psf.upfronthosting.co.za>


Michael Foord added the comment:

Although I'm not certain the first test is "invalid". It's testing a different case than the second test. So if the first test passes it should be renamed rather than removed. If it *fails* then I'd like to look at the behaviour and specify (test) that.

----------
assignee:  -> michael.foord
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Thu Sep 12 23:26:33 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 12 Sep 2013 21:26:33 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379021193.19.0.858497043653.issue18993@psf.upfronthosting.co.za>


Michael Foord added the comment:

Good catch - thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Thu Sep 12 23:56:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Sep 2013 21:56:41 +0000
Subject: [issue13107] Text width in optparse.py can become negative
In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za>
Message-ID: <1379023001.07.0.99610747347.issue13107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is less ugly patch (for argparse and optparse). Instead of prohibiting wrapping at all for small width, it limits minimal width of formatted text. It try first decrease the indent for help.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file31735/argparse_less_ugly.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13107>
_______________________________________

From report at bugs.python.org  Fri Sep 13 00:08:48 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Thu, 12 Sep 2013 22:08:48 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1379023728.76.0.881774593329.issue8713@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8713>
_______________________________________

From report at bugs.python.org  Fri Sep 13 03:41:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Sep 2013 01:41:24 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379036484.34.0.61752758092.issue18993@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

The first test fails. I already tested it.

I think they test the same thing, what happens to the attribute of mock instance if you delete it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Fri Sep 13 06:16:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 04:16:39 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1379045799.37.0.0667504589909.issue17087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about such output?

    >>> re.search('p((a)|(b))(c)?', 'unpack')
    <SRE Match object: [2: 5]: 'p'(('a')())('c')>

Or may be ('p', [['a'], []], ['c']) if you prefer legal Python expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Fri Sep 13 06:27:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 04:27:34 +0000
Subject: [issue18744] pathological performance using tarfile
In-Reply-To: <1376544025.63.0.959353089302.issue18744@psf.upfronthosting.co.za>
Message-ID: <1379046454.13.0.469845991455.issue18744@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18744>
_______________________________________

From report at bugs.python.org  Fri Sep 13 06:29:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 04:29:40 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1379046580.72.0.344406635002.issue18682@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Antoine, what you say?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Fri Sep 13 06:52:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 04:52:04 +0000
Subject: [issue18784] minor uuid.py loading optimization
In-Reply-To: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za>
Message-ID: <1379047924.31.0.5715136857.issue18784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
stage:  -> commit review
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18784>
_______________________________________

From report at bugs.python.org  Fri Sep 13 07:09:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 05:09:16 +0000
Subject: [issue18784] minor uuid.py loading optimization
In-Reply-To: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za>
Message-ID: <3cblJB48q2z7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset 7aaba721ebc0 by Serhiy Storchaka in branch '3.3':
Issue #18784: The uuid module no more attempts to load libc via ctypes.CDLL,
http://hg.python.org/cpython/rev/7aaba721ebc0

New changeset 66ec8431032d by Serhiy Storchaka in branch 'default':
Issue #18784: The uuid module no more attempts to load libc via ctypes.CDLL,
http://hg.python.org/cpython/rev/66ec8431032d

New changeset 6d8a5cbb94c9 by Serhiy Storchaka in branch '2.7':
Issue #18784: The uuid module no more attempts to load libc via ctypes.CDLL,
http://hg.python.org/cpython/rev/6d8a5cbb94c9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18784>
_______________________________________

From report at bugs.python.org  Fri Sep 13 07:17:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 05:17:25 +0000
Subject: [issue18784] minor uuid.py loading optimization
In-Reply-To: <1376934568.82.0.658591354908.issue18784@psf.upfronthosting.co.za>
Message-ID: <1379049445.17.0.182757565084.issue18784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Evgeny.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18784>
_______________________________________

From report at bugs.python.org  Fri Sep 13 07:24:31 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 13 Sep 2013 05:24:31 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1379049871.72.0.585874685287.issue14678@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Brett wrote a pure python zipimporter in http://bugs.python.org/issue17630 :)

FWIW, the zipimport.c implementation (in 2.7) causes us serious pain when we've got the stdlib in a .zip file and need to update that while there are running python processes (which have cached the central directory of that .zip file but do not also keep a fd to the zip file open or even attempt to stat the file to see if it has changed [racy but it'd still be better than the nothing that is done now]).

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Fri Sep 13 08:18:29 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 06:18:29 +0000
Subject: [issue18902] Make ElementTree event handling more modular to allow
 custom targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1379053109.37.0.206689343584.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

The way the XMLPullParser is implemented in lxml.etree now is that it simply inherits from XMLParser. This would also make sense for ElementTree, even before supporting arbitrary targets. The patch in ticket #18990 makes this simple to do.

For reference, here is the implementation in lxml.

Iterparse:

https://github.com/lxml/lxml/blob/master/src/lxml/iterparse.pxi

XMLPullParser:

https://github.com/lxml/lxml/blob/d9f7cd8d12a27cafc4d65c6e280ea36156e3b837/src/lxml/parser.pxi#L1357

SAX based parser that collects events and/or maps parser callbacks to callbacks on the target object:

https://github.com/lxml/lxml/blob/master/src/lxml/saxparser.pxi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18902>
_______________________________________

From report at bugs.python.org  Fri Sep 13 08:23:50 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 06:23:50 +0000
Subject: [issue17741] event-driven XML parser
In-Reply-To: <1366058982.04.0.43047381217.issue17741@psf.upfronthosting.co.za>
Message-ID: <1379053430.0.0.289945674891.issue17741@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

The way the XMLPullParser is implemented in lxml.etree now is that it simply inherits from XMLParser. This would also make sense for ElementTree, even before supporting arbitrary targets. The patch in ticket #18990 makes this simple to do.

For reference, here is the implementation in lxml.

Iterparse:

https://github.com/lxml/lxml/blob/master/src/lxml/iterparse.pxi

XMLPullParser:

https://github.com/lxml/lxml/blob/d9f7cd8d12a27cafc4d65c6e280ea36156e3b837/src/lxml/parser.pxi#L1357

SAX based parser that collects events and/or maps parser callbacks to callbacks on the target object:

https://github.com/lxml/lxml/blob/master/src/lxml/saxparser.pxi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17741>
_______________________________________

From report at bugs.python.org  Fri Sep 13 08:32:32 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 13 Sep 2013 06:32:32 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1379053952.56.0.575700114858.issue1424152@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I have a slight fear that this patch could be considered as a feature addition in 2.7 urllib.py, I would like to quell that and ensure that behaviour expectation is consistent when using urllib or urllib2 and latest urllib/request.py modules.

Also, tests + docs can help a lot in speedier reviews.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424152>
_______________________________________

From report at bugs.python.org  Fri Sep 13 09:22:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 07:22:53 +0000
Subject: [issue17324] SimpleHTTPServer serves files even if the URL has a
 trailing slash
In-Reply-To: <1362128046.23.0.253565985522.issue17324@psf.upfronthosting.co.za>
Message-ID: <3cbpGN25nyzRdD@mail.python.org>


Roundup Robot added the comment:

New changeset a58b620e4dc9 by Senthil Kumaran in branch '2.7':
Fix SimpleHTTPServer's request handling case on trailing '/'.
http://hg.python.org/cpython/rev/a58b620e4dc9

New changeset 1fcccbbe15e2 by Senthil Kumaran in branch '3.3':
Fix http.server's request handling case on trailing '/'.
http://hg.python.org/cpython/rev/1fcccbbe15e2

New changeset b85c9d2a5227 by Senthil Kumaran in branch 'default':
Fix http.server's request handling case on trailing '/'.
http://hg.python.org/cpython/rev/b85c9d2a5227

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17324>
_______________________________________

From report at bugs.python.org  Fri Sep 13 09:24:26 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 13 Sep 2013 07:24:26 +0000
Subject: [issue17324] SimpleHTTPServer serves files even if the URL has a
 trailing slash
In-Reply-To: <1362128046.23.0.253565985522.issue17324@psf.upfronthosting.co.za>
Message-ID: <1379057066.64.0.899396321926.issue17324@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patches, Vajrasky and Karl. Fixed in currently active (3.4,3.3 and 2.7) versions of python.

----------
assignee:  -> orsenthil
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17324>
_______________________________________

From report at bugs.python.org  Fri Sep 13 09:47:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 07:47:47 +0000
Subject: [issue18725] Multiline shortening
In-Reply-To: <1376388778.3.0.982069932509.issue18725@psf.upfronthosting.co.za>
Message-ID: <1379058467.41.0.793726675027.issue18725@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. It get rid of TextWrap.shorten() because TextWrap.fill() supersedes it and because "placeholder" now a parameter of TextWrap. Module level shorten() is left but I doubt about it.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file31736/textwrap_max_lines.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18725>
_______________________________________

From report at bugs.python.org  Fri Sep 13 10:22:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 08:22:15 +0000
Subject: [issue18468] re.group() should never return a bytearray
In-Reply-To: <1373931432.85.0.594082146564.issue18468@psf.upfronthosting.co.za>
Message-ID: <1379060535.02.0.896490715594.issue18468@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, seems I again did not attach a patch. Now I understand why there were no any feedback so long time.

----------
keywords: +needs review, patch
Added file: http://bugs.python.org/file31737/re_group_type.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18468>
_______________________________________

From report at bugs.python.org  Fri Sep 13 10:35:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 08:35:57 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1379061357.09.0.356767623592.issue18682@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Are there tests for all the "builtin scalars"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Fri Sep 13 10:46:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 08:46:52 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <3cbr7H2jG3zSpd@mail.python.org>


Roundup Robot added the comment:

New changeset c7fdb0637d0b by Serhiy Storchaka in branch 'default':
Issue #18818: The "encodingname" part of PYTHONIOENCODING is now optional.
http://hg.python.org/cpython/rev/c7fdb0637d0b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Sep 13 10:48:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 08:48:41 +0000
Subject: [issue18818] Empty PYTHONIOENCODING is not the same as nonexistent
In-Reply-To: <1377240348.58.0.0824436318174.issue18818@psf.upfronthosting.co.za>
Message-ID: <1379062121.79.0.0756922387461.issue18818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ezio and Vajrasky for the review.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18818>
_______________________________________

From report at bugs.python.org  Fri Sep 13 10:53:03 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Fri, 13 Sep 2013 08:53:03 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1379062383.04.0.329809344212.issue18999@psf.upfronthosting.co.za>


Lars Buitinck added the comment:

Ok. Do you (or jnoller?) have time to review my proposed patch, at least before 3.4 is released? I didn't see it in the release schedule, so it's probably not planned soon, but I wouldn't want the API to change *again* in 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Fri Sep 13 11:25:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 09:25:51 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1379064351.4.0.487377191097.issue9951@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:04:45 2013
From: report at bugs.python.org (Laurence McGlashan)
Date: Fri, 13 Sep 2013 12:04:45 +0000
Subject: [issue19008] tkinter: UnboundLocalError: local variable 'sys'
 referenced before assignment
Message-ID: <1379073885.83.0.804640187446.issue19008@psf.upfronthosting.co.za>


New submission from Laurence McGlashan:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/sk1/__init__.py", line 21, in <module>
    app.main.main()
  File "/usr/lib64/python2.7/site-packages/sk1/app/main.py", line 150, in main
    application = SketchApplication(filename, options.display, options.geometry, run_script = options.run_script)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 155, in __init__
    TkApplication.__init__(self, screen_name = screen_name, geometry = geometry)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 60, in __init__
    self.init_tk(screen_name, geometry)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 185, in init_tk
    TkApplication.init_tk(self, screen_name = screen_name, geometry = geometry)
  File "/usr/lib64/python2.7/site-packages/sk1/app/skapp.py", line 63, in init_tk
    self.root = Tk(screenName = screen_name, baseName = self.tk_basename, className = self.tk_class_name)
  File "/usr/lib64/python2.7/lib-tk/Tkinter.py", line 1748, in __init__
    if not sys.flags.ignore_environment:
UnboundLocalError: local variable 'sys' referenced before assignment


Patch attached.

----------
components: Tkinter
files: Tkinter.patch
keywords: patch
messages: 197563
nosy: Laurence.McGlashan
priority: normal
severity: normal
status: open
title: tkinter: UnboundLocalError: local variable 'sys' referenced before assignment
versions: Python 2.7
Added file: http://bugs.python.org/file31738/Tkinter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19008>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:20:25 2013
From: report at bugs.python.org (Michael Foord)
Date: Fri, 13 Sep 2013 12:20:25 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379074825.89.0.111420094679.issue18993@psf.upfronthosting.co.za>


Michael Foord added the comment:

Well, they actually test slightly different scenarios - they're *not* just duplicates of each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:21:43 2013
From: report at bugs.python.org (Laurence McGlashan)
Date: Fri, 13 Sep 2013 12:21:43 +0000
Subject: [issue19008] tkinter: UnboundLocalError: local variable 'sys'
 referenced before assignment
In-Reply-To: <1379073885.83.0.804640187446.issue19008@psf.upfronthosting.co.za>
Message-ID: <1379074903.95.0.941309683163.issue19008@psf.upfronthosting.co.za>


Changes by Laurence McGlashan <laurence.mcglashan at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19008>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:30:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 12:30:20 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <3cbx574538z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 63f25483c8f6 by Eli Bendersky in branch '3.3':
Issue #18945: Add tests for tempfile name collision handling.
http://hg.python.org/cpython/rev/63f25483c8f6

New changeset c902ceaf7825 by Eli Bendersky in branch 'default':
Issue #18945: Add tests for tempfile name collision handling.
http://hg.python.org/cpython/rev/c902ceaf7825

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:30:46 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 13 Sep 2013 12:30:46 +0000
Subject: [issue19008] tkinter: UnboundLocalError: local variable 'sys'
 referenced before assignment
In-Reply-To: <1379073885.83.0.804640187446.issue19008@psf.upfronthosting.co.za>
Message-ID: <1379075446.7.0.573199677234.issue19008@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Security bug in tkinter allows for untrusted, arbitrary code execution.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19008>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:32:12 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 12:32:12 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1379075532.44.0.591932283328.issue18945@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks Vlad, committed to 3.3/3.4; would you like to provide the 2.7 patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:33:24 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 12:33:24 +0000
Subject: [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1379075604.11.0.38434015457.issue18911@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18911>
_______________________________________

From report at bugs.python.org  Fri Sep 13 14:35:36 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 12:35:36 +0000
Subject: [issue18998] iter() not working in ElementTree
In-Reply-To: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>
Message-ID: <1379075736.41.0.41712612003.issue18998@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I can't reproduce it with the most recent default branch (Python 3.4.0a2+ (default:c7fdb0637d0b, Sep 13 2013, 05:29:00)) either.

Unless I'm missing something, there's no issue here. Let me know if something else can be done. Otherwise I'll close the issue in a couple of days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18998>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:14:54 2013
From: report at bugs.python.org (Vlad Shcherbina)
Date: Fri, 13 Sep 2013 13:14:54 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1379078094.8.0.378340798443.issue18945@psf.upfronthosting.co.za>


Changes by Vlad Shcherbina <vlad.shcherbina at gmail.com>:


Added file: http://bugs.python.org/file31739/tempfile_collision_tests_27

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:28:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 13:28:12 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <3cbyMv6G17z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 39823ebfc731 by Eli Bendersky in branch '3.3':
Issue #18997: fix ElementTree crash with using pickle and __getstate__.
http://hg.python.org/cpython/rev/39823ebfc731

New changeset bda5a87df1c8 by Eli Bendersky in branch 'default':
Merge for Issue #18997: Issue #18997: fix ElementTree crash with using pickle and __getstate__.
http://hg.python.org/cpython/rev/bda5a87df1c8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:28:25 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 13:28:25 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1379078905.95.0.190783422288.issue18945@psf.upfronthosting.co.za>


R. David Murray added the comment:

We don't generally backport tests unless they are part of a bug fix.  It's not a blanket prohibition, but normally the risk of false positives in a maintenance release on platforms not covered by our buildbots outweighs the benefits of adding the tests.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:28:41 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 13:28:41 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <1379078921.63.0.795220257252.issue18997@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Fixed the patch and committed. Thanks.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:29:52 2013
From: report at bugs.python.org (Arnon Yaari)
Date: Fri, 13 Sep 2013 13:29:52 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1379078992.8.0.974399880253.issue9951@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

You can follow the discussion I linked in the ticket description for an answer:
http://psf.upfronthosting.co.za/roundup/tracker/issue3532
Mainly the answer is: to conform to PEP 358 and to provide the opposite of bytes.fromhex.
I agree that you can use binascii, but apparently it was decided that this functionality is good to have in the builtins (what used to be encode/decode('hex') in Python 2.x, and what is now bytes.fromhex, with the missing bytes.hex). In addition, binascii works a little differently - already discussed in the given link...

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:30:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 13:30:41 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379079041.32.0.645835244629.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch updated. Added tests. The locale_alias mapping updated to be self-consistency (i.e. for every name in locale_alias.values() normalize(name) == name).

----------
assignee: docs at python -> serhiy.storchaka
keywords:  -easy
nosy: +lemburg
stage: needs patch -> patch review
versions:  -Python 3.2
Added file: http://bugs.python.org/file31740/locale_parse_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:36:45 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 13:36:45 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1379078905.95.0.190783422288.issue18945@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8ctK91tSX9xDw0HejfWS9v2bp4kLuONMSEVTn6SP4dZA@mail.gmail.com>


Eli Bendersky added the comment:

On Fri, Sep 13, 2013 at 6:28 AM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray added the comment:
>
> We don't generally backport tests unless they are part of a bug fix.  It's
> not a blanket prohibition, but normally the risk of false positives in a
> maintenance release on platforms not covered by our buildbots outweighs the
> benefits of adding the tests.
>

These tests are very related to an actual bug-fix (
http://bugs.python.org/issue18849). Moreover, they cover a previously
uncovered feature which resulted in very intermittent heisen-bugs where
temp file creation was occasionally failing on some platforms. IMHO having
this covered is worth the small maintenance burden of the tests - who
knows, it may uncover real problems. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:38:53 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 13:38:53 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1379079533.33.0.691939204647.issue18844@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:39:30 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Sep 2013 13:39:30 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
Message-ID: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson:

Some applications require reading http response data in "long" polls as it becomes available.  This is used, e.g. to receive "notifications" over a HTTP stream.
Using response.read(large_buffer) is not possible because this will attempt to fullfill the entire request (using multiple underlying recv() calls), negating the attempt to get data as it becomes available.
Using "readline", and using \n boundaries in the data, this problem can be overcome.
Currently, readline is slow because it will attempt to read one byte at a time.  Even if it is doing so from a buffered stream, it is still doing it one character at a time.
This patch adds a "peek" method to HttpResponse, which works both for chunked and non-chunked transfer encoding, thus improving the performance of readline.  IOBase.readline will use peek() to determine the readahead it can use, instead of one byte which it must use by default.

----------
components: Library (Lib)
files: peek.patch
keywords: patch
messages: 197574
nosy: kristjan.jonsson
priority: normal
severity: normal
status: open
title: Enhance HTTPResponse.readline() performance
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file31741/peek.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:41:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 13:41:28 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379079688.64.0.147017910337.issue5815@psf.upfronthosting.co.za>


R. David Murray added the comment:

It would be great if this could get a review by MAL, since it looks like a non-trivial change.

Also, you have some (commented out) debug prints in there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:42:30 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 13:42:30 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379079750.5.0.211831831051.issue18989@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I agree with David. This is yet another case where we try to go against Python and make enum special, and I'm against this. Nothing prevents users from accidentally overriding their own members and methods in normal classes as well. This is trivially discoverable with tests. Let's please stop making enum more and more complex with all these needless type checks. We'll never get out of it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Fri Sep 13 15:45:43 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 Sep 2013 13:45:43 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1379079041.32.0.645835244629.issue5815@psf.upfronthosting.co.za>
Message-ID: <52331701.7050302@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.09.2013 15:30, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Patch updated. Added tests. The locale_alias mapping updated to be self-consistency (i.e. for every name in locale_alias.values() normalize(name) == name).

Could you elaborate on the alias changes ?

Were those coming from an updated X11 local.alias file ?

If so, I'd suggest to create two patches: one with the alias
updates (which can then also be backported) and one with the
new normalization code (which is a new feature and probably
cannot be backported).

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:15:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 14:15:10 +0000
Subject: [issue17394] Add slicing support to collections.deque
In-Reply-To: <1362972021.66.0.443403979058.issue17394@psf.upfronthosting.co.za>
Message-ID: <1379081710.74.0.676931111376.issue17394@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What type should be a result of slicing? List, tuple, deque, other?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17394>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:15:36 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Sep 2013 14:15:36 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1379081736.67.0.187088475175.issue17087@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Serhiy, at the first glance, that repr doesn't make sense to me, thus it seems a little difficult to comprehend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:17:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 14:17:08 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379081828.78.0.52521720301.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Also, you have some (commented out) debug prints in there.

These debug prints were in old code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:19:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 14:19:44 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379081984.07.0.382275214252.issue5815@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  I only scanned the patch quickly, obviously.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:31:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 14:31:51 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1379082711.29.0.592050404859.issue18945@psf.upfronthosting.co.za>


R. David Murray added the comment:

If they are part of a bug fix, then sure.  That wasn't clear from this issue, though.  On the other hand, if the tests in that other issue cover the actual bug, and these have any chance of *introducing* test failures (especially if they are heisenburgs, although I'm assuming the point is that they are not), then I'd say no.  The issue with backporting tests isn't about "maintenance burden" (backporting tests actually makes the maintenance burden smaller, not larger).  The issue is potential effectively spurious test failures in the field in a maintenance release.

To put it another way: the right place to find test bugs is in a feature release, which we then fix in the next maintenance release.  We do *not* want to find test bugs in maintenance releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:34:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 14:34:36 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379082876.95.0.661262699212.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Could you elaborate on the alias changes ?
> Were those coming from an updated X11 local.alias file ?

No, they are not from X11 local.alias file. They are a result of the test_locale_alias self-test, I have fixed all failures.

This test can't be backported without rest of changes, because they fix other error, for example processing encodings with hyphen. Without them test_locale_alias will fail even with updated locale_alias. I.e. we can backport either changes to locale_alias without tests, or changes to locale_alias with all changes to parser and tests, or changes to parser and all tests except test_locale_alias.

Current code doesn't work with locales with modifiers and locales with hyphenated encodings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 16:57:16 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Fri, 13 Sep 2013 14:57:16 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on
 a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379084236.22.0.693382878121.issue18987@psf.upfronthosting.co.za>


Sam Ferencik added the comment:

Are you asking *what* distutils does?

It tackles the problem completely differently on Windows, Unix, and OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:04:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 15:04:16 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379084656.53.0.596638449089.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch without changes to locale_alias.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:05:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 15:05:33 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1379084733.6.0.842653425918.issue5815@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31742/locale_parse_2a.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:14:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 15:14:13 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1379084236.22.0.693382878121.issue18987@psf.upfronthosting.co.za>
Message-ID: <218162047.60064020.1379085247541.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Are you asking *what* distutils does?

Yup :-) I'm not a distutils maintainer, so I hardly know how it does
things internally.

> It tackles the problem completely differently on Windows, Unix, and
> OS X.

Ah... but does it compute the result by itself or simply queries some
kind of external information?
If the former, then it should be simple to give it the right bitness
value (32 vs. 64). If the latter, things will get a bit more...
interesting :-)

----------
title: distutils.utils.get_platform() for 32-bit Python on a	64-bit machine -> distutils.utils.get_platform() for 32-bit Python on	a	64-bit machine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:16:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 15:16:58 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379085418.6.0.934419881322.issue19009@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This sounds ok on the principle. I suppose one can't simply wrap the "fp" inside a BufferedReader?
I think it would be good to add tests for the peek() implementation, though.

----------
nosy: +orsenthil, pitrou, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.4 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:18:42 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 Sep 2013 15:18:42 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1379082876.95.0.661262699212.issue5815@psf.upfronthosting.co.za>
Message-ID: <52332CCB.4040501@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.09.2013 16:34, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> Could you elaborate on the alias changes ?
>> Were those coming from an updated X11 local.alias file ?
> 
> No, they are not from X11 local.alias file. They are a result of the test_locale_alias self-test, I have fixed all failures.
> 
> This test can't be backported without rest of changes, because they fix other error, for example processing encodings with hyphen. Without them test_locale_alias will fail even with updated locale_alias. I.e. we can backport either changes to locale_alias without tests, or changes to locale_alias with all changes to parser and tests, or changes to parser and all tests except test_locale_alias.
> 
> Current code doesn't work with locales with modifiers and locales with hyphenated encodings.

Then I don't understand changes such as:

-    'chinese-s':                            'zh_CN.eucCN',
+    'chinese-s':                            'zh_CN.gb2312',

or

-    'sp':                                   'sr_CS.ISO8859-5',
-    'sp_yu':                                'sr_CS.ISO8859-5',
+    'sp':                                   'sr_RS.ISO8859-5',
+    'sp_yu':                                'sr_RS.ISO8859-5',

The .test_locale_alias() checks that the normalize()
function returns the the alias given in the alias table.

If you have to make changes to the alias table that cause the
encoding to or locale to change, something is wrong with
normalize() function.

Note that we are using the X11 locale.alias file as basis for
the mapping, so any such changes need to be found there as
well.

The Tools/i18n/makelocalealias.py script can be used to create
an updated listing.

Please remember that the output of the alias table
is a C runtime locale string. Those do not necessarily
use the same encodings as we do in Python.

Perhaps we should open a separate ticket for the update of the
alias table. I just ran the script on my older dev system
and it returned this list of changes compared to what's in
Python 2.7:

#    added 'ar_in'
#    added 'as_in'
#    added 'be_bg'
#    added 'bo_in'
#    added 'en_dk'
#    added 'hne_in'
#    added 'ks_in'
#    added 'mai_in'
#    added 'ml_in'
#    added 'ne_np'
#    added 'or_in'
#    added 'pa_pk'
#    added 'sd_in'
#    added 'sd_in at devanagari'
#    added 'te_in'
#    updated 'univ' -> 'en_US.utf' to 'en_US.UTF-8'
#    added 'ur_in'
#    added 'zh_sg'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:20:00 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Fri, 13 Sep 2013 15:20:00 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379085600.63.0.108773269929.issue18987@psf.upfronthosting.co.za>


Sam Ferencik added the comment:

It's very hacky on all of Windows, Unix, and OS X. That's why I don't feel confident to propose a solution.

On Unix, specifically, the return value is heavily based on os.uname(). It seems that the maintainers of OS X have started with the same but then chose to diverge and instead use a list of values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:24:14 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 15:24:14 +0000
Subject: [issue18902] Make ElementTree event handling more modular to allow
 custom targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1379085854.31.0.744989856671.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Also, +1 for allowing start-ns and end-ns event callbacks on parser targets, although that's a different feature entirely.

Actually, I take that back. I can't see a use case for this feature, and it doesn't really fit with the notion of fully qualified tag names in ElementTree (which itself is a great feature). I'm -0.7 on adding this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18902>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:31:12 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 13 Sep 2013 15:31:12 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379086272.5.0.0699030483171.issue18989@psf.upfronthosting.co.za>


Ethan Furman added the comment:

In any other (normal) class, this works:
==================================================================================
-->class Okay:
...   red = 1
...   green = 2
...   blue = 3
...   red = 4
==================================================================================

But not in Enum.

And this works:
==================================================================================
-->class Color:
...   red = 1
...   green = 2
...   blue = 3
...   def red(self):
...     return 42
... 
--> Color.red
<property object at 0x7fee4db306d8>
==================================================================================

This only works in Enum because we added code to deal with it.  If we hadn't, we'd see this:
==================================================================================
<Color.red: <property object at 0x7fee4db30f58>>
==================================================================================

So right now the rule is:  you can overwrite an enum member with anything besides another enum member.  Considering the point of the Enum class is to create enum members this rule is nonsensical as it allows the removal of already created members.

At the very least the rule should be: enum members cannot be overwritten.

I prefer to have the rule: enum members cannot overwrite anything else, and cannot be overwritten by anything else.  This seems to me to be a simpler, more consistent rule, and more in keeping with what an enumeration should be doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:33:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 Sep 2013 15:33:01 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379086381.15.0.645472313678.issue18987@psf.upfronthosting.co.za>


?ric Araujo added the comment:

FTR the Mac OS code does some normalization: http://hg.python.org/cpython/file/bda5a87df1c8/Lib/_osx_support.py#l473

Code for linux just returns the value from uname, as Same said: http://hg.python.org/cpython/file/bda5a87df1c8/Lib/distutils/util.py#l75

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:33:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 15:33:06 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379086386.49.0.241025983065.issue18989@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

What if I redefine an existing key inside a subclass?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:34:14 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 13 Sep 2013 15:34:14 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379086454.89.0.237386004658.issue18989@psf.upfronthosting.co.za>


Ethan Furman added the comment:

One cannot subclass an Enum that has already defined keys.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:35:14 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Sep 2013 15:35:14 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379086514.46.0.489448409415.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

The problem is that self.fp is already a Buffered stream, and such streams are documented to have their read() and readinto() calls make multiple system calls to fullfill the request.

My original goal was actually to make response.read(amt) not try to make multiple read() calls, so that one could have other delimiters than newline.  It is simple for the chunked case, but I don't know how to bypass it for response.fp, since it is already a buffered file that has no guaranteed such behaviour.... wait, one can simply call peek() on it and know how much one can get :)

But anyway, the use case I have actually uses newlines as record separators in the http stream, so this enhancement seems less intrusive.

I'll add unit tests.  There ought to be ready-made HTTPResponse tests already that I can use as templates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:36:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 15:36:21 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379086581.96.0.334104238619.issue18987@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> On Unix, specifically, the return value is heavily based on os.uname().

Ouch. Then I'm afraid this is a probably a won't fix :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:37:07 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 13 Sep 2013 15:37:07 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379086627.5.0.418224331782.issue18989@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Perhaps you meant, what if you define a key in a subclass that shadows a method/property in a parent class?

I'm inclined to say that would be acceptable, since one reason for subclassing is to add or make changes to the parent class' behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:37:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 15:37:51 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379086514.46.0.489448409415.issue19009@psf.upfronthosting.co.za>
Message-ID: <1509816209.60125059.1379086665442.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> My original goal was actually to make response.read(amt) not try to
> make multiple read() calls, so that one could have other delimiters
> than newline.  It is simple for the chunked case, but I don't know
> how to bypass it for response.fp, since it is already a buffered
> file that has no guaranteed such behaviour.... wait, one can simply
> call peek() on it and know how much one can get :)

Or you can use read1()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:44:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 15:44:37 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <52332CCB.4040501@egenix.com>
Message-ID: <CAAuNNr4hFXTiOjPhXtp1UJqR-=pttok8gegoYXn8pA25uzA=sg@mail.gmail.com>


Serhiy Storchaka added the comment:

> Then I don't understand changes such as:
>
> -    'chinese-s':                            'zh_CN.eucCN',
> +    'chinese-s':                            'zh_CN.gb2312',
>
> or
>
> -    'sp':                                   'sr_CS.ISO8859-5',
> -    'sp_yu':                                'sr_CS.ISO8859-5',
> +    'sp':                                   'sr_RS.ISO8859-5',
> +    'sp_yu':                                'sr_RS.ISO8859-5',
>
> The .test_locale_alias() checks that the normalize()
> function returns the the alias given in the alias table.
>

It also test normalize(locale_alias[localname]) == locale_alias[localname]
== normalize(localname). I.e. that applying normalize() twice doesn't
change a result.

chinese-s is mapped to zh_CN.eucCN, but eucCN is mapped to gb2312. sp is
mapped to sr_CS.ISO8859-5, but sr_CS is mapped to sr_RS.UTF-8 and then
.ISO8859-5 replaces UTF-8. Of course we can recursive call normalize(), but
it will be more practical just update the mapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:45:32 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Fri, 13 Sep 2013 15:45:32 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379087132.52.0.054195259349.issue18987@psf.upfronthosting.co.za>


Sam Ferencik added the comment:

Well, the maintainers of Mac OS didn't consider it a won't fix - and have this working properly. I don't see why we couldn't try to copy what they did.

Actually, I think the impact of changing this for 32-bit Python on 64-bit Linux should be quite small, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:48:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 15:48:20 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379087300.68.0.934914178939.issue19009@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue 13541?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:50:42 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Fri, 13 Sep 2013 15:50:42 +0000
Subject: [issue18948] deliberately crashing tests should prevent core dumps
In-Reply-To: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>
Message-ID: <1379087442.49.0.275868889613.issue18948@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

Great! Thanks for putting together a list. I've incorporated SuppressCoreFiles into these tests and have used the test suite without any errors. Again, I'm testing these on Ubuntu.

----------
keywords: +patch
Added file: http://bugs.python.org/file31743/issue-18948.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18948>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:50:47 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Sep 2013 15:50:47 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379087447.03.0.347444279528.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Intersting. I didn't know about that.  My excuse is that I never use 3.x except when I'm porting some CCP enhancements for cpython.

Here's a thought:  HTTPResponse inherits from RawIOBase.  Only the BufferedIO classes have read1() and are documented to have more than one system calls on their read() methods.  Yet, HTTPResponse will happily behave in that way.
So, either HTTPResponse, being a non-buffered IO object, should not work in that way, or we could add a read1() method to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 17:53:37 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 13 Sep 2013 15:53:37 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379087617.12.0.379253471175.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

I should add, I fully support the use case that response.read(amt=None) needs to read to the end of the response.  It is only the read(amt=bufsize) use case I'm thinking of, and that could be handled with a read1() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:03:32 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 16:03:32 +0000
Subject: [issue19010] Make XMLPullParser in ElementTree inherit from XMLParser
Message-ID: <1379088212.34.0.0740514839917.issue19010@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

As mentioned in tickets #18902 and #17741, the XMLPullParser in the external lxml.etree package inherits from the existing XMLParser class. This makes the interface simpler, both simpler to explain and to implement.

The implementation in ElementTree should do the same.

----------
components: Library (Lib), XML
messages: 197605
nosy: eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: Make XMLPullParser in ElementTree inherit from XMLParser
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19010>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:04:35 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 16:04:35 +0000
Subject: [issue18902] Make ElementTree event handling more modular to allow
 custom targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1379088275.96.0.520355477924.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I created a separate ticket #19010 for the inheritance issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18902>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:05:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 16:05:00 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1379087132.52.0.054195259349.issue18987@psf.upfronthosting.co.za>
Message-ID: <777755492.60193361.1379088294561.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Well, the maintainers of Mac OS didn't consider it a won't fix - and
> have this working properly. I don't see why we couldn't try to copy
> what they did.

Ah, ok. Then a patch would be welcome :-)

> Actually, I think the impact of changing this for 32-bit Python on
> 64-bit Linux should be quite small, no?

Well, if you can get the semantics reliably right, yes, probably.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:12:32 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 16:12:32 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1379088752.22.0.050575042524.issue18945@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Benjamin, what do you think?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:23:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 16:23:14 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1379089394.8.0.0610469476221.issue17087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Well, then first will commit a simpler patch. I left comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:53:36 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Sep 2013 16:53:36 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1379091216.86.0.26089863957.issue17087@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's the new version. I added a few replies on the Rietveld.

----------
Added file: http://bugs.python.org/file31744/sre_repr2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Fri Sep 13 18:55:43 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 13 Sep 2013 16:55:43 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
Message-ID: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>


New submission from Chris Lambacher:

The use case for this is that when you are in a template and you want to use the Enum instances in a conditional, then you need to pass the Enum class to the template or start using someenumvariable.__class__.someenumvalue. Instead it would be useful to be able to do someenumvariable.someenumvalue. Implimenting as __getattr__ on enum class allows real attributes to take precedence and also allows for overriding of behaviour in child classes.

----------
components: Library (Lib)
files: getattr_for_enum_class.patch
keywords: patch
messages: 197611
nosy: lambacck
priority: normal
severity: normal
status: open
title: Enum should have a __getattr__ that makes all the instances available from an instance
versions: Python 3.4
Added file: http://bugs.python.org/file31745/getattr_for_enum_class.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:07:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 17:07:22 +0000
Subject: [issue18951] In unittest.TestCase.assertRegex change "re" and "regex"
 to "r"
In-Reply-To: <1378521986.13.0.796704852763.issue18951@psf.upfronthosting.co.za>
Message-ID: <1379092042.58.0.229097034865.issue18951@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

[The information in titles, especially long titles that do not fit in the title box (on my system, at least) should be repeated in the opening message.]

The point of the patch is to use the same name for the same object in the two columns* and to use a single letter to be consistent with the rest of the table. I think the patch should be applied.

* Using 're' and 'regex' to mean the same object *is* confusing.

----------
nosy: +terry.reedy
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18951>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:23:07 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 13 Sep 2013 17:23:07 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <1379092987.41.0.593922682652.issue19011@psf.upfronthosting.co.za>


Ethan Furman added the comment:

============================================================================
--> class Test:
...   this = 'that'
...   these = 'those'
... 
--> Test.this
'that'
--> Test.this.these
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'str' object has no attribute 'these'
============================================================================

This is not normal Python behavior, nor does it seem to be behavior intrinsic to enumerations.  It also adds an Alice-in-Wonderland quality to Enums:
============================================================================
--> red = Color.red
--> red.blue.blue.red.green.blue
<Color.blue: 3>
============================================================================

We're going to have to live without this particular "feature".

----------
assignee:  -> ethan.furman
nosy: +barry, eli.bendersky, ethan.furman
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:24:28 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 17:24:28 +0000
Subject: [issue18960] First line can be executed twice
In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>
Message-ID: <1379093068.14.0.758472928339.issue18960@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I thought that that was the specification*: the encoding comment should be the first line unless it has to be the second line to allow for an executable comment. Executing a non-comment first line twice is definitely contrary to the intent of the PEP.

* I have not read it recently ;-).

When running that snippet from 3.3.2 Idle editor, 'first' is only printed once. I consider this to be correct and I would not want to change Idle to match the buggy behavior.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18960>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:26:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Sep 2013 17:26:01 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379093161.68.0.208390305674.issue18993@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, I found the difference.

The second test case is to test the case on which we delete the attribute of the mock instance before being referenced by any variable. The we make sure the attribute is gone for good.

The first test case is to test the case on which we delete the attribute of the mock instance after being referenced by any variable (or maybe just needed to be used by __getattr__), then we make sure the attribute is resetted to the original value, not deleted.

I oversight this because I never thought that people could rely on this behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:28:59 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 13 Sep 2013 17:28:59 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <1379093339.12.0.931938190055.issue19011@psf.upfronthosting.co.za>


Chris Lambacher added the comment:

You are not comparing the same thing. Normally when there is a class parameter, those are available from instances of the class.

>>> class Test:
...    pass
...
>>> Test.this = Test()
>>> Test.that = Test()
>>> Test.this.that
<__main__.Test instance at 0x7ff681bd3560>
>>>
>>> isinstance(Test.this, Test)
True
>>> from enum import IntEnum

>>> class Color(IntEnum):
...     red = 1
...     blue = 2
...     green = 3
...
>>> isinstance(Color.red, Color)
True
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:31:11 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 Sep 2013 17:31:11 +0000
Subject: [issue18960] First line can be executed twice
In-Reply-To: <1379093068.14.0.758472928339.issue18960@psf.upfronthosting.co.za>
Message-ID: <52334BD9.9000904@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.09.2013 19:24, Terry J. Reedy wrote:
> 
> Terry J. Reedy added the comment:
> 
> I thought that that was the specification*: the encoding comment should be the first line unless it has to be the second line to allow for an executable comment. Executing a non-comment first line twice is definitely contrary to the intent of the PEP.
> 
> * I have not read it recently ;-).
> 
> When running that snippet from 3.3.2 Idle editor, 'first' is only printed once. I consider this to be correct and I would not want to change Idle to match the buggy behavior.

Agreed. The PEP never intended to allow executable first lines in
a Python code file.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18960>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:33:25 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Sep 2013 17:33:25 +0000
Subject: [issue17087] Improve the repr for regular expression match objects
In-Reply-To: <1359589982.45.0.929656950631.issue17087@psf.upfronthosting.co.za>
Message-ID: <1379093605.6.0.190260618442.issue17087@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Added the new version.

----------
Added file: http://bugs.python.org/file31746/sre_repr3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17087>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:34:34 2013
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 13 Sep 2013 17:34:34 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <1379093674.62.0.379503690398.issue19011@psf.upfronthosting.co.za>


Ethan Furman added the comment:

My apologies, you are correct.

I am still against this for the Alice reason, but lets see what the others think.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:38:59 2013
From: report at bugs.python.org (Chris Lambacher)
Date: Fri, 13 Sep 2013 17:38:59 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <1379093939.76.0.0530964492643.issue19011@psf.upfronthosting.co.za>


Chris Lambacher added the comment:

For what it's worth, I was confused by the inability to access the class members from the instance for like 3 or 4 weeks until I realized that the instances were not actually on the class and the implications of that for class attribute access.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:48:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 17:48:59 +0000
Subject: [issue18961] Non-UTF8 encoding line
In-Reply-To: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>
Message-ID: <1379094539.98.0.427201935541.issue18961@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Which behavior do you propose to change? Does PEP263 specify the response to a self-contradictory encoding comment? What do you think it should say?

I raising is the better behavior. 

Idle notices that it cannot save the file with iso8859-15 encoding, so it saves it with utf-8 encoding instead. Any Python-aware editor that recognizes and uses the encoding cookie would have to either do the same or refuse to save until the encoding specification were changed.

Trying to run the file brings up a error box with SyntaxError: encoding problem: utf-8. Note that Idle runs a syntax check before creating a new subprocess, connecting to it, and trying to actually run the file. Closing the box takes one back to the editor as the spot where the error was noticed, which in this case is at the end of the line.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18961>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:49:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 17:49:59 +0000
Subject: [issue18965] 2to3 can produce illegal bytes literals
In-Reply-To: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za>
Message-ID: <1379094599.67.0.932381260476.issue18965@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18965>
_______________________________________

From report at bugs.python.org  Fri Sep 13 19:54:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 17:54:21 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <3cc4H01LbBz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 540a9c69c2ea by Charles-Fran?ois Natali in branch 'default':
Issue #16201: socket: Use inet_pton()/inet_addr() instead of ad-hoc parsing for
http://hg.python.org/cpython/rev/540a9c69c2ea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:07:48 2013
From: report at bugs.python.org (py.user)
Date: Fri, 13 Sep 2013 18:07:48 +0000
Subject: [issue18951] In unittest.TestCase.assertRegex change "re" and "regex"
 to "r"
In-Reply-To: <1378521986.13.0.796704852763.issue18951@psf.upfronthosting.co.za>
Message-ID: <1379095668.33.0.111140695737.issue18951@psf.upfronthosting.co.za>


py.user added the comment:

ok, I will repeat patch contents in message by words to avoid guessing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18951>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:28:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 18:28:06 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1379096886.06.0.516418377712.issue18968@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:28:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 18:28:14 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1379096894.43.0.754466179137.issue18968@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:31:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 18:31:08 +0000
Subject: [issue18974] Use argparse in the diff script
In-Reply-To: <1378654081.42.0.0708536053784.issue18974@psf.upfronthosting.co.za>
Message-ID: <1379097068.32.0.763629886477.issue18974@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18974>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:41:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Sep 2013 18:41:49 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1379097709.09.0.543768436981.issue19006@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I like the current division, but agree that
  The TestCase class provides a number of methods to check for and
  report failures, such as:

is slightly misleading. I would change it to
  The TestCase class provides a number of methods to check for and
  report failures. The most commonly used are:
  ...<table>
  More are listed in the Regex, Comparisons, and Type-specific tables.

where each of Regex, Comparisons, and Type-specific link to their respective tables. (Repaint the link names if you wish ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19006>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:45:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 18:45:22 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379097922.51.0.797550779584.issue18967@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Attached is my rough attempt at a script to auto-generate Misc/NEWS from commit logs. Key points:

- Works from the hg log in XML format as dumped to a file
- Considers a commit newsworthy if it isn't a merge and either has an issue number or has an "interesting" path (e.g. not an HTML file) and details (i.e. the stuff after a \n\n)
- Uses paths in the commit to determine what category the commit belongs to

Decisions to make:

- How to exactly flag a commit should not be in NEWS (I say it doesn't contain "#\d+:" to signify an issue and lacks any details after a \n\n)
- How often to run (e.g. at release time, anyone, post-commit hook, etc.)

----------
nosy: +brett.cannon
Added file: http://bugs.python.org/file31747/newsworthy.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:46:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 18:46:23 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379097983.46.0.315303307109.issue18967@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I like the script name :-)... Other than that, can you attach a NEWS file such as generated by this script?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:46:42 2013
From: report at bugs.python.org (Roy Smith)
Date: Fri, 13 Sep 2013 18:46:42 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1379098002.39.0.97451587751.issue19006@psf.upfronthosting.co.za>


Roy Smith added the comment:

The new text suggested by terry.reedy works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19006>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:54:21 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 18:54:21 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379098461.32.0.55741683033.issue18967@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Example file at Antoine's request. Just don't forget, very rough and not at all finished. =) We probably can't use something like this until Python 3.5 in order to make sure everyone uses commit messages that make sense, but you can get a sense of whether it has a chance of working.

I should also mention that it would be easy to have multiple outputs, e.g. a reST one that links to the actual commit as well as the issue in order to have a pretty version for the website, etc.

----------
Added file: http://bugs.python.org/file31748/very_early_output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 20:57:22 2013
From: report at bugs.python.org (Sjoerd)
Date: Fri, 13 Sep 2013 18:57:22 +0000
Subject: [issue19012] liburl2: bad proxy configuration throws "getaddrinfo"
 error
Message-ID: <1379098642.08.0.213959473701.issue19012@psf.upfronthosting.co.za>


New submission from Sjoerd:

I'm sorry for providing very little information, but I don't have the system at hand anymore. Therefore I will try to reproduce what I know, hoping that you recognise the problem. If not, I will get back to the system and try to obtain the necessary information.

Calling liburl2.openurl('http://www.google.com') gave me an getaddrinfo error. Therefore, I checked my DNS configuration, which seemed okay and I issued a socket.getaddrinfo('www.google.com'), which correctly returned an IP address. Finally, I found out that I had an old, non-existing (?) proxy configuration in the Windows registry (that indeed turned up when calling liburl2.getproxies()). Removing the proxy configuration from my Windows registry solved the problem.

Is it preliminary to conclude that the getaddrinfo error may actually mean several things (not only a simple getaddrinfo problem)? If so, I suggest that the error message be broadened ("DNS lookup or proxy problem"), because it took me several hours to find the proxy problem.

----------
components: Library (Lib)
messages: 197629
nosy: SjoerdOptLand
priority: normal
severity: normal
status: open
title: liburl2: bad proxy configuration throws "getaddrinfo" error
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19012>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:13:44 2013
From: report at bugs.python.org (py.user)
Date: Fri, 13 Sep 2013 19:13:44 +0000
Subject: [issue18206] license url in site.py should always use X.Y.Z form of
 version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379099624.2.0.417494671082.issue18206@psf.upfronthosting.co.za>


py.user added the comment:

Senthil Kumaran changed the pattern

from: r'^See (http://www\.python\.org/[^/]+/license.html)$'
  to: r'^See (http://www\.python\.org/download/releases/[^/]+/license/)$'

test doesn't pass

[guest at localhost cpython]$ ./python
Python 3.4.0a2+ (default, Sep 14 2013, 05:56:46) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> license()
See http://www.python.org/3.4/license.html
>>>


make test
...
[265/380/3] test_site
test test_site failed -- Traceback (most recent call last):
  File "/home/guest/tmp/tests/misc/git/example/cpython/Lib/test/test_site.py", line 416, in test_license_page
    self.assertIsNotNone(mo, msg='can\'t find appropriate url in license')
AssertionError: unexpectedly None : can't find appropriate url in license
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:20:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 19:20:40 +0000
Subject: [issue18951] In unittest.TestCase.assertRegex change "re" and "regex"
 to "r"
In-Reply-To: <1378521986.13.0.796704852763.issue18951@psf.upfronthosting.co.za>
Message-ID: <3cc6Bc222NzQwf@mail.python.org>


Roundup Robot added the comment:

New changeset 03e94f9884ce by Ezio Melotti in branch '3.3':
#18951: use consistent names in unittest docs.
http://hg.python.org/cpython/rev/03e94f9884ce

New changeset eb332e3dc303 by Ezio Melotti in branch 'default':
#18951: merge with 3.3.
http://hg.python.org/cpython/rev/eb332e3dc303

New changeset 6d8ff8c57d38 by Ezio Melotti in branch '2.7':
#18951: use consistent names in unittest docs.
http://hg.python.org/cpython/rev/6d8ff8c57d38

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18951>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:20:53 2013
From: report at bugs.python.org (py.user)
Date: Fri, 13 Sep 2013 19:20:53 +0000
Subject: [issue18206] license url in site.py should always use X.Y.Z form of
 version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379100053.19.0.570267215077.issue18206@psf.upfronthosting.co.za>


Changes by py.user <bugzilla-mail-box at yandex.ru>:


----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:23:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 19:23:38 +0000
Subject: [issue18951] In unittest.TestCase.assertRegex change "re" and "regex"
 to "r"
In-Reply-To: <1378521986.13.0.796704852763.issue18951@psf.upfronthosting.co.za>
Message-ID: <1379100218.05.0.30141902151.issue18951@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!
I also updated the table entry for assertRaisesRegex and assertWarnsRegex.
I avoid using "regex" instead of "re" or "r" to keep it short and avoid confusion with the re/regex modules.  The documentation of the methods uses "regex", but there it's OK.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18951>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:26:26 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Sep 2013 19:26:26 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379100386.98.0.841637447761.issue18967@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:28:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 19:28:09 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379100489.47.0.0540866972312.issue18967@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Decisions to make:

Another important question: how do we manage manual edits to Misc/NEWS? Is the script smart enough to recognize those edits and not override them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:49:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 19:49:11 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
Message-ID: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Nothing happens when you try to execute it on the command line:

$ ./python -m unittest.test
/home/antoine/cpython/default/python: No module named unittest.test.__main__; 'unittest.test' is a package and cannot be directly executed
$ ./python -m unittest.test.test_case
$

----------
components: Library (Lib), Tests
messages: 197634
nosy: ezio.melotti, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest's own test suite is not CLI-friendly
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:52:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 19:52:19 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379101939.15.0.0428780775774.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an alternative C implementation. It adds to the dict class support of the __transform__() method. If this method is defined in dict subclass it used to transforming keys. collections.TransformDict is just utilizes this feature as collections.defaultdict utilizes __missing__(). This patch changes twice less C code than previous one (227 vs 474 lines).

----------
Added file: http://bugs.python.org/file31749/dict__transform__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Sep 13 21:53:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 19:53:38 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1379102018.92.0.491087243933.issue18937@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Question: should the default level threshold be INFO or WARNING?
My initial patch uses INFO, but WARNING might be better since that's also logging's default level filter when not configured.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18937>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:00:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 20:00:04 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379102404.76.0.0823931162621.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Does it slow down regular dicts?

I were surprized, but yes. The ComplexPythonFunctionCalls test from pybench is 40% slower with ctransformdict.patch (and I still don't known why). With dict__transform__.patch it is only 2% slower. All other pybench tests are approximately equal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:05:10 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Sep 2013 20:05:10 +0000
Subject: [issue18990] Remove unnecessary API inconsistency from
 ElementTree.XMLPullParser.close()
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379102710.52.0.546565370697.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I've updated the lxml documentation to reflect the new implementation. It also has a couple of examples that show how the API works now.

https://github.com/lxml/lxml/blob/74ab4b10176750e7797eb0eff3c7c91901ab6adb/doc/parsing.txt#L509

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:12:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 20:12:27 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379103147.38.0.401371863217.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

I am opposed to generating NEWS from the commit messages.  I thought Antoine was too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:13:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:13:13 +0000
Subject: [issue18955] Confusing documentation in Lib/importlib/util.py
In-Reply-To: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>
Message-ID: <1379103193.88.0.00789225146994.issue18955@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +brett.cannon
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18955>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:15:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:15:15 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1379103315.98.0.861645901897.issue18958@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18958>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:17:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 20:17:28 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1379103147.38.0.401371863217.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379103445.2532.53.camel@fsol>


Antoine Pitrou added the comment:

> I am opposed to generating NEWS from the commit messages.  I thought Antoine was too.

I am *a priori* skeptical that auto-generating NEWS can give good
enough results, but I don't mind being proven wrong :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:17:57 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 20:17:57 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379103477.55.0.782666180096.issue18967@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Antoine: Script isn't far enough along to care about manual edits.

David: That's fine, but I'm opposed to having to manually edit Misc/NEWS. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:20:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 20:20:43 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1379103643.63.0.681531034374.issue18937@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is an updated patch:
- documentation added
- tests improved a bit and style fixed (removed leading underscores on helper methods)

----------
Added file: http://bugs.python.org/file31750/assertlogs2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18937>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:23:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 20:23:22 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379103802.7.0.904269766856.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

Just to be clear: the reason I am opposed is that the audience for Misc/NEWS is different from the audience for commit messages, and I would prefer that the text reflect that.  Mine do :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:23:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 20:23:45 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1379102404.76.0.0823931162621.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379103822.2532.54.camel@fsol>


Antoine Pitrou added the comment:

> > Does it slow down regular dicts?
> 
> I were surprized, but yes. The ComplexPythonFunctionCalls test from
> pybench is 40% slower with ctransformdict.patch (and I still don't
> known why). With dict__transform__.patch it is only 2% slower. All
> other pybench tests are approximately equal.

Did you try any other microbenchmarks? Your approach sounds promising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:25:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:25:20 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379103920.19.0.92611576099.issue18967@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

If the goal is avoiding merging conflicts, a Mercurial hook might solve this problem.  This has been already suggested and discussed on python-dev a while ago.

Anything more complex than that would likely cause more problems that it solves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:25:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 20:25:33 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379103933.74.0.697198680326.issue18059@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:28:16 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Sep 2013 20:28:16 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379104096.41.0.190169454714.issue18059@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:28:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:28:45 +0000
Subject: [issue18959] Create a "Superseded modules" section in standard
 library ToC
In-Reply-To: <1378559362.61.0.726437189184.issue18959@psf.upfronthosting.co.za>
Message-ID: <1379104125.64.0.841318327917.issue18959@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18959>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:34:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:34:20 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1379104460.12.0.117983155709.issue18968@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Isn't this a duplicate of #16056?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:35:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:35:22 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1379104522.54.0.852833934277.issue18968@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also 16079.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:38:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 20:38:20 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379104700.14.0.25167117168.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Did you try any other microbenchmarks? Your approach sounds promising.

Any microbenchmarks which I tried did not show any interesting. Until I found the cause of slowing down ComplexPythonFunctionCalls I have no idea which tests can be representable.

Of course you can run benchmarks yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:40:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:40:11 +0000
Subject: [issue18971] Use argparse in the profile/cProfile modules
In-Reply-To: <1378651735.34.0.106872134579.issue18971@psf.upfronthosting.co.za>
Message-ID: <1379104811.9.0.163754483432.issue18971@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Is the command-line interface covered by tests?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18971>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:43:21 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 20:43:21 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379105001.13.0.906283098675.issue18967@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I get the argument against, but from my experience the difference between the opening line of a commit and what goes into Misc/NEWS is negligible at best. All of the commit-specific stuff for me goes "below the fold" after \n\n.

And while the goal is partially to avoid merge conflicts, it's also to avoid writing the same thing essentially twice along with controlling the format of Misc/NEWS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:44:28 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 20:44:28 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1379105068.56.0.47583815925.issue18716@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Making a deferred blocker to make sure I get around to deprecating before b1.

----------
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18716>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:44:51 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 Sep 2013 20:44:51 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1379103802.7.0.904269766856.issue18967@psf.upfronthosting.co.za>
Message-ID: <5233793C.4080604@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.09.2013 22:23, R. David Murray wrote:
> 
> R. David Murray added the comment:
> 
> Just to be clear: the reason I am opposed is that the audience for Misc/NEWS is different from the audience for commit messages, and I would prefer that the text reflect that.  Mine do :)

I'm with David and -1 on auto-generating documentation that
is meant for Python users. Here's my take on the intentions
behind the various forms of documentation we have:

 * Commit messages only provide a very terse hint at what a
   particular patch set was meant for. The target audience
   is other core developers.

 * News entries explain these patches (there may be more than one
   for a particular issue or project) to Python programmers who
   need to know what to watch out for when upgrading to a new
   version.

 * The "What's New" document explains the reasoning and effects
   of major changes and gives a high level overview of what
   to expect in a new version.

 * Finally, the Python documentation, with it's "Version added"
   markers, provides details to application programmers who need
   to know how the new techniques work and when they were added
   (in order to determine which APIs they can use if they want to
   support multiple Python versions).

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:50:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:50:44 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379105444.18.0.0428654870621.issue18967@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> it's also to avoid writing the same thing essentially twice

Before committing I always make an "hg di" to double-check, and then copy (part of) the Misc/NEWS entry (that usually happens to be conveniently placed at the end of the diff) in the commit message.

Automating the generation of Misc/NEWS would likely make whatever modification we might want to do to the content more difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:51:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 20:51:09 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379105469.39.0.999568400375.issue18967@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I would argue, MAL, that what you want Misc/NEWS to be should instead be merged into the end of What's New. If something changed which could potentially break a user it should be listed in the most visible upgrade doc we have. Otherwise pouring through Misc/NEWS is a trudge and you might as well read the commit logs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:52:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 20:52:29 +0000
Subject: [issue19014] Allow memoryview.cast() for empty views
Message-ID: <1379105549.83.0.888503022363.issue19014@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is one of most annoying things in Python to me. When you want accept any bytes-like object in you bytes-processing function you need special case empty input.

def foo(data):
    data = memoryview(data)
    if data:
        data = data.cast('B')
    else:
        data = b''

You can't use just memoryview(data).cast('B') because it doesn't work for empty data.

>>> memoryview(b'').cast('b')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: memoryview: cannot cast view with zeros in shape or strides

It would be very nice to allow cast() for empty views.

----------
components: Interpreter Core
messages: 197655
nosy: pitrou, serhiy.storchaka, skrah, teoliphant
priority: normal
severity: normal
status: open
title: Allow memoryview.cast() for empty views
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19014>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:52:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 20:52:33 +0000
Subject: [issue18955] Confusing documentation in Lib/importlib/util.py
In-Reply-To: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>
Message-ID: <3cc8Dc6Ys7z7Lk0@mail.python.org>


Roundup Robot added the comment:

New changeset ecc18ec4a12e by Brett Cannon in branch 'default':
Issue #18955: clarify what is removed by importlib.util.module_for_loader.
http://hg.python.org/cpython/rev/ecc18ec4a12e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18955>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:52:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Sep 2013 20:52:53 +0000
Subject: [issue18955] Confusing documentation in Lib/importlib/util.py
In-Reply-To: <1378529793.43.0.614039652943.issue18955@psf.upfronthosting.co.za>
Message-ID: <1379105573.13.0.532931290155.issue18955@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18955>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:54:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 20:54:52 +0000
Subject: [issue18981] Typo in the ctypes tests
In-Reply-To: <1378673741.26.0.448771285371.issue18981@psf.upfronthosting.co.za>
Message-ID: <3cc8HH3YZ3zMGY@mail.python.org>


Roundup Robot added the comment:

New changeset b90ba60c5029 by Ezio Melotti in branch '2.7':
#18981: fix a typo in a comment (noticed by Anoop Thomas Mathew).
http://hg.python.org/cpython/rev/b90ba60c5029

New changeset 9fcb9deb70f5 by Ezio Melotti in branch '3.3':
#18981: fix a typo in a comment (noticed by Anoop Thomas Mathew).
http://hg.python.org/cpython/rev/9fcb9deb70f5

New changeset dae3e64e1743 by Ezio Melotti in branch 'default':
#18981: merge with 3.3.
http://hg.python.org/cpython/rev/dae3e64e1743

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18981>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:55:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 20:55:25 +0000
Subject: [issue18981] Typo in the ctypes tests
In-Reply-To: <1378673741.26.0.448771285371.issue18981@psf.upfronthosting.co.za>
Message-ID: <1379105725.03.0.852371328739.issue18981@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18981>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:55:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 20:55:34 +0000
Subject: [issue19014] Allow memoryview.cast() for empty views
In-Reply-To: <1379105549.83.0.888503022363.issue19014@psf.upfronthosting.co.za>
Message-ID: <1379105734.09.0.565982178051.issue19014@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This actually sounds like a bug to me. A view over the empty bytestring is a one-dimensional zero-length view, it isn't a special kind of entity.

----------
nosy: +ncoghlan
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19014>
_______________________________________

From report at bugs.python.org  Fri Sep 13 22:56:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 20:56:32 +0000
Subject: [issue18971] Use argparse in the profile/cProfile modules
In-Reply-To: <1378651735.34.0.106872134579.issue18971@psf.upfronthosting.co.za>
Message-ID: <1379105792.54.0.569130249143.issue18971@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No. And I know your next proposition. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18971>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:01:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 21:01:26 +0000
Subject: [issue18948] deliberately crashing tests should prevent core dumps
In-Reply-To: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>
Message-ID: <1379106086.79.0.733706445458.issue18948@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've left a comment on the review tool above. You can click on the "review" link if you haven't received an e-mail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18948>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:07:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 21:07:50 +0000
Subject: [issue19014] Allow memoryview.cast() for empty views
In-Reply-To: <1379105549.83.0.888503022363.issue19014@psf.upfronthosting.co.za>
Message-ID: <1379106470.7.0.515899994627.issue19014@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Cool. Therefore I can hope on fixing this in maintained releases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19014>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:10:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 21:10:10 +0000
Subject: [issue19014] Allow memoryview.cast() for empty views
In-Reply-To: <1379106470.7.0.515899994627.issue19014@psf.upfronthosting.co.za>
Message-ID: <1379106607.2532.57.camel@fsol>


Antoine Pitrou added the comment:

> Cool. Therefore I can hope on fixing this in maintained releases?

Provided someone makes a patch :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19014>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:10:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 21:10:24 +0000
Subject: [issue18985] Improve the documentation in fcntl module
In-Reply-To: <1378722919.93.0.901392318122.issue18985@psf.upfronthosting.co.za>
Message-ID: <1379106624.33.0.780305317814.issue18985@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18985>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:13:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Sep 2013 21:13:42 +0000
Subject: [issue18206] license url in site.py should always use X.Y.Z form of
 version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379106822.55.0.184028193578.issue18206@psf.upfronthosting.co.za>


R. David Murray added the comment:

The test needs to be fixed so that it runs even when the LICENSE file exists. (It is also missing the skip when the network resource is not asserted.)  I have a patched test, and a fix for the 3.4 problem, but I can't apply it because the 3.4.0 license file does not yet exist on the website.

On the other hand, this test could be a pain before the first alpha is released (the web URL doesn't exist yet), so perhaps the test also needs to special case that somehow.

----------
nosy: +larry
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:13:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Sep 2013 21:13:51 +0000
Subject: [issue18022] Inconsistency between quopri.decodestring() and
 email.quoprimime.decode()
In-Reply-To: <1369059208.07.0.0770184639372.issue18022@psf.upfronthosting.co.za>
Message-ID: <1379106831.49.0.0201991281881.issue18022@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

So what scheme we will picked?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18022>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:18:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 21:18:38 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
In-Reply-To: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>
Message-ID: <1379107118.12.0.976969963724.issue18994@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, neologix
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18994>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:19:54 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Sep 2013 21:19:54 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
In-Reply-To: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>
Message-ID: <1379107194.63.0.647286455919.issue19013@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:26:37 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Sep 2013 21:26:37 +0000
Subject: [issue18731] Increased test coverage for uu and telnet
In-Reply-To: <1377643461.79.0.131386576227.issue18731@psf.upfronthosting.co.za>
Message-ID: <1379107597.74.0.958688604583.issue18731@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18731>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:34:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 21:34:51 +0000
Subject: [issue19014] Allow memoryview.cast() for empty views
In-Reply-To: <1379105549.83.0.888503022363.issue19014@psf.upfronthosting.co.za>
Message-ID: <1379108091.17.0.115582243906.issue19014@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch. I can't tell whether it's right for sure, since the whole buffer thing has become so complicated.

----------
keywords: +patch
Added file: http://bugs.python.org/file31751/zerocast.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19014>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:35:24 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 13 Sep 2013 21:35:24 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1379105469.39.0.999568400375.issue18967@psf.upfronthosting.co.za>
Message-ID: <52338515.6080905@egenix.com>


Marc-Andre Lemburg added the comment:

On 13.09.2013 22:51, Brett Cannon wrote:
> 
> Brett Cannon added the comment:
> 
> I would argue, MAL, that what you want Misc/NEWS to be should instead be merged into the end of What's New. If something changed which could potentially break a user it should be listed in the most visible upgrade doc we have. Otherwise pouring through Misc/NEWS is a trudge and you might as well read the commit logs.

There are often lots of small changes between releases that don't
end up in the What's New, but which can still make changes necessary
in user applications. Also, "What' New" is often not updated for
patch level releases, so the NEWS file is the only source to
track patch level changes.

And again, no, going through commit messages does not give the
same kind of information as in the NEWS file :-)

As you can see in your auto-generated file, there are multiple
entries for the same ticket, some entries don't reference a ticket,
there's no structure in the file, it includes everything (including
changes that were reverted again before the release), etc.

The auto generation would only result in the same kind of NEWS
file if everyone were really stringent in the way they write commit
messages. With hg not supporting editing commit messages after
the fact (apart from perhaps the last one), this is bound to
cause extra overhead to e.g. fix typos, add more infos, remove/hide
unnecessary entries, etc. We're all humans after all ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:35:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Sep 2013 21:35:32 +0000
Subject: [issue18948] deliberately crashing tests should prevent core dumps
In-Reply-To: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>
Message-ID: <1379108132.8.0.536373641303.issue18948@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18948>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:44:22 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Sep 2013 21:44:22 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379108662.54.0.615091878044.issue18987@psf.upfronthosting.co.za>


Ned Deily added the comment:

A compatibility issue here is that the value provided by get_platform() is also used outside of Distutils, in particular by pkg_resources (provided by setuptools) and by pip, in both cases to help determine whether a binary distribution of an extension module is compatible with the python being used.  It's also used in Distutils to form the name of the build directory for extension modules.  I believe at the moment pip requires an exact match of the get_platform() value for most platforms, other than OS X, so it is possible that making this change could break downloads of existing binary egg-based distributions. (On the other hand, binary distributions for Linux platforms are known to be problematic because of API differences that are not reflected in the platform-derived string.)  So any change in behavior here should probably be limited to a feature release (like 3.4) and in coordination with the Pypa packaging developers (setuptools, pip, wheel, et al) to minimize disruptions.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:46:34 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 13 Sep 2013 21:46:34 +0000
Subject: [issue18999] Robustness issues in multiprocessing.{get,
 set}_start_method
In-Reply-To: <1378824821.26.0.31883015251.issue18999@psf.upfronthosting.co.za>
Message-ID: <1379108794.81.0.77958822481.issue18999@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I'll review the patch.  (According to http://www.python.org/dev/peps/pep-0429/ feature freeze is expected in late November, so there is not too much of rush.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18999>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:54:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 21:54:07 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
In-Reply-To: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>
Message-ID: <3cc9bg0Qztz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 1d08ce952592 by Antoine Pitrou in branch 'default':
Issue #19013: add unittest.main() epilogs to unittest's own test modules
http://hg.python.org/cpython/rev/1d08ce952592

New changeset f81a53580c45 by Antoine Pitrou in branch 'default':
Issue #19013: add unittest.main() epilogs to unittest.mock's own test modules
http://hg.python.org/cpython/rev/f81a53580c45

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Fri Sep 13 23:59:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 21:59:01 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
In-Reply-To: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>
Message-ID: <1379109541.52.0.755301702969.issue19013@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

When trying to use a standard load_tests() inside a __main__.py, I get the following kind of errors:

======================================================================
ERROR: test_suite (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 56, in testPartExecutor
    yield
  File "/home/antoine/cpython/default/Lib/unittest/case.py", line 496, in run
    testMethod()
  File "/home/antoine/cpython/default/Lib/unittest/loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: test_suite
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/unittest/loader.py", line 272, in _find_tests
    module = self._get_module_from_name(name)
  File "/home/antoine/cpython/default/Lib/unittest/loader.py", line 250, in _get_module_from_name
    __import__(name)
  File "/home/antoine/cpython/default/Lib/unittest/test/test_suite.py", line 6, in <module>
    from .support import LoggingResult, TestEquality
SystemError: Parent module '' not loaded, cannot perform relative import


... which means that loader.discover() doesn't try to import the test modules as part of their parent package, but as if they were standalone modules :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:05:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Sep 2013 22:05:35 +0000
Subject: [issue18961] Non-UTF8 encoding line
In-Reply-To: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>
Message-ID: <1379109935.3.0.412994122276.issue18961@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18961>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:06:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Sep 2013 22:06:29 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
In-Reply-To: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>
Message-ID: <1379109989.74.0.157803542709.issue18994@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18994>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:07:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Sep 2013 22:07:35 +0000
Subject: [issue19005] PyIter_Next crashes if passed a non-iterator
In-Reply-To: <1378894942.16.0.763585748614.issue19005@psf.upfronthosting.co.za>
Message-ID: <1379110055.73.0.0109387769049.issue19005@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19005>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:08:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Sep 2013 22:08:57 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379110137.38.0.520816162704.issue19001@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:11:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Sep 2013 22:11:49 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379110309.01.0.0736754822125.issue18553@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Why only changing Python 2 documentation?

http://docs.python.org/dev/library/os.html#os.isatty
still mention "Availability: Unix."

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:38:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 22:38:02 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
In-Reply-To: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>
Message-ID: <3ccBZL0WZdz7Ljl@mail.python.org>


Roundup Robot added the comment:

New changeset bbcdcdb06c66 by Antoine Pitrou in branch 'default':
Issue #19013: add a __main__ to unittest.test to ease CLI invocation
http://hg.python.org/cpython/rev/bbcdcdb06c66

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:39:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Sep 2013 22:39:21 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
In-Reply-To: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>
Message-ID: <3ccBbr4Ygqz7Ljn@mail.python.org>


Roundup Robot added the comment:

New changeset c2b926c0d0c2 by Antoine Pitrou in branch 'default':
Issue #19013: add a __main__ to unittest.test.testmock to ease CLI invocation
http://hg.python.org/cpython/rev/c2b926c0d0c2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:39:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Sep 2013 22:39:44 +0000
Subject: [issue19013] unittest's own test suite is not CLI-friendly
In-Reply-To: <1379101751.33.0.506221476811.issue19013@psf.upfronthosting.co.za>
Message-ID: <1379111984.88.0.0402330393798.issue19013@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19013>
_______________________________________

From report at bugs.python.org  Sat Sep 14 00:42:03 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 13 Sep 2013 22:42:03 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379112123.88.0.0607517838197.issue18553@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I had removed them in all. Something must have gone wrong if still present or I did a mistake.


changeset:   85594:678e3c0d2d99
parent:      85591:c116b658aede
parent:      85593:14ba90816930
user:        Senthil Kumaran <senthil at uthcode.com>
date:        Sat Sep 07 11:30:04 2013 -0700
files:       Doc/library/os.rst
description:
merge from 3.3

Removing the mention of os.isatty mention as Unix only
Correct the wrong documentation.


changeset:   85593:14ba90816930
branch:      3.3
parent:      85589:dd669daad7de
user:        Senthil Kumaran <senthil at uthcode.com>
date:        Sat Sep 07 11:28:58 2013 -0700
files:       Doc/library/os.rst
description:
Removing the mention of os.isatty mention as Unix only
Correct the wrong documentation.


changeset:   85592:d5c5ac33b9a1
branch:      2.7
parent:      85588:523cfc78847c
user:        Senthil Kumaran <senthil at uthcode.com>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Sat Sep 14 01:33:02 2013
From: report at bugs.python.org (py.user)
Date: Fri, 13 Sep 2013 23:33:02 +0000
Subject: [issue18206] license url in site.py should always use X.Y.Z form of
 version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379115182.31.0.751386200161.issue18206@psf.upfronthosting.co.za>


py.user added the comment:

R. David Murray wrote:

>It is also missing the skip when the network resource is not asserted.

How it connects, I copied from another python tests.
The test was skipped without network connection.

"support.requires('network')" ?

>the 3.4.0 license file does not yet exist on the website

http://www.python.org/download/releases/3.4.0/license/
opens

>The test needs to be fixed so that it runs even when the LICENSE file exists.

The fixture can rename it back and forth.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep 14 01:34:40 2013
From: report at bugs.python.org (py.user)
Date: Fri, 13 Sep 2013 23:34:40 +0000
Subject: [issue18206] The license url in site.py should always use X.Y.Z form
 of version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379115280.9.0.574762336674.issue18206@psf.upfronthosting.co.za>


Changes by py.user <bugzilla-mail-box at yandex.ru>:


----------
title: license url in site.py should always use X.Y.Z form of version number -> The license url in site.py should always use X.Y.Z form of version number

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep 14 01:38:31 2013
From: report at bugs.python.org (py.user)
Date: Fri, 13 Sep 2013 23:38:31 +0000
Subject: [issue18206] The license url in site.py should always use X.Y.Z form
 of version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379115511.93.0.926136294236.issue18206@psf.upfronthosting.co.za>


py.user added the comment:

The patch needs to be compatible with version 2.7
Now there urllib.request is importing only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep 14 03:31:34 2013
From: report at bugs.python.org (Valerie Lambert)
Date: Sat, 14 Sep 2013 01:31:34 +0000
Subject: [issue18948] deliberately crashing tests should prevent core dumps
In-Reply-To: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>
Message-ID: <1379122294.18.0.25687788492.issue18948@psf.upfronthosting.co.za>


Valerie Lambert added the comment:

Oops! That was careless. Fixed.

----------
Added file: http://bugs.python.org/file31752/issue-18948_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18948>
_______________________________________

From report at bugs.python.org  Sat Sep 14 04:01:11 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 14 Sep 2013 02:01:11 +0000
Subject: [issue19015] Too long command returns 32512
Message-ID: <1379124071.08.0.89239994658.issue19015@psf.upfronthosting.co.za>


New submission from Sworddragon:

If a command gets too long os.system() will return 32512. As I have figured out from Google this normally happens if the command can't be found. In the attachments is an example command which will fail on os.system() (it was generated as test during development - it is nearly 600.000 characters long). Executing the file with bash works fine but using os.system() makes troubles.

----------
components: Library (Lib)
files: test.sh
messages: 197680
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Too long command returns 32512
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31753/test.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19015>
_______________________________________

From report at bugs.python.org  Sat Sep 14 04:11:52 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Sep 2013 02:11:52 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1379086627.5.0.418224331782.issue18989@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dLcoxhRLp5Fq8sVzdGPrz9YN=2eYJcwm8Gdathx8PvtA@mail.gmail.com>


Nick Coghlan added the comment:

+1 from me to just allow the names to be overwritten, even by another enum
member.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 04:16:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 02:16:53 +0000
Subject: [issue19015] Too long command returns 32512
In-Reply-To: <1379124071.08.0.89239994658.issue19015@psf.upfronthosting.co.za>
Message-ID: <1379125013.15.0.185770161462.issue19015@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Python simply delegates to the system() C function:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html

I don't think it's a Python-specific issue here.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19015>
_______________________________________

From report at bugs.python.org  Sat Sep 14 06:25:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Sep 2013 04:25:02 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379132702.95.0.506411656524.issue19001@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'd seen this locally, but hadn't got around to looking into it. I just realised it is likely related to the internal changes in sets, so I'll see if I can come up with a patch.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sat Sep 14 06:41:18 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Sep 2013 04:41:18 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379133678.54.0.101601277502.issue19001@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Running test_gdb on its own didn't reproduce the error in a threads-enabled build on Fedora 19. I'm now trying it with the same command line as the failed buildbot run:

    /python  ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600 --randseed=6475478

If that still passes, I'll try a without-threads build.

If I can't reproduce it even with threads disabled, then I'd be inclined to say "closed won't fix" on the grounds that Fedora 16 is already end-of-life.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sat Sep 14 07:06:55 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 14 Sep 2013 05:06:55 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379135215.5.0.051999319643.issue18989@psf.upfronthosting.co.za>


Ethan Furman added the comment:

That is expressly forbidden in the PEP.  Can we change it now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 07:26:45 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 14 Sep 2013 05:26:45 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379136405.27.0.0528394382778.issue18059@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I don't think I have my head deep enough in the encodings implementation to say that this is the correct/best way to do it, but the patch looks mostly reasonable to me and would be a helpful addition.

I have two comments on the pyexpat_encoding_convert() function:

1) I can't see a safe-guard against reading beyond the data buffer. What if s already points to the last byte and we are trying to read two or three bytes to decode them? I wouldn't be surprised to see that this kind of input can be crafted.

2) Creating a throw-away Unicode object through a named decoder looks like a huge overhead for decoding two bytes. It might be considered an optimisation to change that, but if you are really trying to parse a longer XML document with lots of Japanese text in it (i.e. if you actually *need* this feature), it will most likely end up being way too slow to make any real use of it.

I think that both points should be addressed before this gets added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:02:31 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 14 Sep 2013 07:02:31 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379142151.38.0.843719265024.issue18989@psf.upfronthosting.co.za>


Georg Brandl added the comment:

It can be changed up to beta1, with good reasons of course. Many PEPs are actually out of date with respect to the actual implementation in minor points.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:03:22 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 14 Sep 2013 07:03:22 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379142202.93.0.0299161539603.issue18989@psf.upfronthosting.co.za>


Georg Brandl added the comment:

That said, for a PEP that has seen so much discussion before being accepted, the agreed-on API should not be changed lightly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:04:30 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 Sep 2013 07:04:30 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1379142270.33.0.498503155259.issue18968@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18968>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:11:01 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 14 Sep 2013 07:11:01 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1379142661.92.0.321976399482.issue16248@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Should be fixed now in 3.2 too.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:12:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Sep 2013 07:12:15 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <3ccPzf2zl3z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset c18c18774e24 by Georg Brandl in branch '3.2':
Fix tkinter regression introduced by the security fix in #16248.
http://hg.python.org/cpython/rev/c18c18774e24

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:14:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 07:14:26 +0000
Subject: [issue18907] urllib2.open FTP open times out at 20 secs despite
 timeout parameter
In-Reply-To: <1378145931.18.0.826598432393.issue18907@psf.upfronthosting.co.za>
Message-ID: <1379142866.57.0.519743022576.issue18907@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18907>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:14:33 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 Sep 2013 07:14:33 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379142873.26.0.594954268915.issue18993@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The duplicate_code_names.py script in issue 16079 did find that there
are duplicate test_attribute_deletion tests in testmock.py (see
http://bugs.python.org/file27376/std_lib_duplicates.txt).

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:16:03 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 14 Sep 2013 07:16:03 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1379142963.33.0.702674062566.issue18709@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Christian, is the -py32 patch still up to date?

----------
nosy: +larry
priority: critical -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:22:59 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 07:22:59 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <3cc4H01LbBz7LjN@mail.python.org>
Message-ID: <CAH_1eM1EUKakhdsNfBQ6_kzNd8eh2PXzvmU7c2bQ5eXHJ2XhqQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Alright, I committed it to default.

I don't think it should go into 2.7 or 3.3, since it's more an
enhancement than a bug fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:24:12 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 14 Sep 2013 07:24:12 +0000
Subject: [issue18825] Making msg optional on logging.exception() and similar
 variants
In-Reply-To: <1377343990.79.0.586156704832.issue18825@psf.upfronthosting.co.za>
Message-ID: <1379143452.11.0.780225412164.issue18825@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18825>
_______________________________________

From report at bugs.python.org  Sat Sep 14 09:27:43 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 14 Sep 2013 07:27:43 +0000
Subject: [issue18824] Adding LogRecord attribute "traceback"
In-Reply-To: <1377343016.83.0.299071692967.issue18824@psf.upfronthosting.co.za>
Message-ID: <1379143663.75.0.590658022073.issue18824@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

basicConfig() is for simple usage only. You can use a custom Formatter subclass to meet your specific requirements.

----------
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18824>
_______________________________________

From report at bugs.python.org  Sat Sep 14 10:27:55 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 14 Sep 2013 08:27:55 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379147275.23.0.963814127375.issue18993@psf.upfronthosting.co.za>


Michael Foord added the comment:

On balance I think that this test failing is *correct* (after deleting an attribute the old mock should *not* come back). I'd rather adjust the test to assert this than just remove it though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Sat Sep 14 11:06:00 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Sep 2013 09:06:00 +0000
Subject: [issue18993] There is an overshadowed and invalid test in testmock.py
In-Reply-To: <1378796103.81.0.419617172609.issue18993@psf.upfronthosting.co.za>
Message-ID: <1379149560.28.0.694842318928.issue18993@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Michael, attached the patch to accommodate your request. Yeah, I think this is the best way because I have seen no possible solutions to make both tests work without altering them.

Xavier, that's cool. I didn't know such tool exists. Usually I found the duplicate function/method by using flake plugin in Vim.

----------
Added file: http://bugs.python.org/file31754/fix_overshadowed_test_in_testmock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18993>
_______________________________________

From report at bugs.python.org  Sat Sep 14 11:14:32 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 14 Sep 2013 09:14:32 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1379150072.84.0.558056851523.issue16248@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Fix still needs to be applied on 3.1 branch.

----------
priority: deferred blocker -> release blocker
status: closed -> open
versions: +Python 3.1 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Sat Sep 14 11:36:45 2013
From: report at bugs.python.org (Shawn Krisman)
Date: Sat, 14 Sep 2013 09:36:45 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
Message-ID: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>


New submission from Shawn Krisman:

import mock
from collections import namedtuple

Foo = namedtuple('Foo', bar)
mock_foo = mock.create_autospec(Foo)

if mock_foo:
    print('the namedtuple is truthy')
else:
    print('the namedtuple is not truthy')


The expected behavior is that it should print "the namedtuple is truthy." Instead it prints "the namedtuple is not truthy." Almost all namedtuples are truthy, the exception being the nearly useless namedtuple with 0 fields. The problem stems from the fact that tuples have a __len__ defined which is what is used derive truthiness. MagicMocks define __len__ to be zero by default. Workarounds to the problem are very difficult because you cannot simply define __len__ to be a nonzero number and have the mock work correctly. 


In general MagicMock has defaults that encourage the mocks to be very truthy all around:

__bool__ -- True
__int__ -- 1
__complex__ -- 1j
__float__ -- 1.0
__index__ -- 1

So it was interesting to me to find out that __len__ was defined to be 0. The fix that I am proposing is to make 1 the new default for __len__. I believe this is a more useful default in general because an instance of a class with a __len__ attribute will likely be truthy far more often then not.


There are of course backwards compatibility issues to consider here, however I don't think many people are assuming this behavior. Certainly nobody in the python code base.

----------
components: Library (Lib)
files: namedtuple_truthiness.patch
keywords: patch
messages: 197698
nosy: michael.foord, skrisman
priority: normal
severity: normal
status: open
title: autospecced namedtuples should be truthy by default
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file31755/namedtuple_truthiness.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Sat Sep 14 12:13:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 10:13:24 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1379142202.93.0.0299161539603.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379153602.2498.4.camel@fsol>


Antoine Pitrou added the comment:

Le samedi 14 septembre 2013 ? 07:03 +0000, Georg Brandl a ?crit :
> Georg Brandl added the comment:
> 
> That said, for a PEP that has seen so much discussion before being
> accepted, the agreed-on API should not be changed lightly.

I agree with that.
Also, I think it was argued that Enums are by design "restricted"
classes in that they forbid certain things in the name of convenience
and expectability. I think it is a reasonable design point and, as such,
Enums needn't be as flexible and versatile as normal classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 12:15:17 2013
From: report at bugs.python.org (Drekin)
Date: Sat, 14 Sep 2013 10:15:17 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1379153717.32.0.857637539316.issue1602@psf.upfronthosting.co.za>


Drekin added the comment:

Hello again. I have rewritten the custom stdio objects and implemented them as raw io reading and writing bytes in UTF-16-LE encoding. They are then wrapped in standard BufferedReader/Writer and TextIOWrapper objects. This approach also solves a bug of wrong string length given to WriteConsoleW when the string contained supplementary character. Since we are waiting for Ctrl-C signal to arrive, this implmentation doesn't suffer from http://bugs.python.org/issue18597 . It seems to work when main script is executed however it doesn't work in Python interactive REPL since the REPL doesn't use sys.stdin for input. However it uses its encoding which results in mess when sys.stdin is changed to object with different encoding like UTF-16-LE. See http://bugs.python.org/issue17620 .

----------
Added file: http://bugs.python.org/file31756/streams.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sat Sep 14 13:01:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 11:01:58 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
Message-ID: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Currently, in case of invalid file descriptor (which can happen easily e.g. if the user closes the FD before unregistering it), selector.select() will react differently depending on the backend:

SelectSelector fails with EBADF
PollSelector returns EVENT_READ/EVENT_WRITE for the FD (translated from poll()'s POLLNVAL)
EpollSelector returns nothing (epoll silently removes the FD from the set of monitored FD, there's no EPOLLNVAL)
KqueueSelector behaves like EpollSelector

One possibility would be for PollSelector.select() to raise EBADF in case of POLLNVAL. That would be consistent with select, but not with epoll and kqueue.

Another possibility would be to silently fix those, i.e. in case of EBADF/POLLNVAL in select/poll, remove the offending FD from the list of monitored FDs. That's what libev does (see e.g. http://cvs.schmorp.de/libev/ev_poll.c?revision=1.39&view=markup and http://cvs.schmorp.de/libev/ev.c?revision=1.457&view=markup), and that's also what twisted does, at least for select (see http://twistedmatrix.com/trac/browser/trunk/twisted/internet/selectreactor.py#L77).

One advantage is that once we've detected a bad FD, we remove it so we're sure we won't loop endlessly: e.g. for poll, if the user doesn't try to use the FD no exception will be raised and selector.select() keep reporting the FD ready.

(Note that performing this cleanup is easy for poll since it's flagged with POLLNVAL, but for select this requires looping over the registered FDs, but since that's only called in case of error, it's not performance critical, see Twisted's code)

I personally favor the later solution.

Second point: if we opt for the later solution, we should probably update {EpollSelector,KqueueSelector}.unregister() to silently catch an error if the FD wasn't registered in the underlying epoll/kqueue.
That's what libev does, and amusingly that's what the select module already does:
http://hg.python.org/cpython/file/c9644c1f9c94/Modules/selectmodule.c#l1329

Third point: should the current select behavior (ignoring epoll.unregister() error) be kept?

Thoughts?

----------
messages: 197701
nosy: giampaolo.rodola, gvanrossum, haypo, neologix, pitrou, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: selectors: towards uniform EBADF handling
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Sat Sep 14 13:11:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 11:11:00 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>
Message-ID: <1379157060.54.0.537003409835.issue19017@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Another possibility would be to silently fix those, i.e. in case of
> EBADF/POLLNVAL in select/poll, remove the offending FD from the list of
> monitored FDs.

Or we could remove the fd *and* still raise an error the first time, or at least a warning. It sounds like a programming error, so I'm not sure it's a good idea to silence it.

Note that Twisted still logs an error message. Also, Tornado lets errors through:
https://github.com/facebook/tornado/blob/master/tornado/ioloop.py#L652
https://github.com/facebook/tornado/blob/master/tornado/platform/select.py#L61

----------
nosy: +glyph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Sat Sep 14 13:20:39 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 11:20:39 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379157060.54.0.537003409835.issue19017@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0otg6XvcO3QA_Jp5e4rvCtPUx1ML3fYsSKbe_5Xa6X5w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Or we could remove the fd *and* still raise an error the first time, or at least a warning. It sounds like a programming error, so I'm not sure it's a good idea to silence it.

Yeah, sure. By "silently" I meant "without user intervention", sorry
for the confusion.

Now I'm not sure between raising an error or just logging it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Sat Sep 14 13:21:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 11:21:41 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <CAH_1eM0otg6XvcO3QA_Jp5e4rvCtPUx1ML3fYsSKbe_5Xa6X5w@mail.gmail.com>
Message-ID: <1379157698.2498.5.camel@fsol>


Antoine Pitrou added the comment:

> Now I'm not sure between raising an error or just logging it.

If "logged", it should be a Warning rather than an actual logging call,
IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Sat Sep 14 14:06:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 12:06:53 +0000
Subject: [issue16201] socket.gethostbyname incorrectly parses ip
In-Reply-To: <1349983863.01.0.255097510924.issue16201@psf.upfronthosting.co.za>
Message-ID: <1379160413.85.0.887422218563.issue16201@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Closing, thanks for the report!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16201>
_______________________________________

From report at bugs.python.org  Sat Sep 14 14:18:17 2013
From: report at bugs.python.org (Drekin)
Date: Sat, 14 Sep 2013 12:18:17 +0000
Subject: [issue13758] compile() should not encode 'filename' (at least on
 Windows)
In-Reply-To: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>
Message-ID: <1379161097.67.0.93242224965.issue13758@psf.upfronthosting.co.za>


Drekin added the comment:

Since this issue was fixed, shouldn't it be marked fixed here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Sat Sep 14 14:50:05 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 14 Sep 2013 12:50:05 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <CADiSq7dLcoxhRLp5Fq8sVzdGPrz9YN=2eYJcwm8Gdathx8PvtA@mail.gmail.com>
Message-ID: <CAF-Rda8L205-rd3nMUVKWZMc21SoW-6DC1RUW=8WSOaU_nSHgw@mail.gmail.com>


Eli Bendersky added the comment:

On Fri, Sep 13, 2013 at 7:11 PM, Nick Coghlan <report at bugs.python.org>wrote:

>
> Nick Coghlan added the comment:
>
> +1 from me to just allow the names to be overwritten, even by another enum
> member.
>

Even though I was in favor of this in the initial discussions (obviously,
as I'm generally in favor of Enum being less magic and special) and had to
agree with the consensus, I think it's too late now - unless we want to
reopen the pandora box. Otherwise, it would not be fair, IMHO. In the
original discussions a lot of people gave their opinions and had the
context to chime in - now changing this "quietly" in the bug tracker with
only a handful of participants isn't appropriate.

The current behavior is fine, I think. The vast majority of enums will not
have methods, and some amount of safety against typos in member definitions
makes sense. Methods have other rules anyway (such as being definable in
subclasses), and since their uses are rarer and arguably more deliberate,
leaving them with more a Pythonic nature should be fine. This behavior is
documented in the PEP and documentation and is fairly well understood.
Also, we can always lift restrictions later without breaking existing code,
if it's deemed that some restrictions are too much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 15:19:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Sep 2013 13:19:41 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379164781.72.0.685612685291.issue18059@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

1) Expat itself responsible for this guard. It has all necessary information and provides an input of required size for custom converter.

2) Yes, this is a problem. I'm working on another approach, when full encoding table built at first request for the encoding (and than cache it). It makes decoding individual characters fast, but requires about 0.5 sec for initialization. Is such approach more suitable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Sat Sep 14 15:38:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 14 Sep 2013 13:38:15 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1379165895.01.0.477403705475.issue18709@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy:  -neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sat Sep 14 15:47:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 Sep 2013 13:47:09 +0000
Subject: [issue13758] compile() should not encode 'filename' (at least on
 Windows)
In-Reply-To: <1326253604.11.0.305060780894.issue13758@psf.upfronthosting.co.za>
Message-ID: <1379166429.57.0.295162028708.issue13758@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13758>
_______________________________________

From report at bugs.python.org  Sat Sep 14 16:18:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 14:18:12 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379168292.33.0.4773163445.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch adding the getitem() method.

----------
Added file: http://bugs.python.org/file31757/transformdict2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Sat Sep 14 16:18:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 14:18:54 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379168334.97.0.34977681154.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note: I haven't renamed transformdict to TransformDict yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Sat Sep 14 16:31:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 14:31:54 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379169114.23.0.524806840169.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I'd rather not propagate more options all the way through, especially 
> as this is some thing that should be decided by the test framework and 
> is unlikely to be something you want to turn on and off per test run
> (which is what command line options are for). Frameworks that want to 
> disable this behaviour should use a TestSuite that overrides
> _removeAtIndex.

That sounds like a completely disproportionate solution. Why would you have to override the TestSuite class just to change an option and restore old behaviour? Why don't you simply expose the cleanup flag on TestSuite instances?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Sep 14 16:32:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 14:32:46 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379169166.81.0.66013822164.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For the record, this change broke the --forever option in Tulip's test script, which is why I'm caring. Setting the _cleanup flag to False seems to restore old behaviour, except that _cleanup is (obviously) a private API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Sep 14 16:36:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 14:36:55 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379169415.4.0.236763282581.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note: ideally, the --forever flag wouldn't reuse TestCase instances but rather create new ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Sep 14 17:07:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Sep 2013 15:07:05 +0000
Subject: [issue18022] Inconsistency between quopri.decodestring() and
 email.quoprimime.decode()
In-Reply-To: <1369059208.07.0.0770184639372.issue18022@psf.upfronthosting.co.za>
Message-ID: <1379171225.24.0.710818955052.issue18022@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I said, not exactly any of the above.

I'll get back to this after I finish the new email code (which should happen before the end of the month).  I need to take some time to look over the RFCs and real world examples and come up with the most appropriate rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18022>
_______________________________________

From report at bugs.python.org  Sat Sep 14 17:25:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Sep 2013 15:25:22 +0000
Subject: [issue19012] liburl2: bad proxy configuration throws "getaddrinfo"
 error
In-Reply-To: <1379098642.08.0.213959473701.issue19012@psf.upfronthosting.co.za>
Message-ID: <1379172322.26.0.927021190649.issue19012@psf.upfronthosting.co.za>


R. David Murray added the comment:

The getaddrinfo error message should *not* refer to proxies, because getaddrinfo does not do anything involving proxy configuration.  

Presumably the error occurred when liburl2 tried to resolve the proxy.  So, it is liburl2 that needs to make sure that error is placed in a comprehensible context.  liburl2 is not an stdlib module.  You should report your problem to the liburl2 maintainers.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
versions: +3rd party -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19012>
_______________________________________

From report at bugs.python.org  Sat Sep 14 18:17:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Sep 2013 16:17:37 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379175457.54.0.358795821084.issue18989@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OK, rechecking PEP 435, I see that disallowing reuse of a name was indeed explicitly accepted as part of the defined API: http://www.python.org/dev/peps/pep-0435/#duplicating-enum-members-and-values

In that case, I switch my perspective to agree with Ethan that overwriting it with a method or descriptor should *also* be disallowed. The PEP is currently silent on that question, and as Ethan notes in the original post, the weird middle ground of the current behaviour is thoroughly confusing:

>>> class Disallowed(Enum):
...     a = 1
...     a = 2
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in Disallowed
  File "/home/ncoghlan/devel/py3k/Lib/enum.py", line 87, in __setitem__
    raise TypeError('Attempted to reuse key: %r' % key)
TypeError: Attempted to reuse key: 'a'


>>> class Allowed(Enum):
...     a = 1
...     @property
...     def a(self):
...         return 2
... 
>>> Allowed.a
<property object at 0x7f3d65da14d8>
>>> Allowed().a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __call__() missing 1 required positional argument: 'value'
>>> Allowed(1).a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/enum.py", line 218, in __call__
    return cls.__new__(cls, value)
  File "/home/ncoghlan/devel/py3k/Lib/enum.py", line 439, in __new__
    raise ValueError("%s is not a valid %s" % (value, cls.__name__))
ValueError: 1 is not a valid Allowed
>>> Allowed('a').a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/enum.py", line 218, in __call__
    return cls.__new__(cls, value)
  File "/home/ncoghlan/devel/py3k/Lib/enum.py", line 439, in __new__
    raise ValueError("%s is not a valid %s" % (value, cls.__name__))
ValueError: a is not a valid Allowed
>>> Allowed['a'].a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/enum.py", line 255, in __getitem__
    return cls._member_map_[name]
KeyError: 'a'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sat Sep 14 18:27:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 Sep 2013 16:27:29 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379157698.2498.5.camel@fsol>
Message-ID: <CAMpsgwZmYBuPfZh4Xvqntd4wGDfpu9ENSGnB8hVBjcofuHWCog@mail.gmail.com>


STINNER Victor added the comment:

Would it be possible to emit an event "invalid fd" with the fd? So the user
can decide what to do on such case: ignore, log, raise an exception, ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Sat Sep 14 19:15:19 2013
From: report at bugs.python.org (John Nagle)
Date: Sat, 14 Sep 2013 17:15:19 +0000
Subject: [issue18907] urllib2.open FTP open times out at 20 secs despite
 timeout parameter
In-Reply-To: <1378145931.18.0.826598432393.issue18907@psf.upfronthosting.co.za>
Message-ID: <1379178919.09.0.701878177992.issue18907@psf.upfronthosting.co.za>


John Nagle added the comment:

The server operator at the US Securities and Exchange Commission writes to me: "There was a DNS issue that affected the availability of FTP at night. We believe it is resolved. Please let us know if you encounter any further problems.  Thanks, SEC Webmaster".

So this may have been a DNS related issue, perhaps a load balancer referring the connection to a dead machine.  Yet, for some reason, the Windows command line FTP client can recover from this problem after 20 seconds? What are they doing right? Completely retrying the open?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18907>
_______________________________________

From report at bugs.python.org  Sat Sep 14 19:32:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Sep 2013 17:32:13 +0000
Subject: [issue18206] The license url in site.py should always use X.Y.Z form
 of version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <3ccgl031HQz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset 7c18b799841e by R David Murray in branch '3.3':
#18206: Fix test for existence of license URL.
http://hg.python.org/cpython/rev/7c18b799841e

New changeset 321c3c9cd1b5 by R David Murray in branch 'default':
Merge #18206: Fix test for existence of license URL.
http://hg.python.org/cpython/rev/321c3c9cd1b5

New changeset 9354325d2ee4 by R David Murray in branch 'default':
#18206: Re-fix license URL.
http://hg.python.org/cpython/rev/9354325d2ee4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep 14 19:38:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Sep 2013 17:38:39 +0000
Subject: [issue18206] The license url in site.py should always use X.Y.Z form
 of version number
In-Reply-To: <1371162560.09.0.685782864566.issue18206@psf.upfronthosting.co.za>
Message-ID: <1379180319.27.0.394173290456.issue18206@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are right, there was a further typo in the 3.4 URL that I missed.

Yes, requires_resource('network') is what I was referring to (though using transient_internet is also a very good idea :).  I also changed the urllib call to only do a HEAD request.  No need to rename the LICENSE file, I just pulled the info out of the data structure.  It's a white box test, but then so is parsing the "See" line at all, so I think it is acceptable.

(I wonder if it would be worthwhile to have transient_internet call requires_resource('network')?)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep 14 19:42:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 17:42:12 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1379180532.65.0.124062622205.issue18937@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

David told me he was in favour of keeping INFO the default, so I'll leave it like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18937>
_______________________________________

From report at bugs.python.org  Sat Sep 14 19:45:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Sep 2013 17:45:53 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <3cch2m6drqz7Lkw@mail.python.org>


Roundup Robot added the comment:

New changeset 4f5815747f58 by Antoine Pitrou in branch 'default':
Issue #18937: Add an assertLogs() context manager to unittest.TestCase to ensure that a block of code emits a message using the logging module.
http://hg.python.org/cpython/rev/4f5815747f58

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18937>
_______________________________________

From report at bugs.python.org  Sat Sep 14 19:46:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 17:46:29 +0000
Subject: [issue18937] add unittest assertion for logging
In-Reply-To: <1378412761.53.0.263834884699.issue18937@psf.upfronthosting.co.za>
Message-ID: <1379180789.39.0.381875118944.issue18937@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18937>
_______________________________________

From report at bugs.python.org  Sat Sep 14 20:00:15 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 14 Sep 2013 18:00:15 +0000
Subject: [issue18206] The license url in site.py should always use X.Y.Z form
 of version number
In-Reply-To: <1379180319.27.0.394173290456.issue18206@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT=CxAM7HGk_kzFOHRQqwZt7stDsqLUPKm6isKyKuU16Q@mail.gmail.com>


Senthil Kumaran added the comment:

Thanks for making these changes (and correcting some of my mistakes), RDM.
They are much better now.

On Sat, Sep 14, 2013 at 10:38 AM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray added the comment:
>
> You are right, there was a further typo in the 3.4 URL that I missed.
>
> Yes, requires_resource('network') is what I was referring to (though using
> transient_internet is also a very good idea :).  I also changed the urllib
> call to only do a HEAD request.  No need to rename the LICENSE file, I just
> pulled the info out of the data structure.  It's a white box test, but then
> so is parsing the "See" line at all, so I think it is acceptable.
>
> (I wonder if it would be worthwhile to have transient_internet call
> requires_resource('network')?)
>
> ----------
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18206>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18206>
_______________________________________

From report at bugs.python.org  Sat Sep 14 20:53:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Sep 2013 18:53:54 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379184834.24.0.196082110167.issue18059@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a totally rewritten patch, which builds decoding table at first request for encoding and save it in the cache. Decoding should be very fast.

Do you have large testing XML files with multibyte encodings? Could you please measure the time of parsing this files and for comparision the time of parsing this files encoded with utf-8 and utf-16?

----------
Added file: http://bugs.python.org/file31758/pyexpat_multibyte_encodings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Sat Sep 14 20:54:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Sep 2013 18:54:31 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379184871.42.0.850012905439.issue18059@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file31758/pyexpat_multibyte_encodings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Sat Sep 14 20:55:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Sep 2013 18:55:03 +0000
Subject: [issue18059] Add multibyte encoding support to pyexpat
In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za>
Message-ID: <1379184903.63.0.895941682834.issue18059@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31759/pyexpat_multibyte_encodings_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18059>
_______________________________________

From report at bugs.python.org  Sat Sep 14 21:16:38 2013
From: report at bugs.python.org (Artem Fokin)
Date: Sat, 14 Sep 2013 19:16:38 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
Message-ID: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>


New submission from Artem Fokin:

Suppose we have the following code:

    from heapq import merge

    def iterable():
        lst = range(10)
        for i in xrange(20):
            yield lst[i]
        
    it1, it2= iterable(), iterable()

    print list(merge(it1, it2)) # no IndexError
    #output is: [0, 0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6, 7, 7, 8, 8, 9]


The reason is that in heapq.merge http://hg.python.org/cpython/file/7c18b799841e/Lib/heapq.py#l372 try-catch clause for IndexError is too broad

    while 1:
        try:
            while 1:
                v, itnum, next = s = h[0]   # raises IndexError when h is empty
                yield v
                s[0] = next()               # raises StopIteration when exhausted, 
                _heapreplace(h, s)          # restore heap condition
        except _StopIteration:
            _heappop(h)                     # remove empty iterator
        except IndexError:
            return

s[0] = next() also may raise different kinds of exceptions including IndexError which will be silently suppressed. 
For example, this loop can be rewritten as

    while 1:
        try:
            while 1:
                try:
                    v, itnum, next = s = h[0]   # raises IndexError when h is empty
                except IndexError:
                    return
                yield v
                s[0] = next()               # raises StopIteration when exhausted, 
                _heapreplace(h, s)          # restore heap condition
        except _StopIteration:
            _heappop(h)                     # remove empty iterator

----------
components: Library (Lib)
messages: 197726
nosy: afn
priority: normal
severity: normal
status: open
title: Heapq.merge suppreses IndexError from user generator
type: behavior
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 21:21:22 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 14 Sep 2013 19:21:22 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <1379186482.11.0.829587505804.issue18945@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't object to adding the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Sat Sep 14 21:31:53 2013
From: report at bugs.python.org (Artem Fokin)
Date: Sat, 14 Sep 2013 19:31:53 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379187113.07.0.343766402234.issue19018@psf.upfronthosting.co.za>


Changes by Artem Fokin <ar.fokin at gmail.com>:


----------
versions:  -3rd party, Python 2.6, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 21:36:40 2013
From: report at bugs.python.org (Artem Fokin)
Date: Sat, 14 Sep 2013 19:36:40 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379187400.82.0.0941169125435.issue19018@psf.upfronthosting.co.za>


Artem Fokin added the comment:

Oh, it seems that in current cpython branch this problem is fixed by checking condition _len(h) > 1:
http://hg.python.org/cpython/file/1dc925ee441a/Lib/heapq.py#l373
But is it possible to fix it for the previous branches?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 22:05:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 20:05:16 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379189116.32.0.386269203389.issue19018@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 22:31:13 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Sep 2013 20:31:13 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
Message-ID: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>


New submission from Ned Deily:

On the python-dev mailing list, Raymond Hettinger asks:
> I was exercising the alpha two release of 3.4 and noticed that
> it is still being built under GCC 4.2.1.  
> 
> Is there any reason we have to use an old compiler?

Yes, kinda.  It's because the 64-bit/32-bit installer we supply is designed to run on multiple versions of OS X: 10.6 (Snow Leopard), 10.7, 10.8, and the upcoming 10.9.  The safest way to ensure that the bits produced (executables, shared libs, and .so bundles) are linked with compatible versions of system shared libraries and frameworks is to build on the lowest supported system, 10.6, or - carefully - with a 10.6 SDK on a newer system.  The standard compiler in the Apple Developer Tools for 10.6 is gcc 4.2.  The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK.  Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries.  We have been burned by that in the past.

> I would like to see it built under the latest version of Clang
> (like the other tools on the Mac) or under GCC 4.8.1.
> I've better using the latter for many months.  It works great
> and produces *much* better code (in terms of readability
> for those of us who look at assembly output and in terms
> of speed (approx 20-25% better for cpu bound code)).
> 
> I'm wondering whether is some issue that forces us to use
> GCC 4.2.1 or whether that is just an artifact of continuing
> to do what we've always been doing.

I'd like to move to Apple's latest clang, as well.  (Apple is dropping gcc totally from the next release of Xcode.)  There are a couple of approaches that may work and still reliably support multiple versions of OS X.  Investigating this is on my list of things to do prior to the next alpha.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 197729
nosy: ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Investigate using Apple clang for building OS X installers
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Sat Sep 14 22:41:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Sep 2013 20:41:19 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379191279.38.0.417278465838.issue19018@psf.upfronthosting.co.za>


R. David Murray added the comment:

It was checked in as an optimization, but if it fixes a bug I don't see why it couldn't be backported.  A unit test would be helpful, if you feel like writing one.

----------
nosy: +r.david.murray
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 22:47:44 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Sep 2013 20:47:44 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379191664.13.0.116730663524.issue19018@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This seems like a good reason for a backport.

Add a unittest and I'll take care of the rest.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 23:14:52 2013
From: report at bugs.python.org (Artem Fokin)
Date: Sat, 14 Sep 2013 21:14:52 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379193292.96.0.0413574791809.issue19018@psf.upfronthosting.co.za>


Artem Fokin added the comment:

Which branch should I add a unit-test to?
Here is a patch that adds a unit-test to the current one.

----------
keywords: +patch
Added file: http://bugs.python.org/file31760/unittest_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sat Sep 14 23:35:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 21:35:24 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379194524.18.0.0395295839087.issue18986@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Uploading new patch with added transform_func property.

----------
Added file: http://bugs.python.org/file31761/transformdict3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Sun Sep 15 00:03:19 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 14 Sep 2013 22:03:19 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379196199.19.0.448737557989.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

Can that be fixed in tulip?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sun Sep 15 00:07:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Sep 2013 22:07:04 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379196424.2.0.575553073189.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, but that's not the point. Legitimate use cases can be broken by the change, so at least there should be an easy way to disable the new behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sun Sep 15 00:11:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Sep 2013 22:11:22 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
Message-ID: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Current 3.3.2+ repository build (32 bit) and 3.4.0a2 repository build (32 bit) and installation (64 bit) have a problem that did not exist in my Win6 3.3.2 installation (64 bit). (Bruce Sherwood discovered the symption with some installed version of 3.4.0a?) Adding to recent files a path with a directory or file whose name begins with '0' causes Idle to stop with a traceback such as given below. Currently, opening *any* file causes the recent files list to be rebuilt (seen in traceback). So the problem happens whether one opens a new file with a leading 0 somewhere or if there merely is one such already on the list.

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python34\lib\tkinter\__init__.py", line 1475, in __call__
    return self.func(*args)
  File "C:\Python34\lib\idlelib\IOBinding.py", line 179, in open
    flist.open(filename, self.loadfile)
  File "C:\Python34\lib\idlelib\FileList.py", line 34, in open
    return action(filename)
  File "C:\Python34\lib\idlelib\IOBinding.py", line 240, in loadfile
    self.updaterecentfileslist(filename)
  File "C:\Python34\lib\idlelib\IOBinding.py", line 521, in updaterecentfileslist
    self.editwin.update_recent_files_list(filename)
  File "C:\Python34\lib\idlelib\EditorWindow.py", line 915, in update_recent_files_list
    menu.delete(0, END)  # clear, and rebuild:
  File "C:\Python34\lib\tkinter\__init__.py", line 2739, in delete
    if 'command' in self.entryconfig(i):
  File "C:\Python34\lib\tkinter\__init__.py", line 2749, in entryconfigure
    return self._configure(('entryconfigure', index), cnf, kw)
  File "C:\Python34\lib\tkinter\__init__.py", line 1247, in _configure
    self.tk.call(_flatten((self._w, cmd)))):
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc0 in position 14: invalid start byte

'invalid start byte' 0xc0 has appeared before in other issues.

Bruce got this with
  H:\HP_Documents\0PythonWork\AirplaneKinematics\accel2.py
I get 12' instead of '14' with
  F:\Python\mypy\0...' (file or directory, must be 0, not 1)
It appears that the string is being improperly 're-cooked' at some point, so that '\x' sequences are 1 position rather than 2.

At the point of failure, I believe tk is checking whether a particular menuitem has an associated callback that should be deleted before the menuitem itself is deleted (before later being rebuilt). (It is a separate issue of whether we could just adjust the recent file list (sub sub menu) rather than deleting and rebuilding it, possibly the same as it was. Even if we did, the issue would still arise when opening a new '0' file, or when closing Idle.)

----------
messages: 197736
nosy: bsherwood, ezio.melotti, haypo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Regression: Windows-tkinter-idle, unicode, and 0xxx filename
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Sun Sep 15 00:28:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Sep 2013 22:28:22 +0000
Subject: [issue6699] IDLE: Warn user about overwriting a file that has a newer
 version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1379197702.07.0.639553334794.issue6699@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bsherwood

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6699>
_______________________________________

From report at bugs.python.org  Sun Sep 15 01:46:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Sep 2013 23:46:46 +0000
Subject: [issue19021] AttributeError in Popen.__del__
Message-ID: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Sometimes closing IDLE I got such exception:

Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0xb5b8618c>>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/subprocess.py", line 890, in __del__
TypeError: 'NoneType' object is not callable

It is happened because the builtins module was destroyed before running __del__ in process of garbage collecting.

Here is a patch which should fix the bug. Anothe possible solution is get rid from getattr and catch AttributeError instead.

See also issue16650.

----------
components: Library (Lib)
files: subprocess_del_getattr.patch
keywords: patch
messages: 197737
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: AttributeError in Popen.__del__
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31762/subprocess_del_getattr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Sun Sep 15 02:15:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 00:15:16 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1379204116.11.0.815570929598.issue19020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps this is caused by issue18101.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Sun Sep 15 03:07:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 01:07:28 +0000
Subject: [issue18856] Added test coverage for calendar print functions
In-Reply-To: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>
Message-ID: <3ccsrH0D5nz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 442e23bbec48 by Ezio Melotti in branch '3.3':
#18856: improve test coverage of the calendar module.  Patch by Madison May.
http://hg.python.org/cpython/rev/442e23bbec48

New changeset 81da2ed0c563 by Ezio Melotti in branch 'default':
#18856: merge with 3.3.
http://hg.python.org/cpython/rev/81da2ed0c563

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18856>
_______________________________________

From report at bugs.python.org  Sun Sep 15 03:08:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Sep 2013 01:08:13 +0000
Subject: [issue18856] Added test coverage for calendar print functions
In-Reply-To: <1377631161.77.0.572665348858.issue18856@psf.upfronthosting.co.za>
Message-ID: <1379207293.54.0.556838989606.issue18856@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18856>
_______________________________________

From report at bugs.python.org  Sun Sep 15 03:15:04 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 01:15:04 +0000
Subject: [issue18995] Enum does not work with reversed
In-Reply-To: <1378804463.14.0.741296151335.issue18995@psf.upfronthosting.co.za>
Message-ID: <1379207704.72.0.59701646806.issue18995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Well, I totally messed up the commit message, but the code is now in place.  Thanks, Vajrasky Kok!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18995>
_______________________________________

From report at bugs.python.org  Sun Sep 15 03:53:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 01:53:45 +0000
Subject: [issue18929] inspect.classify_class_attrs ignores metaclass
In-Reply-To: <1378349462.72.0.930877473496.issue18929@psf.upfronthosting.co.za>
Message-ID: <3cctsh66JZz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset b0517bb271ad by Ethan Furman in branch 'default':
Close #18929: inspect.classify_class_attrs will now search the metaclasses (last) to find where an attr was defined.
http://hg.python.org/cpython/rev/b0517bb271ad

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18929>
_______________________________________

From report at bugs.python.org  Sun Sep 15 04:39:00 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 02:39:00 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1379212740.53.0.260169040086.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, here's the patch after the inspect portion was committed in #18929.

Summary:
  - added __objclass__ to each enum member
  - added __module__ to the class dir
  - aded any extra methods defined to the instance dir
  - changed _RouteClassAttributeToGetattr to use the wrapped doc if it exists
  - added more useful __doc__s to value and name
  - added another test :)

----------
resolution: fixed -> 
Added file: http://bugs.python.org/file31763/issue18693.stoneleaf.02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Sun Sep 15 05:53:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 03:53:11 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <3ccxWV3q4lz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 0ff5bb61c6a1 by Raymond Hettinger in branch '3.3':
Issue #19018: The heapq.merge() function no longer suppresses IndexError
http://hg.python.org/cpython/rev/0ff5bb61c6a1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sun Sep 15 05:59:06 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Sun, 15 Sep 2013 03:59:06 +0000
Subject: [issue18958] Exception('No JSON object could be decoded') when
 parsing a valid JSON
In-Reply-To: <1378557195.07.0.581794298686.issue18958@psf.upfronthosting.co.za>
Message-ID: <1379217546.54.0.380283164126.issue18958@psf.upfronthosting.co.za>


Anoop Thomas Mathew added the comment:

Patch for BOM signature documentation in json.loads

----------
keywords: +patch
nosy: +Anoop.Thomas.Mathew
Added file: http://bugs.python.org/file31764/json_BOM_signature_documentation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18958>
_______________________________________

From report at bugs.python.org  Sun Sep 15 06:20:15 2013
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 Sep 2013 04:20:15 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1379218815.93.0.773092504995.issue11344@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sun Sep 15 06:22:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 04:22:03 +0000
Subject: [issue16650] Popen._internal_poll() references errno.ECHILD outside
 of the local scope
In-Reply-To: <1355036600.83.0.376355184043.issue16650@psf.upfronthosting.co.za>
Message-ID: <1379218923.2.0.852223220778.issue16650@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16650>
_______________________________________

From report at bugs.python.org  Sun Sep 15 06:22:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 04:22:47 +0000
Subject: [issue16650] Popen._internal_poll() references errno.ECHILD outside
 of the local scope
In-Reply-To: <1355036600.83.0.376355184043.issue16650@psf.upfronthosting.co.za>
Message-ID: <1379218967.04.0.0132981227756.issue16650@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

sorry for noise

----------
nosy: +terry.reedy
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16650>
_______________________________________

From report at bugs.python.org  Sun Sep 15 06:30:23 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 04:30:23 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1379219423.35.0.203232988771.issue19021@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Sun Sep 15 07:17:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 05:17:50 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <3cczP94wJbz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 56a3c0bc4634 by Raymond Hettinger in branch '2.7':
Issue #19018: The heapq.merge() function no longer suppresses IndexError
http://hg.python.org/cpython/rev/56a3c0bc4634

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sun Sep 15 07:30:36 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Sep 2013 05:30:36 +0000
Subject: [issue19018] Heapq.merge suppreses IndexError from user generator
In-Reply-To: <1379186198.08.0.186322749234.issue19018@psf.upfronthosting.co.za>
Message-ID: <1379223036.63.0.571016140601.issue19018@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19018>
_______________________________________

From report at bugs.python.org  Sun Sep 15 07:30:39 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 05:30:39 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379223039.45.0.44528749715.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think this patch is a false solution and should be reverted. Oleg should have been told to use sys.version to make the correct call. Given how Python is, that is the correct solution to his problem.

The result of this patch is #19021: an AttributeError on shutdown when getattr gets cleared before the Popen instance.

The problem of Python putting out an uncatchable error message when deleting an uninitialized instance is generic and not specific to Popen.

class C():
    def __init__(self): self.a = 1
    def __del__(self): self.a

try:
    C(1)
except (TypeError, AttributeError): pass

# prints
Exception AttributeError: "'C' object has no attribute 'a'" in <bound method C.__del__ of <__main__.C object at 0x00000000033FB128>> ignored

If there is to be any change, it should be as generic as the problem. Perhaps that message should simply be eliminated. Perhaps it should be a Warning, which could be blocked. Perhaps there should be a real AttributeError chained with the TypeError.


What we should not do and should not tell people to do is add at least one getattr call to every __del__ method.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 15 07:47:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 05:47:37 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379224057.66.0.186219517077.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The same issue arises when an exception is raised during the __init__ execution, rather than in the call argument match phase, and the exception is caught.

class C():
    def __init__(self): self.a = self.b
    def __del__(self): self.a

try:
    C()
except AttributeError): pass
# print same message as before about self.a in __del__

What is different is that if the exception raised within __init__ is not caught, only the normal traceback is printed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 15 07:50:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 05:50:10 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1379224210.31.0.497426419236.issue19021@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The condition was changed from self._child_created to the getattr call in #12085. As explained in msg197748, I think that change should be reverted (and this issue closed). I think elaborating a bad patch only makes it worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Sun Sep 15 08:20:35 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 15 Sep 2013 06:20:35 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1379226035.05.0.758795924361.issue1602@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Hi Drekin. Thanks for your work in progressing this issue. There have been a variety of techniques proposed for this issue, but it sounds like yours has built on what the others learned, and is close to complete, together with issue 17620.

Is this in a form that can be used with Python 3.3? or 3.4 alpha? Can it be loaded externally from a script, or must it be compiled into Python, or both?

I've been using a variant of davidsarah's patch since 2 years now, but would like to take yours out for a spin. Is there a Complete Idiot's guide to using your patch? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Sep 15 08:32:11 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 06:32:11 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1379226731.19.0.758599116607.issue1602@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From reading the module,
  import stream; stream.enable()
replaces sys.stdin/out/err with new classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Sep 15 09:06:21 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 Sep 2013 07:06:21 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>
Message-ID: <1379228781.66.0.248898457185.issue14927@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I would propose a leading underscore for these methods; they should make it clear to the user that the parameter is meant to be "private".

With this line in the docstring, I would wonder "Why is the argument there in the first place?!" (because most people don't know about the optimization technique).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Sun Sep 15 09:21:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 07:21:32 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379229692.0.0.026746455087.issue12085@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As Victor suggested in msg136939 we can use a class attribute. This technique is used in some other places in the stdlib (perhaps for other purposes). For example in subprocess.Handle.

We should check all defined __del__-s in stdlib and fix them all if they use a instance attribute created in __init__.

----------
nosy: +serhiy.storchaka
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 15 09:33:28 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Sep 2013 07:33:28 +0000
Subject: [issue19022] Improve handling of type.__abstractmethods__ descriptor
Message-ID: <1379230408.43.0.525404043988.issue19022@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 10006 pointed out that attempting to access object.__abstractmethods__ raises AttributeError. The solution was to ensure type.__abstractmethods__ *also* raises AttributeError.

This is thoroughly confusing, since the name is clearly visible in the output of dir(type). While it's technically legal for a descriptor to always raise AttributeError, breaking the following typical assumed invariant is *highly* dubious:

    all(hasattr(obj, x) for x in dir(obj))

I see three main alternatives for improving the situation:

1. Make __abstractmethods__ a read-only descriptor that returns something meaningful (like a frozenset(), the same as you get if you inherit from abc.ABCMeta without defining any abstract methods)

2. Throw a better exception message that explains the broken invariant rather than the generic "AttributeError with attribute name" that is currently thrown.

3. Implement type.__dir__ to filter out the uncooperative descriptor

----------
messages: 197755
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve handling of type.__abstractmethods__ descriptor
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19022>
_______________________________________

From report at bugs.python.org  Sun Sep 15 09:34:19 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Sep 2013 07:34:19 +0000
Subject: [issue19022] Improve handling of type.__abstractmethods__ descriptor
In-Reply-To: <1379230408.43.0.525404043988.issue19022@psf.upfronthosting.co.za>
Message-ID: <1379230459.98.0.903121665366.issue19022@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +Yaroslav.Halchenko, benjamin.peterson, daniel.urban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19022>
_______________________________________

From report at bugs.python.org  Sun Sep 15 10:47:28 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 15 Sep 2013 08:47:28 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
In-Reply-To: <1379109989.8.0.180903091474.issue18994@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2EsdgzpxfGiy4WqyhH9WXCqPM85=5kRcFq_OL64VQU=w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I noticed this when converting the code to use PyModule_AddIntMacro().

Vajrasky, did you see Ezio's review on
http://bugs.python.org/review/18994/#ps9258 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18994>
_______________________________________

From report at bugs.python.org  Sun Sep 15 11:06:36 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Sep 2013 09:06:36 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
In-Reply-To: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>
Message-ID: <1379235996.43.0.984192675751.issue18994@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Charles-Fran?ois Natali, sorry I just noticed Ezio's comment. The all_ins function return -1 on failure and 0 on success.

I use this form:

    if (all_ins(m))
        return NULL;

because I follow the example in Modules/posixmodule.c. If this form:
    
    if (all_ins(m) < 0)
        return NULL;
    
is better, then so be it, here is the patch to accommodate Ezio's suggestion.

----------
Added file: http://bugs.python.org/file31765/check_return_code_all_ins_in_fcntl_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18994>
_______________________________________

From report at bugs.python.org  Sun Sep 15 11:24:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 09:24:17 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1379237057.84.0.607640381987.issue19020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are two methods: splitlist() and split(). The splitlist() method splits only one level and always returns a tuple (even if it is empty or one-element). The split() method splits recursive and can returns a string if it is not splittable. I.e. result type of split() depends on if the argument contains spaces.

Before issue18101 split() was broken on Python 3. It splitted recursively only bytes objects but not unicode strings. After "fixing" it becomes split already parsed tuples of strings.

Perhaps split() shouldn't recursive parse tuples. But in this case its purpose is questionable. Recursive parse only string argument? But how it can distinguish the list of two strings "a" and "b c" from the list of the "a" string and the ["b", "c"] list? Both are spelled as {a {b c}} in Tcl.

The proposed patch gets rid from split() in the configure result parsing code and uses two-level splitline() instead. Perhaps we should replace all left split()-s to the appropriate number of splitline()-s.

----------
assignee:  -> serhiy.storchaka
components: +IDLE, Tkinter
keywords: +patch
nosy: +gpolo
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31766/tkinter_configure_splitlist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Sun Sep 15 11:55:52 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Sep 2013 09:55:52 +0000
Subject: [issue19014] Allow memoryview.cast() for empty views
In-Reply-To: <1379105549.83.0.888503022363.issue19014@psf.upfronthosting.co.za>
Message-ID: <1379238952.43.0.66921961775.issue19014@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I agree that this cast should work. Perhaps disallowing zero strides
is enough -- I have to look at this more closely though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19014>
_______________________________________

From report at bugs.python.org  Sun Sep 15 11:57:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 09:57:04 +0000
Subject: [issue18950] Miscellaneous fixes for the sunau module
In-Reply-To: <1378502694.18.0.563332968903.issue18950@psf.upfronthosting.co.za>
Message-ID: <1379239024.42.0.252026180613.issue18950@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Update patch addresses Ezio's comment.

----------
Added file: http://bugs.python.org/file31767/sunau.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18950>
_______________________________________

From report at bugs.python.org  Sun Sep 15 12:53:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 10:53:19 +0000
Subject: [issue18877] tkinter askopenfilenames does not work in Windows
 library folder
In-Reply-To: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>
Message-ID: <1379242399.97.0.672191226131.issue18877@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I guess tkinter.wantobjects is 0 for you?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18877>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:00:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 11:00:43 +0000
Subject: [issue18877] tkinter askopenfilenames does not work in Windows
 library folder
In-Reply-To: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>
Message-ID: <1379242843.47.0.235193123155.issue18877@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This patch should fix the issue (as many other issues).

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.4
Added file: http://bugs.python.org/file31768/tkinter_Tkapp_CallResult.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18877>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:03:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 11:03:03 +0000
Subject: [issue3405] Add support for the new data option supported by event
 generate (Tk 8.5)
In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za>
Message-ID: <1379242983.11.0.221421974513.issue3405@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3405>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:07:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 11:07:09 +0000
Subject: [issue6181] Tkinter.Listbox several minor issues
In-Reply-To: <1243977899.25.0.845872446641.issue6181@psf.upfronthosting.co.za>
Message-ID: <1379243229.59.0.464222866445.issue6181@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6181>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:18:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 11:18:33 +0000
Subject: [issue13519] Tkinter rowconfigure and columnconfigure functions crash
 if minsize, pad, or weight is not None
In-Reply-To: <1322817071.4.0.270134570046.issue13519@psf.upfronthosting.co.za>
Message-ID: <1379243913.03.0.418935540224.issue13519@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this was fixed in issue16809.

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13519>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:22:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 11:22:29 +0000
Subject: [issue18141] tkinter.Image.__del__ can throw an exception if module
 globals are destroyed in the wrong order
In-Reply-To: <1370434176.62.0.932474289882.issue18141@psf.upfronthosting.co.za>
Message-ID: <1379244149.45.0.147751721836.issue18141@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +gpolo, serhiy.storchaka, terry.reedy
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18141>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:37:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 11:37:43 +0000
Subject: [issue12558] Locale-dependent exception for float width argument to
 Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1379245063.91.0.809746091643.issue12558@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:57:50 2013
From: report at bugs.python.org (Sye van der Veen)
Date: Sun, 15 Sep 2013 11:57:50 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
Message-ID: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>


New submission from Sye van der Veen:

In the ctypes documentation, there's mention of a BigEndianUnion/LittleEndianUnion that isn't actually implemented, and the "Arrays and pointers" section just reads "Not yet written".

The attached patch adds the (Big|Little)EndianUnion classes (with tests), finishes the Array/_Pointer class docs (and adds missing cases to the tests), and makes some stylistic improvements to docs.

The patch was made against default, but it's quite likely it could be back-ported all the way to Python 3.1.

----------
assignee: docs at python
components: Documentation, Tests, ctypes
hgrepos: 209
messages: 197764
nosy: docs at python, syeberman
priority: normal
severity: normal
status: open
title: ctypes docs: Unimplemented and undocumented features
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Sun Sep 15 13:58:47 2013
From: report at bugs.python.org (Sye van der Veen)
Date: Sun, 15 Sep 2013 11:58:47 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1379246327.2.0.652619819316.issue19023@psf.upfronthosting.co.za>


Changes by Sye van der Veen <syeberman at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31769/75843d82f6cf.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Sun Sep 15 14:41:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 12:41:15 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
 tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1379248875.64.0.565565023543.issue5712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is it still reproducible on 2.7?

----------
nosy: +serhiy.storchaka
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Sun Sep 15 14:41:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 12:41:29 +0000
Subject: [issue12558] Locale-dependent exception for float width argument to
 Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1379248889.28.0.457222941285.issue12558@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a bug in Tk. It uses locale-agnostic Tcl_GetDoubleFromObj() in most places, but in some places (especially in canvas) it uses locale-dependent strtod(). And that is even worse, strtod() is used even for parsing comma-delimited floats (@-indices).

We can't fix it from Python side (except perhaps switching to C locale for every Tcl/Tk operation). But in desires a warning in the documentation.

----------
components: +Documentation
stage:  -> needs patch
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Sun Sep 15 14:52:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 12:52:14 +0000
Subject: [issue3015] tkinter with wantobjects=False has been broken for some
 time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <1379249534.23.0.557907978394.issue3015@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as issue18877 is related to this. I have proposed for it a little different patch than first Guilherme's patch.

As for removing wantobjects, we perhaps can do this only in 3.4.

----------
nosy: +serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________

From report at bugs.python.org  Sun Sep 15 14:53:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 12:53:21 +0000
Subject: [issue18877] tkinter askopenfilenames does not work in Windows
 library folder
In-Reply-To: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>
Message-ID: <1379249601.6.0.189260893493.issue18877@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also #3015 and #5712.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18877>
_______________________________________

From report at bugs.python.org  Sun Sep 15 14:56:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 12:56:21 +0000
Subject: [issue6225] Fixing several minor bugs in Tkinter.Canvas and one in
 Misc._configure
In-Reply-To: <1244325396.24.0.788727463424.issue6225@psf.upfronthosting.co.za>
Message-ID: <1379249781.41.0.446197047532.issue6225@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also #19020.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6225>
_______________________________________

From report at bugs.python.org  Sun Sep 15 15:02:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 13:02:03 +0000
Subject: [issue1602742] itemconfigure returns incorrect text property of text
 items
Message-ID: <1379250123.49.0.0962119947811.issue1602742@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch for issue19020 fixes this issue.

----------
nosy: +serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602742>
_______________________________________

From report at bugs.python.org  Sun Sep 15 15:16:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 13:16:46 +0000
Subject: [issue8010] tkFileDialog.askopenfiles crashes on Windows 7
In-Reply-To: <1267005125.4.0.826921627128.issue8010@psf.upfronthosting.co.za>
Message-ID: <1379251006.52.0.245835798549.issue8010@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as a duplicate of issue5712.

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8010>
_______________________________________

From report at bugs.python.org  Sun Sep 15 15:18:38 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 13:18:38 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
Message-ID: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I'd say this is a critical documentation bug that leads to head bang when you try to figure out what does '*' in code means.

This bug is two fold:
1. Define a dedicated place in documentation for '*' operator with examples. I propose http://docs.python.org/3/library/stdtypes.html chapter with a name like "Special Operations" or "Function Argument Operations" or "Function Argument Operators"
 
2. Make '*', 'asterisk', 'splat', 'star' operator searchable
http://docs.python.org/3/search.html?q=*
http://docs.python.org/3/search.html?q=asterisk
http://docs.python.org/3/search.html?q=splat
http://docs.python.org/3/search.html?q=star+operator

Good?

References:
http://stackoverflow.com/questions/2322355/proper-name-for-python-operator
http://stackoverflow.com/questions/5239856/foggy-on-asterisk-in-python
http://stackoverflow.com/questions/2921847/python-once-and-for-all-what-does-the-star-operator-mean-in-python
http://stackoverflow.com/questions/287085/what-do-args-and-kwargs-mean
http://stackoverflow.com/search?q=[python]+%2Bkwargs+is%3Aquestion

----------
assignee: docs at python
components: Documentation
messages: 197772
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Document asterisk (*), splat or star operator
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 15 15:26:32 2013
From: report at bugs.python.org (Drekin)
Date: Sun, 15 Sep 2013 13:26:32 +0000
Subject: [issue1602] windows console doesn't print or input Unicode
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1379251592.53.0.897085526883.issue1602@psf.upfronthosting.co.za>


Drekin added the comment:

Glenn Linderman: Yes I have built on what the others learned. For your question, I made it and tested it in Python 3.3, it should also work in 3.4 and what I've tried, it actually works. As Terry J. Reedy says you can just load the module and enable the streams. I do this automatically on startup using sitecustomize. However as I said currently this meeses up the interactive session because of http://bugs.python.org/issue17620 . I have made some workaround ? custom REPL built on stdlib module code. And also a helper script which runs the main script and then runs the custom REPL (I couldn't find any stadard hook which would run the custom REPL). I'm uploding full code. I will delete it if this isn't appropriate place.

Things like this could be fixed more easily if more core interpreter logic took place in stdlib. E. g. the code for interactive REPL. Few days ago I started some discussion on python ideas: https://mail.python.org/pipermail/python-ideas/2013-August/023000.html .

----------
Added file: http://bugs.python.org/file31770/win_unicode_console.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Sun Sep 15 15:50:20 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 13:50:20 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379253020.85.0.728933157407.issue19024@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

tag:easy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 15 15:58:17 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 15 Sep 2013 13:58:17 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379253497.3.0.00235214918947.issue19024@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type: crash -> enhancement
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:15:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Sep 2013 15:15:10 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
Message-ID: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> from enum import Enum
>>> class MyPet(Enum):
...   CUTE_CAT = 1
...   VIGOROUS_DOG = 2
...   UGLY_BLOBFISH = 3
...   PROMISCUOUS_BONOBO = 4
...   def spam(cls): pass
... 
>>> del MyPet.CUTE_CAT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: CUTE_CAT

This is misleading. I have CUTE_CAT attribute in Enum. It should throw TypeError exception.

>>> del MyPet.LONELY_WOLF
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: LONELY_WOLF

This is correct.

>>> del MyPet['CUTE_CAT']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'EnumMeta' object does not support item deletion

I think this behaviour is correct.

>>> del MyPet['LONELY_WOLF']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'EnumMeta' object does not support item deletion

This behaviour is somewhat misleading. I don't have LONELY_WOLF item.

>>> del MyPet.spam
>>> hasattr(MyPet, 'spam')
False

This is correct. We should be able to delete method from Enum class, or shouldn't we?

>>> cute_cat = MyPet.CUTE_CAT
>>> del cute_cat.name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sky/Code/python/programming_language/cpython/Lib/enum.py", line 29, in __delete__
    raise AttributeError("can't delete attribute")
AttributeError: can't delete attribute

This is *maybe" correct. But shouldn't it be TypeError exception?

All the exception messages related with deleting attribute in Python codebase are using TypeError exception (with one exception in pyexpat on which it uses RuntimeError exception).

Attached the patch to handle the attribute deletion correctly.

For now, I don't change the exception for the last case (del MyPet.CUTE_CAT.name) because maybe there is an exception case for enum.

----------
components: Library (Lib)
files: handling_attribute_deletion_correctly_in_enum.patch
keywords: patch
messages: 197775
nosy: ethan.furman, vajrasky
priority: normal
severity: normal
status: open
title: Deleting attribute of Enum gives misleading error message
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31771/handling_attribute_deletion_correctly_in_enum.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:15:12 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 15:15:12 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1379258112.07.0.884217559616.issue1565525@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Ping!  I'd like to change the function name to clear_frames() and then commit this.  Antoine or anyone, want to disagree with using clear_frames() as the name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:17:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Sep 2013 15:17:38 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
In-Reply-To: <1379258112.07.0.884217559616.issue1565525@psf.upfronthosting.co.za>
Message-ID: <1379258255.2525.0.camel@fsol>


Antoine Pitrou added the comment:

> Ping!  I'd like to change the function name to clear_frames() and then
> commit this.  Antoine or anyone, want to disagree with using
> clear_frames() as the name?

clear_frames() sounds fine to me :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:43:44 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Sun, 15 Sep 2013 15:43:44 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1379259824.86.0.143571757485.issue18704@psf.upfronthosting.co.za>


R. Jayakrishnan added the comment:

Thanks for showing great interest on this idea.
As usual, it seems this will going to be another nice project with IDLE for me. Better to close this issue then, and create an appropriate initiation with the suggested points(preferring a commencement by core developers).
 
Anyway to keep in touch with the Python analyzing and related tools, I have initiated a separate project with porting the works done on the patch here https://github.com/Jay-Krish/IDLEAnalyzer.
I Hope this will help further while working on this project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:45:15 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 15:45:15 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1379259915.58.0.101757346318.issue16043@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:53:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 15:53:55 +0000
Subject: [issue17104] Tk() not defined in Tkinter module
In-Reply-To: <1359797316.8.0.0796335939383.issue17104@psf.upfronthosting.co.za>
Message-ID: <1379260435.84.0.702174194315.issue17104@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Tkinter -None
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17104>
_______________________________________

From report at bugs.python.org  Sun Sep 15 17:59:42 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 15:59:42 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379260782.64.0.16087969044.issue16042@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The patch requires a little adjusting to apply against 2.6.

----------
nosy: +akuchling
Added file: http://bugs.python.org/file31772/smtplib-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:03:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 16:03:50 +0000
Subject: [issue15363] Idle/tkinter ~x.py 'save as' fails. closes idle
In-Reply-To: <1342394243.7.0.336788716257.issue15363@psf.upfronthosting.co.za>
Message-ID: <1379261030.53.0.554506029128.issue15363@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Tkinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15363>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:04:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 16:04:30 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379261070.36.0.0637568882225.issue19025@psf.upfronthosting.co.za>


R. David Murray added the comment:

Doesn't this confusion (here and in 19011) arise from the fact that the enum class does *not* have CUTE_CAT attribute?  That is, the error message is correct, but surprising.  Because, frankly, Enums are surprising in many ways ;)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:21:49 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 16:21:49 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1379262109.22.0.732962172847.issue16040@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Any more thoughts on this bug w.r.t. 2.6.9?  It seems that without a patch for any version of Python, and with 2.6.9 coming soon, a fix for this just won't make it into 2.6.9.  

That doesn't bother me too much, and I'm willing to just knock this off the 2.6.9 radar unless objections (accompanied by patches? :) are raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:28:00 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 16:28:00 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379262480.34.0.473960114717.issue19025@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:31:57 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 16:31:57 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379262717.28.0.135464945849.issue16042@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Here's a final proposed version of the patch for 2.6 that adds a test.  Changes made:

* code now raises SMTPResponseException instead of a new SMTPLineTooLong exception; bwarsaw deemed that adding a new exception class was changing the module API.

* we looked at Serhiy's suggestion to move the length check into the 'while' loop's condition and decided not to -- the code is more obvious with the separate if/break.

* the test class is a cut-and-paste and slight modification of the BadHELOServerTests class; I didn't try to unify them in some way.

----------
Added file: http://bugs.python.org/file31773/smtplib-2.6-with-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:34:11 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 16:34:11 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379262851.38.0.00635083230068.issue19025@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:37:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 16:37:33 +0000
Subject: [issue17764] Support http.server passing bind address via commend
 line argument
In-Reply-To: <1366129730.55.0.013246712373.issue17764@psf.upfronthosting.co.za>
Message-ID: <3cdGTS396qz7Lkx@mail.python.org>


Roundup Robot added the comment:

New changeset a248655c8261 by Senthil Kumaran in branch 'default':
Expose --bind argument for http.server, enable http.server to bind to a user
http://hg.python.org/cpython/rev/a248655c8261

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17764>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:39:35 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Sep 2013 16:39:35 +0000
Subject: [issue17764] Support http.server passing bind address via commend
 line argument
In-Reply-To: <1366129730.55.0.013246712373.issue17764@psf.upfronthosting.co.za>
Message-ID: <1379263175.93.0.0153244441994.issue17764@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Found the patch suitable and had addressed Berker Pesag's review comments too. Thanks for contributing, Malte Swart and thanks for submitting the contributor agreement too.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17764>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:42:14 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Sep 2013 16:42:14 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1379263334.33.0.407983802378.issue18704@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[TJR]
> I am opposed to this specific proposal and 
> think this issue should be closed.

[Ramchandra Apte]
> Agree with Terry Reedy.

[R. Jayakrishnan]
> Better to close this issue then ...

I agree as well.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:45:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 16:45:28 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379263528.07.0.856769723035.issue16042@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is not important in the context of this issue, but readline(0) is blocked and returns 1-character string. Move the length check above self.sslobj.read(1). For readability you can also move the chr != "\n" inside the loop:

             while size is None or len(str) < size:
                 chr = self.sslobj.read(1)
                 if not chr or chr == "\n": break
                 str += chr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:46:03 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 16:46:03 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
Message-ID: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://stackoverflow.com/questions/15733558/python-ordereddict-not-keeping-element-order

I wonder why OrderedDict accepts dict as parameter in a first place? OD is used when order is important and if plain dict is supplied, the order is lost.

    >>> d = {3:4, 1:2}
    >>> OD(d)
    OrderedDict([(1, 2), (3, 4)])

OrderedDict should not accept dict as parameter.

----------
components: Library (Lib)
messages: 197787
nosy: techtonik
priority: normal
severity: normal
status: open
title: OrderedDict should not accept dict as parameter
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:47:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 16:47:33 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379263653.25.0.722698801999.issue16042@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is not important in the context of this issue, but readline(0) is blocked and returns 1-character string. Move the length check above self.sslobj.read(1). For readability you can also move the chr != "\n" inside the loop:

             while size is None or len(str) < size:
                 chr = self.sslobj.read(1)
                 if not chr or chr == "\n": break
                 str += chr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:48:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 16:48:11 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379263691.17.0.932684300486.issue16042@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg197788

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:48:55 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 16:48:55 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379263735.56.0.811867394004.issue16042@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Patch looks great, thanks Andrew.  All tests pass.  Feel free to commit to the 2.6 branch along with a NEWS file entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:49:46 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Sep 2013 16:49:46 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>
Message-ID: <1379263786.64.0.114161493355.issue19026@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

An OrderedDict is a dict subclass and needs to accept the same inputs as dict methods.  This is a guaranteed API and not a bug.

It is not the OrderedDict's fault if you supply an unordered input.  It can't add order after the fact.

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:50:46 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 16:50:46 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379263846.14.0.90829030563.issue16038@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

For 2.6 I'll make a revised version of Giampaolo's patch that doesn't add a new exception class.  

Rationale: Adding a new exception class changes the API of the module, which we'd like to avoid.  If someone is writing 2.6 code that wants to catch this exception, they can't write "except ftplib.LineTooLong" because the name isn't present.  Instead they'll have to catch the parent Error exception class and analyze either its type or the exception message.  My conclusion is that adding the new class isn't actually useful.

(bwarsaw and I are at a mini-sprint looking at the 2.6.9 blockers, so we're looking at all of these 'unlimited readline' issues and will continue to remove new exceptions introduced by patches.)

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Sep 15 18:54:20 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 16:54:20 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1379263653.25.0.722698801999.issue16042@psf.upfronthosting.co.za>
Message-ID: <20130915125405.29ba135e@anarchist>


Barry A. Warsaw added the comment:

On Sep 15, 2013, at 04:47 PM, Serhiy Storchaka wrote:

>It is not important in the context of this issue, but readline(0) is blocked
>and returns 1-character string. Move the length check above
>self.sslobj.read(1). For readability you can also move the chr != "\n" inside
>the loop:
>
>             while size is None or len(str) < size:
>                 chr = self.sslobj.read(1)
>                 if not chr or chr == "\n": break
>                 str += chr

Hi Serhiy.  Is there a functional difference to re-arranging this loop?
All things being equal, the minimal change is probably best.

Also, what do you mean by "readline(0) is blocked"?  Do you mean this is a
blocking call or something else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:00:42 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 17:00:42 +0000
Subject: [issue18709] SSL module fails to handle NULL bytes inside
 subjectAltNames general names (CVE-2013-4238)
In-Reply-To: <1376307172.38.0.0558370001214.issue18709@psf.upfronthosting.co.za>
Message-ID: <1379264442.08.0.2345108889.issue18709@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I'm removing 2.6 from the Versions field since AFAIK we've resolved this issue for 2.6.  This way it'll be easier to scan the blockers for 2.6.9.

If anyone things we still have things to address for this issue in 2.6.9, please reassign it or follow up.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18709>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:15:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 17:15:12 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <3cdHJv3pW1z7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset 8a6def3add5b by Andrew Kuchling in branch '2.6':
#16042: CVE-2013-1752: Limit amount of data read by limiting the call to readline().
http://hg.python.org/cpython/rev/8a6def3add5b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:20:13 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 17:20:13 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>
Message-ID: <1379265613.39.0.483651755754.issue19026@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

I don't know if it is bug or feature. There are probably cases when order is not important and OrderedDict is used, but I don't remember any.

Too bad Python doesn't have first class ordered mapping type, so that it could report error if unordered arguments are supplied (such as dict or **kwargs).

tag:wart

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:20:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 17:20:28 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379265628.89.0.563333639875.issue16042@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not sure what Serhiy means by "is blocked", but the second half makes sense: readline(0) on a file will return the empty string, but here it will read one character and return it.  Like he says, it doesn't break anything in the context of this bug fix, but it is an API bug.  Unless I'm missing something his replacement also has a bug, though: it won't add the \n to the returned string.

A minimal fix for the API bug would be to extend the 'if size' with an elif for 0 that returns the empty string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:20:48 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 15 Sep 2013 17:20:48 +0000
Subject: [issue19027] undefined symbol: _PyParser_Grammar
Message-ID: <1379265648.95.0.708128098895.issue19027@psf.upfronthosting.co.za>


New submission from Armin Rigo:

It is possible to get the working copy of Python 2.7 in a state such that any attempt to do "make" ends with the error shown in the title.  The working copy is perfectly valid; it is a matter of getting the wrong timestamps on the files.

(Despite the error message, this is not directly related to issue10013 or "make -j".)

I didn't try Python 3.x, but the same issue might apply.

How to reproduce:

- get your checkout, let's say in python/src/

- go to your build directory, say python/build/, and run "../src/configure; make".

- then, in the src dir, give Include/graminit.h a more recent timestamp than Python/graminit.c, for example by saying "touch Include/graminit.h" (this is the crux: a common mercurial checkout will order them the other way, just because of alphabetical ordering).

- remove your python/build/ directory completely, create it anew, and run again "../src/configure; make".

The cause of the message is that the Makefile rule for $(GRAMMAR_C) runs, because the GRAMMAR_H file is more recent; but the GRAMMAR_H rule does nothing, because the latter is already up-to-date.  So the only thing that runs is "touch $(GRAMMAR_C)".  But this creates an empty file build/Python/graminit.c!

----------
components: Interpreter Core
messages: 197797
nosy: arigo
priority: normal
severity: normal
status: open
title: undefined symbol: _PyParser_Grammar
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19027>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:23:13 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 17:23:13 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>
Message-ID: <1379265793.09.0.424728940613.issue19026@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Is it possible to make strict OrderedDict an optional feature? Like `from features import strict_ordered_dict'?

----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:26:03 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 17:26:03 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379265963.58.0.879980375734.issue16042@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

I took Serhiy's suggestion and just moved up the 'if size' check in the loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:34:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 17:34:17 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379266457.64.0.96796605216.issue16042@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Also, what do you mean by "readline(0) is blocked"?  Do you mean this is a blocking call or something else?

Yes, I mean this is a blocking call.

> Unless I'm missing something his replacement also has a bug, though: it won't add the \n to the returned string.

Oh, right. The correct code should be as I proposed in msg173413 or... as Andrew has committed. Good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:36:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 17:36:58 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>
Message-ID: <1379266618.97.0.312756879464.issue19026@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 19:50:38 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 17:50:38 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379267438.16.0.6543841892.issue19025@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Perhaps a section in the docs about the differences from typical Python classes is warranted:

  - Enum members are virtual
  - Enum members are singletons
  - new Enum members (aka instances of an Enum class) cannot be created
  - during class creation Enum members cannot be overwritten, nor overwrite
    other class attributes
  - Enum classes with members cannot be subclassed
  - Enum classes support iteration
  - Enum classes support containment

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:01:03 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 18:01:03 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379268063.35.0.417424306997.issue19025@psf.upfronthosting.co.za>


Ethan Furman added the comment:

As for the error messages (going in reverse order):

==========================================================================
--> del cute_cat.name
Traceback (most recent call last):
...
AttributeError: can't delete attribute
==========================================================================

This is the same error given by @property.


==========================================================================
--> del MyPet.spam
--> hasattr(MyPet, 'spam')
False
==========================================================================

This is correct.  Only Enum members get special treatment.


==========================================================================
--> del MyPet['LONELY_WOLF']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'EnumMeta' object does not support item deletion
==========================================================================

There are two errors here: LONELY_WOLF does not exist, and an operation is being attempted that is not supported.  Of those two, attempting the unsupported operation is the more serious, and should be the reported error.  (Yes, dealing with multiple errors at once can often be confusing.)


==========================================================================
--> del MyPet.CUTE_CAT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: CUTE_CAT
==========================================================================

This one I am not sure about (much as I am not sure about __getattr__ in #19011).  Enum members are virtual, and don't actually live in the class namespace.  I'm inclined to leave the existing behavior as is, but if we choose to change one, we should change both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:05:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 18:05:03 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379268303.47.0.458516318277.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

For the security fix, the check should only be done if the file is the the default .netrc.  (Which would also make your error message correct...otherwise it is not :)  Also, it would make more sense for the 'prop =' to be inside the 'if posix'.

Barry, with that detail fixed should I apply this to 2.6?  (I'll tweak the error messages a bit, too.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:08:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 18:08:40 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379268520.12.0.0539228795169.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note that I'll test it by hand before applying, and will write a test for 3.3 (where Mock is available to make testing practical).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:25:49 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Sep 2013 18:25:49 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>
Message-ID: <1379269549.16.0.384035631498.issue19026@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In general, it is not possible for a hypothetical StrictOrderedDict to know whether its input was ordered or not.  For the specific case of dict, it is possible, but the general case is of course completely general (i.e. if the input has a keys() method, the pairs are loaded with:  for k in other.keys(): od[k] = other[k]).  Those semantics are guaranteed.

Remember, Armin's core concept for OrderedDict was "to remember the order that keys were added, the order is determined by whoever does the adding".

FWIW, the stackoverflow question was resolved trivially.  The learning point is perfectly general (i.e. it explains why you write Decimal('1.1') instead of Decimal(1.1)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:38:29 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Sun, 15 Sep 2013 18:38:29 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1379270309.25.0.189303988808.issue18594@psf.upfronthosting.co.za>


Anoop Thomas Mathew added the comment:

40% faster collections.Counter() . Removed C accelerator. Patch attached. Passes all tests. Results comparison follows.

----------
keywords: +patch
nosy: +Anoop.Thomas.Mathew
Added file: http://bugs.python.org/file31774/collections_Counter_without_C_accelerator_with_comprehension.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:39:19 2013
From: report at bugs.python.org (Anoop Thomas Mathew)
Date: Sun, 15 Sep 2013 18:39:19 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1379270359.97.0.21969873278.issue18594@psf.upfronthosting.co.za>


Anoop Thomas Mathew added the comment:

Performance comparison with and without patch applied.

----------
Added file: http://bugs.python.org/file31775/performance_comparision.csv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:44:00 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 18:44:00 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1379268303.47.0.458516318277.issue14984@psf.upfronthosting.co.za>
Message-ID: <20130915144353.511490b3@anarchist>


Barry A. Warsaw added the comment:

On Sep 15, 2013, at 06:05 PM, R. David Murray wrote:

>For the security fix, the check should only be done if the file is the the
>default .netrc.  (Which would also make your error message
>correct...otherwise it is not :) Also, it would make more sense for the 'prop
>=' to be inside the 'if posix'.
>
>Barry, with that detail fixed should I apply this to 2.6?  (I'll tweak the
>error messages a bit, too.)

For the error message, I suggest including both os.getuid and prop.st_uid,
e.g. something like:

".netrc file is owned by (%d); should be (%d)" % (prop.st_uid, os.getuid())

NetrcParseError seems a little odd but I suppose I could justify incorrect
ownership or mode as a parse error.  We definitely don't want to introduce a
new exception for 2.6.9, so the only other option is an OSError I think.

RDM, can you write any tests for this issue?  Also, are any documentation
changes necessary?  I think this should be a candidate for 2.6.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:44:22 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 18:44:22 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379270662.6.0.759323394226.issue14984@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:47:11 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 18:47:11 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1379266457.64.0.96796605216.issue16042@psf.upfronthosting.co.za>
Message-ID: <20130915144708.2c449c09@anarchist>


Barry A. Warsaw added the comment:

On Sep 15, 2013, at 05:34 PM, Serhiy Storchaka wrote:

>Oh, right. The correct code should be as I proposed in msg173413 or... as
>Andrew has committed. Good.

Excellent.  So we're good for this in 2.6.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:49:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 18:49:38 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379270978.73.0.0750753819639.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is a 2.6 specific patch.  I've hand tested this.

----------
keywords: +patch
Added file: http://bugs.python.org/file31776/netrc-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:51:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 18:51:06 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379271066.22.0.450633120942.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

I could write a 2.6 test for the permissions part, but not for the incorrect owner part.  Do you want one without the other?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 20:54:05 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 18:54:05 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1379271066.22.0.450633120942.issue14984@psf.upfronthosting.co.za>
Message-ID: <20130915145401.2a5c6e07@anarchist>


Barry A. Warsaw added the comment:

On Sep 15, 2013, at 06:51 PM, R. David Murray wrote:

>I could write a 2.6 test for the permissions part, but not for the incorrect
>owner part.  Do you want one without the other?

Yeah, I guess you can't mock os or stat in 2.6. ;)

Let's test the permission part, and if you can manually test the owner part,
that'll have to be good enough.  The former will at least test the changes to
NetrcParseError.__str__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:02:40 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 15 Sep 2013 19:02:40 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379269549.16.0.384035631498.issue19026@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xJU6GiEx7hN4bQyXt6Av0Hx4yec4aVSF4b7xJRRgY97vA@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 15, 2013 at 9:25 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
>
> In general, it is not possible for a hypothetical StrictOrderedDict to know whether its input was ordered or not.

Right. That's why it should not accept input that can only be
unordered (including dict and **kwargs) - this is what I mean by
strict mode.

> Remember, Armin's core concept for OrderedDict was "to remember the order that keys were added, the order is determined by whoever does the adding".

IMHO the statement "the order is determined by whoever does the
adding" is false in 9/10 cases of passed dict. In 9/10 cases whoever
supplies dict or **kwargs argument is unaware of what mistake he is
making, and how many hour she will spend discovering the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:08:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 19:08:40 +0000
Subject: [issue18945] Name collision handling in tempfile is not covered by
 tests
In-Reply-To: <1378460052.66.0.943377543243.issue18945@psf.upfronthosting.co.za>
Message-ID: <3cdKqq2Qfqz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset fa54069eb8c4 by Eli Bendersky in branch '2.7':
Close #18945: Add tests for tempfile name collision handling.
http://hg.python.org/cpython/rev/fa54069eb8c4

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18945>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:09:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 19:09:42 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379272182.88.0.0288544506112.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  Answering the doc question caused me to run into something that calls the whole patch into question: 
  
  http://www.unix.com/unix-dummies-questions-answers/11326-netrc-refuses-password.html.

In that example, the ftp program only rejected reading the password from the .netrc file when the permissions were wrong, but otherwise happily read it.  *That* would be a better backward compatibility fix.  And yes, in that case I think we should probably put a note about it in the docs.

I'll update my patch and add the permissions test.  I originally used OSError, but with the trigger on password only I think the parse error would actually be more appropriate, so I'll switch to that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:10:44 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Sep 2013 19:10:44 +0000
Subject: [issue18998] iter() not working in ElementTree
In-Reply-To: <1378823821.86.0.0607841458966.issue18998@psf.upfronthosting.co.za>
Message-ID: <1379272244.5.0.753135208002.issue18998@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> works for me
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18998>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:21:18 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 19:21:18 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1379272878.79.0.864247673631.issue18747@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

After further contemplation and without objection from __ap__ and Crys on IRC, I am de-targeting this for 2.6.  I won't apply it for 2.6.9.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18747>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:23:55 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 19:23:55 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379273035.98.0.485704856044.issue16038@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

2.6 version of the patch.  Changes from Giampaolo's version of the patch:

* 2.6 didn't have FTP over TLS, so the patch changes slightly to adapt.

* Removed the LineTooLong exception class and just raise Error instead.  (This repeats the message text for "Line too long" in several place.)

----------
Added file: http://bugs.python.org/file31777/ftplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:27:34 2013
From: report at bugs.python.org (Dan Nicholson)
Date: Sun, 15 Sep 2013 19:27:34 +0000
Subject: [issue4636] bdist_wininst installer with install script raises
 exception
In-Reply-To: <1229030167.98.0.0716327891895.issue4636@psf.upfronthosting.co.za>
Message-ID: <1379273254.87.0.270474427777.issue4636@psf.upfronthosting.co.za>


Dan Nicholson added the comment:

Right, that's what makes this difficult. If the stub exe of the target python was used, then it wouldn't need to care about compatibility. However, what you're running is the stub of the build python. So, when I distribute a bdist_wininst exe, it's running the stub from my python on the user's machine. That introduces a few compatibility issues.

1. The exe needs the same CRT version installed on the target that it was built with. It would fail to run immediately in this case. This does make having the built python be newer than the target python a little difficult.

2. The exe loads the python dll on the target machine. This requires the python dll to have enough compatibility for the usage of the python API in the exe of the build version.

3. After loading the python dll, python code is run in the target python. This is the problem I'm trying to solve here. The python code is embedded in the exe of the installer, so the compatibility with the target python has to be considered at build time.

The situation you're describing where the wininst of the target is run could maybe be made to work, but it would be a larger project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4636>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:29:07 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 19:29:07 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <1379273347.08.0.133578817405.issue18989@psf.upfronthosting.co.za>


Ethan Furman added the comment:

As David noted, this was discussed somewhere in the megathreads that was the Enum PEP discussion.

As Georg noted changes to such a thoroughly discussed API should not be taken lightly.

As Antoine noted the Enum class is more restricted than normal classes by design.

As Nick seconded the current situation is thoroughly confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:30:23 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:30:23 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379273423.83.0.666523621256.issue14984@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:30:29 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:30:29 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379273429.54.0.436878544949.issue14984@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:33:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 19:33:57 +0000
Subject: [issue13888] test_builtin failure when run after test_tk
In-Reply-To: <1327661656.8.0.445863136974.issue13888@psf.upfronthosting.co.za>
Message-ID: <1379273637.64.0.410001654298.issue13888@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is due PyOS_InputHook. After commenting out EnableEventHook() tests are passed.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13888>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:34:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 19:34:57 +0000
Subject: [issue18989] reuse of enum names in class creation inconsistent
In-Reply-To: <1378753130.62.0.150959940535.issue18989@psf.upfronthosting.co.za>
Message-ID: <3cdLQ863cxz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset 54ddd1124df8 by Ethan Furman in branch 'default':
Close #18989: enum members will no longer overwrite other attributes, nor be overwritten by them.
http://hg.python.org/cpython/rev/54ddd1124df8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18989>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:38:11 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:38:11 +0000
Subject: [issue19027] undefined symbol: _PyParser_Grammar
In-Reply-To: <1379265648.95.0.708128098895.issue19027@psf.upfronthosting.co.za>
Message-ID: <1379273891.48.0.512975412854.issue19027@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19027>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:42:12 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:42:12 +0000
Subject: [issue16037] httplib: header parsing is not unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1379274132.82.0.51138611452.issue16037@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: httplib: header parsing is not delimited -> httplib: header parsing is not unlimited
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:43:03 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:43:03 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379274183.91.0.539505463113.issue16038@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:43:21 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 19:43:21 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379274201.18.0.0446619131565.issue14984@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

FWIW, the Ubuntu manpage netrc(5) says:

     password string
               Supply a password.  If this token is present, the auto-login
               process will supply the specified string if the remote server
               requires a password as part of the login process.  Note that
               if this token is present in the .netrc file for any user other
               than anonymous, ftp will abort the auto-login process if the
               .netrc is readable by anyone besides the user.

On Ubuntu, /usr/bin/ftp comes from the netkit-ftp package, which has this code in ruserpass.c:

		case PASSWD:
			if (*aname==NULL) {
	fprintf(stderr, "Error: `password' must follow `login' in .netrc\n");
				goto bad;
			}
			if (strcmp(*aname, "anonymous") &&
			    fstat(fileno(cfile), &stb) >= 0 &&
			    (stb.st_mode & 077) != 0) {
	fprintf(stderr, "Error - .netrc file not correct permissions.\n");
	fprintf(stderr, "Remove password or correct mode (should be 600).\n");
				goto bad;

So it looks like it's only doing a permission check too, and then only if it sees `password`. (FWIW, it does the same check, sans the "anonymous" check obviously, for `account`.)

Seems to me like only doing the permission check is sufficient, and in line with existing tools and documentation.  (Though technically, I suppose if you chowned ~/.netrc to someone other than yourself, it would be "readable by anyone besides the user".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:43:31 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:43:31 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1379274211.29.0.624743481632.issue16039@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:44:01 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:44:01 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1379274241.21.0.0126367131067.issue16040@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:45:28 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:45:28 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1379274328.6.0.571620363233.issue16041@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +barry
priority: critical -> release blocker
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:46:25 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:46:25 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379274385.6.0.284459546174.issue16042@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:46:57 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Sep 2013 19:46:57 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1379274417.26.0.854981135183.issue16043@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:53:52 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 15 Sep 2013 19:53:52 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1379274832.75.0.688658180549.issue16039@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Updated version of the patch against 2.6 that adds a test.  Thanks for the fix, Emil!

----------
nosy: +akuchling
Added file: http://bugs.python.org/file31778/imaplib.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:55:47 2013
From: report at bugs.python.org (Daniel Holth)
Date: Sun, 15 Sep 2013 19:55:47 +0000
Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on
 import
In-Reply-To: <1374331044.49.0.0628884037506.issue18515@psf.upfronthosting.co.za>
Message-ID: <1379274947.6.0.306362084975.issue18515@psf.upfronthosting.co.za>


Daniel Holth added the comment:

I am withdrawing zipfile-no-crc32.patch. It did not work correctly. 

zdlazy.patch should go in. It avoids creating the rarely-needed crc32 table until the first time it is needed, saving some memory and the majority of time needed to import the module.

zdlazy.patch should not affect its C replacement at all, except that the rarely-needed CRC32 table that we are not generating becomes a never-needed table.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18515>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:58:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 19:58:58 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <3cdLxs4r8vz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset c39f42f46a05 by Georg Brandl in branch '3.1':
Fix tkinter regression introduced by the security fix in #16248.
http://hg.python.org/cpython/rev/c39f42f46a05

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Sun Sep 15 21:59:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Sep 2013 19:59:57 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
 arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1379275197.54.0.962682037463.issue16248@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fix backported to 3.1, closing.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:08:36 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 20:08:36 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379275716.77.0.404786694887.issue16038@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

======================================================================
FAIL: test_retrlines_too_long (__main__.TestFTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_ftplib.py", line 374, in test_retrlines_too_long
    self.client.retrlines, 'retr', received.append)
AssertionError: Error not raised

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:09:25 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 20:09:25 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379275765.49.0.954762462863.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is an updated patch, with docs and test.

Turns out it actually wasn't necessary to move the check to the password, but I'm leaving it that way anyway.  The reason it wasn't necessary is that we don't actually parse the .netrc file correctly: we require that the password field be present.  So I'll want to fix *that* bug in some version of python, in which case the test should then be in the password check where I have it now...

----------
Added file: http://bugs.python.org/file31779/netrc-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:15:27 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Sep 2013 20:15:27 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379276127.15.0.719946984023.issue14984@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

@RDM: In netrc.rst, s/posix/POSIX/

It also looks like you're keeping the ownership test.  Did I misunderstand msg197815?  I thought you were only going to keep the permission test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:15:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 20:15:41 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379276141.6.0.758283834614.issue14984@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file31779/netrc-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:15:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 20:15:57 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379276157.25.0.785689875914.issue14984@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Added file: http://bugs.python.org/file31780/netrc-2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:26:40 2013
From: report at bugs.python.org (Vitaly Murashev)
Date: Sun, 15 Sep 2013 20:26:40 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1379276800.95.0.816415788505.issue18307@psf.upfronthosting.co.za>


Vitaly Murashev added the comment:

patch suggested (over 3.3.0 code base).
Without patch test fails, with patch - passed

----------
components:  -Library (Lib)
keywords: +patch
Added file: http://bugs.python.org/file31781/zipimport.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:35:53 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 15 Sep 2013 20:35:53 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1379277353.06.0.51052586011.issue18857@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello. I attached a simple patch for the urlencode case. I'll try to make one for parse_qs(l) as well.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31782/urllib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:39:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Sep 2013 20:39:14 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379277554.79.0.313509235366.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, you did :)  I was using "permissions check" to cover both tests, since as you say, if the file is owned by someone other than the user running the processes, a user other than the one running the process has permission to modify it.

posix->POSIX fixed in my local copy.  Should I commit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:51:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 20:51:08 +0000
Subject: [issue19028] tkinter.tkapp.merge() fails on non-strings
Message-ID: <1379278268.95.0.270517014711.issue19028@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

tkinter.tkapp.merge() recursively merge Python data into Tcl string. When a subitem neither tuple, string or byte string, it calls str() on it. But then it use PyBytes_AsString() which always fails because accepts bytes instead of str.

The proposed patch fixes processing general objects in merge(), simplifies processing strings, and adds tests.

This is only 3.3 issue. merge() was deprecated and removed in 3.4.

----------
components: Tkinter
files: tkinter_merge.patch
keywords: patch
messages: 197833
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: tkinter.tkapp.merge() fails on non-strings
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31783/tkinter_merge.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19028>
_______________________________________

From report at bugs.python.org  Sun Sep 15 22:59:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 20:59:44 +0000
Subject: [issue19029] tix.py uses StringType
Message-ID: <1379278784.45.0.495441517749.issue19029@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Lib/tkinter/tix.py uses the StringType name which is not defined. This is a remnant from 2.x where the StringType type was imported from the types module. In 3.x it gone and was replaced by str in Lib/tkinter/__init__.py.

The proposed patch fixes it also in tix.py.

----------
components: Tkinter
files: tix_StringType.patch
keywords: easy, patch
messages: 197834
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: tix.py uses StringType
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31784/tix_StringType.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19029>
_______________________________________

From report at bugs.python.org  Sun Sep 15 23:09:50 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 15 Sep 2013 21:09:50 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1379279390.26.0.281719689007.issue18857@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Added patch for parse_qsl as well.

----------
Added file: http://bugs.python.org/file31785/urllib_null_value.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Sun Sep 15 23:15:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Sep 2013 21:15:06 +0000
Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on
 import
In-Reply-To: <1374331044.49.0.0628884037506.issue18515@psf.upfronthosting.co.za>
Message-ID: <1379279706.28.0.783729552363.issue18515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I meant my pure Python patch in issue10030. Binding crctable to local variable is one of microoptimizations. Not the largest one however. So in general I not objects. Your patch LGTM. Only one nitpick -- instead "not _ZipDecrypter.crctable" use "_ZipDecrypter.crctable is None".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18515>
_______________________________________

From report at bugs.python.org  Sun Sep 15 23:57:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 21:57:35 +0000
Subject: [issue18771] Reduce the cost of hash collisions for set objects
In-Reply-To: <1376765878.32.0.652855927715.issue18771@psf.upfronthosting.co.za>
Message-ID: <3cdPZk3kRWz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 9353c611f897 by Raymond Hettinger in branch 'default':
Issue 18771: Make it possible to set the number linear probes at compile-time.
http://hg.python.org/cpython/rev/9353c611f897

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18771>
_______________________________________

From report at bugs.python.org  Mon Sep 16 00:16:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Sep 2013 22:16:09 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <3cdQ085rwBz7LmS@mail.python.org>


Roundup Robot added the comment:

New changeset 100606ef02cf by Andrew Kuchling in branch 'default':
#1565525: Add traceback.clear_frames() helper function to clear locals ref'd by a traceback
http://hg.python.org/cpython/rev/100606ef02cf

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Mon Sep 16 00:36:50 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 Sep 2013 22:36:50 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1379284610.94.0.0631360390853.issue18857@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The patch looks good, but I have doubt in the claim that, this new behavior is actually a right thing to do.

RDM wrote:

Now, that said, it seems to me that while it is not (apparently) RFC compliant, query strings do have a natural way to support null values: a name without a value.  It would therefore be convenient if urlencode supported null values by turning something like {'josh': None, 'fred': 'abc'} into:

    josh&fred=abc


It is correctly recognized that it is not RFC Compliant. A reference to this behavior exhibited by the software may be helpful. The `application/x-www-form-urlencoded` type always looks for key=value kind of query string only. And changes submitted by patch will break for folks who think "a=None" is actually what they expected when the sent {a:None}.

I think, some present instances where this behavior is exhibited will be good to note.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 16 00:42:00 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 22:42:00 +0000
Subject: [issue12558] Locale-dependent exception for float width argument to
 Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1379284920.4.0.435164809262.issue12558@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps we can fix it on the Python side. When self.tk is called with a configuration cnf, cnf is often (always?) first passed to Misc._options, as in BaseWidget.__init__:
        self.tk.call(
            (widgetName, self._w) + extra + self._options(cnf))

Misc._options loops through cnf.items looking for values to and modify (currently callables, tuples, and lists) before passing the result on to tk.call.

We could make a list *countkeys* of cnf (configuration) count items fed to strtod. Then, with that loop, if the locale uses comma decimal separators (or always) convert float values for those keys to ints.

  if comma and k in countkeys: v = int(v)  # or
  if comma and k in countkeyw and isinstance(v, float): v = int(v)

I am presuming that tk truncates fractional parts as int() does; if not, use round().

I cannot verify the bug on US Win7 3.3.2 because 'de_DE.utf8' is an 'unsupported locale' for me. For the C locale, I verified that tk silently accept not only non-integral widths, but also negative widths.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Mon Sep 16 01:22:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Sep 2013 23:22:46 +0000
Subject: [issue19029] tix.py uses StringType
In-Reply-To: <1379278784.45.0.495441517749.issue19029@psf.upfronthosting.co.za>
Message-ID: <1379287366.22.0.783448126358.issue19029@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am slightly surprised no one has complained about a NameError. I guess tix is untested and not used too much, or at least not the two methods, tixCommand.tix_configure and TixWidget.config_all.  Anyway, do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19029>
_______________________________________

From report at bugs.python.org  Mon Sep 16 01:28:22 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Sep 2013 23:28:22 +0000
Subject: [issue18307] Relative path in co_filename for zipped modules
In-Reply-To: <1372256829.94.0.0966099631525.issue18307@psf.upfronthosting.co.za>
Message-ID: <1379287702.92.0.498353784708.issue18307@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18307>
_______________________________________

From report at bugs.python.org  Mon Sep 16 01:51:49 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Sep 2013 23:51:49 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1379289109.95.0.531818573236.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Two issues still remain:

  - custom behavior, as well as value and name, don't show in help
  - value and name, if defined as enum members, show up as data 
    descriptors in help

=======================================================================================
--> class Test(enum.Enum):
...   this = 'that'
...   these = 'those'
...   whose = 'mine'
...   name = 'Python'
...   value = 'awesome'
...   def what(self):
...     return "%s is %s!" % (self.name, self.value)
... 

--> dir(Test)
['__class__', '__doc__', '__members__', '__module__', 'name', 'these', 'this', 'value', 'whose']

--> dir(Test.this)
['__class__', '__doc__', '__module__', 'name', 'value', 'what']


--> help(Test)
Help on Test in module __main__ object:

class Test(enum.Enum)
 |  Method resolution order:
 |      Test
 |      enum.Enum
 |      builtins.object
 |  
 |  Data and other attributes defined here:
 |  
 |  these = <Test.these: 'those'>
 |  
 |  this = <Test.this: 'that'>
 |  
 |  whose = <Test.whose: 'mine'>
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.Enum:
 |  
 |  name
 |      The name of the Enum member.
 |  
 |  value
 |      The value of the Enum member.
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.EnumMeta:
 |  
 |  __members__
 |      Returns a mapping of member name->value.
 |      
 |      This mapping lists all enum members, including aliases. Note that this
 |      is a read-only view of the internal mapping.
(END)
=======================================================================================

At this point, dir() on an Enum member shows what can be done with the member, and dir() on an Enum class shows what can be done with the class.

I'll create new issues to track changes for inspect and help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:00:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Sep 2013 00:00:20 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <3cdSJN19FCzSqc@mail.python.org>


Roundup Robot added the comment:

New changeset 353ced6ae182 by Ethan Furman in branch 'default':
Close #18693: Enum is now more help() friendly.
http://hg.python.org/cpython/rev/353ced6ae182

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:00:54 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 00:00:54 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
Message-ID: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Due to the odd nature of Enum classes and instances, the normal methods used by inspect.getmembers and inspect.classify_class_attrs are insufficient.

By special casing Enum inside those two functions the correct information can be returned.

Here is an example of the problem:

=======================================================================================
--> class Test(enum.Enum):
...   this = 'that'
...   these = 'those'
...   whose = 'mine'
...   name = 'Python'
...   value = 'awesome'
...   def what(self):
...     return "%s is %s!" % (self.name, self.value)
... 

--> help(Test)
Help on Test in module __main__ object:

class Test(enum.Enum)
 |  Method resolution order:
 |      Test
 |      enum.Enum
 |      builtins.object
 |  
 |  Data and other attributes defined here:
 |  
 |  these = <Test.these: 'those'>
 |  
 |  this = <Test.this: 'that'>
 |  
 |  whose = <Test.whose: 'mine'>
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.Enum:
 |  
 |  name
 |      The name of the Enum member.
 |  
 |  value
 |      The value of the Enum member.
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.EnumMeta:
 |  
 |  __members__
 |      Returns a mapping of member name->value.
 |      
 |      This mapping lists all enum members, including aliases. Note that this
 |      is a read-only view of the internal mapping.
(END)
=======================================================================================

As can be seen, 'name' and 'value' are not showing up as enum members.

----------
messages: 197844
nosy: barry, eli.bendersky, ethan.furman, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: Make inspect.getmembers and inspect.classify_class_attrs Enum aware
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:03:14 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 00:03:14 +0000
Subject: [issue19031] Make help() enum aware
Message-ID: <1379289794.97.0.994378932185.issue19031@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Currently, if help() is called on an Enum member, it displays help for the class.  While this is usually what one wants, it is not for Enums.

----------
messages: 197845
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
status: open
title: Make help() enum aware
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19031>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:03:39 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 00:03:39 +0000
Subject: [issue18693] help() not helpful with enum
In-Reply-To: <1376013592.17.0.550012846255.issue18693@psf.upfronthosting.co.za>
Message-ID: <1379289819.87.0.352263529989.issue18693@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Tracking inspect in issue19030.

Tracking help in issue19031.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18693>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:06:06 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 Sep 2013 00:06:06 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1379228781.66.0.248898457185.issue14927@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSpOk4cbRDhjodjqJ-Oywf=L9TeTk3C+fqDhF=UrYPonQ@mail.gmail.com>


Senthil Kumaran added the comment:

> Georg Brandl added the comment:
>
> I would propose a leading underscore for these methods; they should make it clear to the user that the parameter is meant to be "private".

+1 to this proposal.
This style is present with randrange, randbelow and shuffle.

> With this line in the docstring, I would wonder "Why is the argument there in the first place?!" (because most people don't know about the optimization technique).

This style has been present since the introduction of these functions.
One attempt to clarify / cleanup shuffle here is: 29430:b80a22250e4f
Georg :  I am unaware of the optimization technique you refer to as
well, it will helpful if you could point to any resource.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:17:23 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 16 Sep 2013 00:17:23 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <CAPOVWOSpOk4cbRDhjodjqJ-Oywf=L9TeTk3C+fqDhF=UrYPonQ@mail.gmail.com>
Message-ID: <CAExdVN=dVquv3vrkL1th5Mt1owYtDuXoYy3eccFa3RN1T4+iTQ@mail.gmail.com>


Tim Peters added the comment:

[Senthil Kumaran]
> I am unaware of the optimization technique you refer to as
> well, it will helpful if you could point to any resource.

It's an old trick since the very first Pythons:  global lookups are
much slower than local lookups (the difference between the LOAD_GLOBAL
and LOAD_FAST opcodes in CPython).  Putting:

     ..., _fast=slow, ...

in an argument list means we endure the slow lookup (of `slow`) only
once, when the function is first defined.  When the function is
_called_, that binding is available via the local (much faster lookup)
variable `_fast`.

Purely a speed trick, but can make a real difference in very heavily
used functions.

And it's a Good Idea to put a leading underscore on such arguments.
It's never intended that users pass values for them.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From tim.peters at gmail.com  Mon Sep 16 02:17:03 2013
From: tim.peters at gmail.com (Tim Peters)
Date: Sun, 15 Sep 2013 19:17:03 -0500
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <CAPOVWOSpOk4cbRDhjodjqJ-Oywf=L9TeTk3C+fqDhF=UrYPonQ@mail.gmail.com>
References: <1379228781.66.0.248898457185.issue14927@psf.upfronthosting.co.za>
 <CAPOVWOSpOk4cbRDhjodjqJ-Oywf=L9TeTk3C+fqDhF=UrYPonQ@mail.gmail.com>
Message-ID: <CAExdVN=dVquv3vrkL1th5Mt1owYtDuXoYy3eccFa3RN1T4+iTQ@mail.gmail.com>

[Senthil Kumaran]
> I am unaware of the optimization technique you refer to as
> well, it will helpful if you could point to any resource.

It's an old trick since the very first Pythons:  global lookups are
much slower than local lookups (the difference between the LOAD_GLOBAL
and LOAD_FAST opcodes in CPython).  Putting:

     ..., _fast=slow, ...

in an argument list means we endure the slow lookup (of `slow`) only
once, when the function is first defined.  When the function is
_called_, that binding is available via the local (much faster lookup)
variable `_fast`.

Purely a speed trick, but can make a real difference in very heavily
used functions.

And it's a Good Idea to put a leading underscore on such arguments.
It's never intended that users pass values for them.

From report at bugs.python.org  Mon Sep 16 02:36:08 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 Sep 2013 00:36:08 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <CAExdVN=dVquv3vrkL1th5Mt1owYtDuXoYy3eccFa3RN1T4+iTQ@mail.gmail.com>
Message-ID: <CAPOVWOSJO5=4VDAnk3XqdM9Hug0Eqo6eBrbvLtMRMZRH6r6_7w@mail.gmail.com>


Senthil Kumaran added the comment:

Tim Peters added the comment:

>      ..., _fast=slow, ...
>
> in an argument list means we endure the slow lookup (of `slow`) only
> once, when the function is first defined.  When the function is
> _called_, that binding is available via the local (much faster lookup)
> variable `_fast`.
>
> Purely a speed trick, but can make a real difference in very heavily
> used functions.

Thanks for the answer, Tim. Interesting optimization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Mon Sep 16 02:43:05 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 16 Sep 2013 00:43:05 +0000
Subject: [issue19032] __reduce_ex__ on lock object
Message-ID: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>


New submission from Ram Rachum:

>>> import threading
    >>> l = threading.Lock()
    >>> l.__reduce_ex__(3)
    (<function __newobj__ at 0x00000000026CD8C8>,
     (<class '_thread.lock'>,),
     None,
     None,
     None)

Isn't it a bug that `__reduce_ex__` works on the non-pickleable lock object?

----------
components: Library (Lib)
messages: 197850
nosy: cool-RR
priority: normal
severity: normal
status: open
title: __reduce_ex__ on lock object
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:13:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 01:13:35 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1379294015.75.0.840709350602.issue18857@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thank you for working on the patches, Claudiu, but...

The backward compatibility concern is valid.

Furthermore, I did a bunch of googling looking for examples.  I did not turn up any examples of APIs that were documented to use parameters without '='...all the cases I looked at that mentioned "parameter without a value" specified the "xxx=" form.

Given that, and thinking about it further, it appears to me that a parameter with no '=' should be treated the same as one that has an '=' but no value...that is, the same as using an empty string.  It would be *logical* for it to be a "nul" value, but in fact the http RFCs have no concept of a "nul" value, so it is in fact out of place.  

Sorry to have sent people down the wrong path here.

So I'm back to saying that one should not use None in an application to represent no value for a query parameter, but rather the empty string.  The url parsing code should turn a parameter without an '=' into an empty string, I think, but again there are backward compatibility concerns there.  There may be code that unintentionally depends on them being discarded.

So, I *think* we could, and should, make them not ignored, but turned into empty strings, in 3.4, following the first part in Postel's law ("be generous in what you accept").  But following the second half of Postel's law ("be strict in what you generate") we really shouldn't generate parameters without even an '=', given that they are not RFC compliant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:17:50 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 16 Sep 2013 01:17:50 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1379294270.51.0.418162229485.issue18975@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

Antoine: I agree that it does look weird to have thousands separators at one place and not at the other but IMO it's still slightly better - the number formatted with separators is simply more readable that separator-less one.

R. David Murray: what's the acceptable separator then? Modifying it to be locale-aware would make it inconsistent with the rest of the output (which, admittedly, is also the case with introducing space separator, dot still is the fraction separator though).

I modified my patch to not have the separators at all, please find timeit-v3-actual-changes-no-separators.patch - if that's the condition for accepting this patch then so be it - the description of the patch would be "print number of loops per second" and the example output is:

10000 loops, best of 3: 34.6 usec per loop (28870 loops/s)

----------
Added file: http://bugs.python.org/file31786/timeit-v3-actual-changes-no-separators.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:24:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 01:24:01 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379294641.53.0.301366149421.issue19030@psf.upfronthosting.co.za>


R. David Murray added the comment:

Special casing Enum in inspect has a code smell to it.  There may not be a better option, but it sure feels ugly.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:26:30 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 01:26:30 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379294790.81.0.380959172178.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Attached patch yields these results:

=======================================================================================
Help on class Test in module __main__:

class Test(enum.Enum)
 |  Method resolution order:
 |      Test
 |      enum.Enum
 |      builtins.object
 |  
 |  Data and other attributes defined here:
 |  
 |  name = <Test.name: 'Python'>
 |  
 |  these = <Test.these: 'those'>
 |  
 |  this = <Test.this: 'that'>
 |  
 |  value = <Test.value: 'awesome'>
 |  
 |  whose = <Test.whose: 'mine'>
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.Enum:
 |  
 |  name
 |      The name of the Enum member.
 |  
 |  value
 |      The value of the Enum member.
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from enum.EnumMeta:
 |  
 |  __members__
 |      Returns a mapping of member name->value.
 |      
 |      This mapping lists all enum members, including aliases. Note that this
 |      is a read-only view of the internal mapping.
(END)
=======================================================================================

----------
keywords: +patch
Added file: http://bugs.python.org/file31787/issue19030.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:31:12 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 01:31:12 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379295072.31.0.745183165389.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

R David Murray said:
>
>Special casing Enum in inspect has a code smell to it.

I agree, and I'm certainly open to other options.

The flow at this point is:

  help() --> inspect.classify_class_attrs --> dir() --> Enum.__dir__

Because inspect relies on dir and Enum's dir has been customized, inspect will fail to return the whole story.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:31:22 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 Sep 2013 01:31:22 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>
Message-ID: <1379295082.59.0.509252741587.issue14927@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Attaching a patch after changing int=int to _int = int and improving the docstring. Please review the changes to the docstring and see if it will be helpful.

----------
status: closed -> pending
Added file: http://bugs.python.org/file31788/14927.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:32:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 01:32:26 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379295146.56.0.521467943048.issue19030@psf.upfronthosting.co.za>


R. David Murray added the comment:

So the real problem is that inspect depends on dir?  Isn't there already a bug open for that issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:42:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 01:42:59 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1379295779.38.0.860440086714.issue18975@psf.upfronthosting.co.za>


R. David Murray added the comment:

My vote is no separators.  But I'm just one vote :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Mon Sep 16 03:44:02 2013
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 16 Sep 2013 01:44:02 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>
Message-ID: <1379295842.35.0.533340623077.issue14927@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I wouldn't add info about the optimization in the docstring.

In _randbelow() I think you missed a call to int().
For _randbelow(), all arguments after "int" are non-public ones.
(_randbelow as a private function wouldn't necessarily need the change, but it's good for consistency.)

Final decision should be made by Raymond.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Mon Sep 16 04:07:29 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 Sep 2013 02:07:29 +0000
Subject: [issue14927] add "Do not supply 'int' argument" to random.shuffle
 docstring
In-Reply-To: <1338133448.81.0.712858049705.issue14927@psf.upfronthosting.co.za>
Message-ID: <1379297249.17.0.887528115548.issue14927@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for catching the mistake at _randbelow. Updated patch to fix that and removed the explanation in the docstring. Not sure if _randbelow should changed (fully) or not at all. Leaving the change only with _int.
Will wait for Raymond's review.

----------
Added file: http://bugs.python.org/file31789/14927-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14927>
_______________________________________

From report at bugs.python.org  Mon Sep 16 04:11:42 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 02:11:42 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379297502.81.0.768255235261.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I do not see one.  I did post to PyDev asking about dir -- perhaps I should have given it a different title.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 04:11:58 2013
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 16 Sep 2013 02:11:58 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379297518.51.0.874106088987.issue19024@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
Removed message: http://bugs.python.org/msg197774

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Mon Sep 16 04:20:10 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 16 Sep 2013 02:20:10 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1379298010.49.0.817803533777.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

Serhiy, from a technical standpoint, your latest patch looks like a solid solution.  From an module design standpoint we still have a few options to think through, though. What if random.weighted_choice_generator was moved to random.choice_generator and refactored to take an array of weights as an optional argument?  Likewise, random.weighted_choice could still be implemented with an optional arg to random.choice.  Here's the pros and cons of each implementation as I see them.

Implementation: weighted_choice_generator + weighted_choice
Pros: 
Distinct functions help indicate that weighted_choice should be used in a different manner than choice -- [weighted_choice(x) for _ in range(n)] isn't efficient.
Can take Mapping or Sequence as argument.
Has a single parameter
Cons:
Key, not value, is returned
Requires two new functions
Dissimilar to random.choice
Long function name (weighted_choice_generator)

Implementation: choice_generator + optional arg to choice
Pros: 
Builds on existing code layout
Value returned directly
Only a single new function required
More compact function name

Cons:
Difficult to support Mappings
Two args required for choice_generator and random.choice
Users may use [choice(x, weights) for _ in range(n)] expecting efficient results

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Sep 16 04:26:28 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 16 Sep 2013 02:26:28 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379298388.42.0.0573031594593.issue19024@psf.upfronthosting.co.za>


Madison May added the comment:

http://docs.python.org/3/tutorial/controlflow.html#arbitrary-argument-lists
http://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists 

The above links do a so-so of explaining the splat operator, although I agree that the docs for '*' could be improved.

----------
nosy: +madison.may

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Mon Sep 16 04:35:35 2013
From: report at bugs.python.org (Robert M. Koretsky)
Date: Mon, 16 Sep 2013 02:35:35 +0000
Subject: [issue19033] Python 3 won't go on PC-BSD 9.1
Message-ID: <1379298935.78.0.614381300505.issue19033@psf.upfronthosting.co.za>


New submission from Robert M. Koretsky:

I use the instructions in the README file that gets unzipped with Python-3.0.tgz to install on PC-BSD 9.1
./configure, make, make test, sudo make install
and it does not work! Error messages too verbose to include here.
My path includes the directory that everything is unzipped into, and I'm executing the configure and makes from within that directory.
I am surprised that no one else has the same problem, or at least hasn't reported it. If the creation of python 3 is so difficult, why hasn't anyone come up with a clear, articulate set of instructions for PC-BSD or FreeBSD installs?

----------
components: Installation
messages: 197864
nosy: Bobk48
priority: normal
severity: normal
status: open
title: Python 3 won't go on PC-BSD 9.1
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19033>
_______________________________________

From report at bugs.python.org  Mon Sep 16 06:00:25 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Mon, 16 Sep 2013 04:00:25 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1379304025.43.0.69434659077.issue18844@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I think Storchaka's solution is more transparent and I agree with him on the point that the choice generator should be exposed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Sep 16 06:14:48 2013
From: report at bugs.python.org (Madison May)
Date: Mon, 16 Sep 2013 04:14:48 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1379304888.09.0.203127505686.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

>  I think Storchaka's solution is more transparent and I agree with him on the point that the choice generator should be exposed.

Valid point -- transparency should be priority #1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Mon Sep 16 06:26:59 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 04:26:59 +0000
Subject: [issue19030] Make inspect.getmembers and inspect.classify_class_attrs
 Enum aware
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379305619.97.0.704746169771.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Here's a crazy idea.  :)

The only reason the patch is tied to Enum is because of Enum's use of the _RouteClassAttributeToGetattr descriptor.

If we had a module similar to functools, say classtools, we could flesh out _RouteClassAttributeToGetattr, rename it to VirtualAttribute, and then it would no longer be Enum specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 06:40:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Sep 2013 04:40:08 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379306408.81.0.864905830383.issue19025@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch containing unit test only to confirm existing behaviour. So people can learn what to expect when they delete Enum attributes.

Even if we *decide* to change the behaviour of "del MyPet.CUTE_CAT" (assuming CUTE_CAT is an Enum member), I sense that we would only change the exception message not the exception type. That is, it still throws AttributeError but with better error message, such as "Cannot delete attribute."

----------
Added file: http://bugs.python.org/file31790/unit_test_attribute_deletion_enum.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Mon Sep 16 07:42:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 05:42:25 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1379310145.1.0.189204926433.issue18975@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> My vote is no separators.  But I'm just one vote :)

Seconded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Mon Sep 16 07:43:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 05:43:47 +0000
Subject: [issue19029] tix.py uses StringType
In-Reply-To: <1379278784.45.0.495441517749.issue19029@psf.upfronthosting.co.za>
Message-ID: <1379310227.32.0.548919007835.issue19029@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I guess this code executed only when wantobjects is false.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19029>
_______________________________________

From report at bugs.python.org  Mon Sep 16 08:18:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Sep 2013 06:18:05 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379312285.58.0.432855914943.issue19030@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

types is the OO equivalent to functools these days, in addition to its original role of exposing the internal type objects that aren't builtins.

However, it seems to me that the fix for issue 1785 is simply *wrong*: it eliminated the exceptions at the expense of sometimes returning the *wrong answer*. The change in that issue means the inspect module isn't implementing the descriptor protocol correctly, and thus may provide a raw descriptor object when attempting to retrieve that attribute will return something else.

Instead of the current behaviour, the inspect module should be trying getattr *first*, and only falling back to peeking in the __dict__ directly if that throws an exception.

----------
title: Make inspect.getmembers and inspect.classify_class_attrs Enum aware -> inspect.getmembers and inspect.classify_class_attrs mishandle descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 08:38:54 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 16 Sep 2013 06:38:54 +0000
Subject: [issue19015] Too long command returns 32512
In-Reply-To: <1379124071.08.0.89239994658.issue19015@psf.upfronthosting.co.za>
Message-ID: <1379313534.7.0.629577991849.issue19015@psf.upfronthosting.co.za>


Sworddragon added the comment:

I have figured out that system() in C can only take up to 65533 arguments after a command (so it is a 16 bit issue). Giving one more argument will result in the return code 32512 (which implies the exit code 127).

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19015>
_______________________________________

From report at bugs.python.org  Mon Sep 16 08:46:39 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 16 Sep 2013 06:46:39 +0000
Subject: [issue11708] argparse: suggestion for formatting optional positional
 args
In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za>
Message-ID: <1379313999.86.0.885526156449.issue11708@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11708>
_______________________________________

From report at bugs.python.org  Mon Sep 16 08:57:02 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 16 Sep 2013 06:57:02 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
Message-ID: <1379314622.34.0.0560095449424.issue13824@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13824>
_______________________________________

From report at bugs.python.org  Mon Sep 16 08:59:41 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 16 Sep 2013 06:59:41 +0000
Subject: [issue14365] argparse: subparsers,
 argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1379314781.29.0.426919925942.issue14365@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Mon Sep 16 09:00:54 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 16 Sep 2013 07:00:54 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1379314854.04.0.07699794846.issue9694@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Mon Sep 16 09:02:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 07:02:03 +0000
Subject: [issue12558] Locale-dependent exception for float width argument to
 Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1379314923.07.0.245972898817.issue12558@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I am presuming that tk truncates fractional parts as int() does; if not, use round().

Tk uses both truncated and rounded value.

$ rlwrap wish
% canvas .c
.c
% .c configure -width 10.1
% .c configure -width
-width width Width 10c 10
% .c configure -width 10.9
% .c configure -width
-width width Width 10c 11

As you can see 10.9 gives both 10c and 11.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Mon Sep 16 09:07:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 07:07:18 +0000
Subject: [issue19033] Python 3 won't go on PC-BSD 9.1
In-Reply-To: <1379298935.78.0.614381300505.issue19033@psf.upfronthosting.co.za>
Message-ID: <1379315238.17.0.494263977737.issue19033@psf.upfronthosting.co.za>


R. David Murray added the comment:

We have FreeBSD buildbots.

Python 3.0 is an ancient version of Python3 (in Internet years, at least :)  Please try again with python 3.3, the current stable version of Python3.  

If that doesn't work, you should contact the pc-bsd support, since Python3 clearly configures and builds on FreeBSD (since it works on the buildbots).   (That said, note that the FreeBSD port does have some patches that provide better integration with the FreeBSD ports system...I don't know if PC-BSD uses the ports system or not, so that might or might not be relevant.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19033>
_______________________________________

From report at bugs.python.org  Mon Sep 16 09:16:07 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Sep 2013 07:16:07 +0000
Subject: [issue19033] Python 3 won't go on PC-BSD 9.1
In-Reply-To: <1379298935.78.0.614381300505.issue19033@psf.upfronthosting.co.za>
Message-ID: <1379315767.75.0.693635502347.issue19033@psf.upfronthosting.co.za>


Ned Deily added the comment:

http://www.python.org/download/
http://www.freebsd.org/cgi/ports.cgi?query=python3&stype=all&sektion=all

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19033>
_______________________________________

From report at bugs.python.org  Mon Sep 16 09:16:32 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Sep 2013 07:16:32 +0000
Subject: [issue19033] Python 3 won't go on PC-BSD 9.1
In-Reply-To: <1379298935.78.0.614381300505.issue19033@psf.upfronthosting.co.za>
Message-ID: <1379315792.94.0.225834996004.issue19033@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
status: open -> closed
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19033>
_______________________________________

From report at bugs.python.org  Mon Sep 16 09:27:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 07:27:35 +0000
Subject: [issue12558] Locale-dependent exception for float width argument to
 Tkinter widget constructor
In-Reply-To: <1310655906.95.0.630445767575.issue12558@psf.upfronthosting.co.za>
Message-ID: <1379316455.43.0.353903290332.issue12558@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry, 10c is unrelated. Tk uses rounding. I don't know if it requires somewhere actual non-integer values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12558>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:04:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Sep 2013 08:04:32 +0000
Subject: [issue19029] tix.py uses StringType
In-Reply-To: <1379278784.45.0.495441517749.issue19029@psf.upfronthosting.co.za>
Message-ID: <3cdg340tWpz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 9eab3e745061 by Serhiy Storchaka in branch '3.3':
Issue #19029: Change non-existing since 3.0 StringType to str.
http://hg.python.org/cpython/rev/9eab3e745061

New changeset 95b3efe3d7b7 by Serhiy Storchaka in branch 'default':
Issue #19029: Change non-existing since 3.0 StringType to str.
http://hg.python.org/cpython/rev/95b3efe3d7b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19029>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:29:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Sep 2013 08:29:31 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1379320171.29.0.0694600684117.issue18975@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm fine with the change too. Tim, what do you think?

Speaking of which, some examples were really done with an old machine:

    $ python -m timeit 'try:' '  str.__bool__' 'except AttributeError:' '  pass'
-   100000 loops, best of 3: 15.7 usec per loop
+   1000000 loops, best of 3: 0.701 usec per loop (1425528 loops/s)

:-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:36:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Sep 2013 08:36:50 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379320610.32.0.0643181219351.issue19030@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> However, it seems to me that the fix for issue 1785 is simply *wrong*: it eliminated the exceptions at the expense of sometimes returning the *wrong answer*.

The underlying problem is that those functions are not very well-specified (actually, classify_class_attrs() is not specified at all: it's undocumented).  The main consumer of inspect in the stdlib is pydoc, and pydoc being broken by third-party libraries with non-trivial descriptors was a major nuisance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:40:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Sep 2013 08:40:25 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>
Message-ID: <1379320825.79.0.540564025974.issue19032@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't really know. It simply looks like the default implementation of __reduce_ex__. Is it important?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:47:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 08:47:32 +0000
Subject: [issue19034] More useful repr for Tcl_Obj
Message-ID: <1379321252.25.0.835083719717.issue19034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently the repr() for Tcl_Obj is not very useful. It exposes only Tcl type name and Tcl object address.

>>> import tkinter.ttk
>>> tv = tkinter.ttk.Treeview()
>>> tv.tag_configure('test', foreground='blue')
{}
>>> str(tv.tag_configure('test', 'foreground'))
'blue'
>>> tv.tag_configure('test', 'foreground')
<color object at 0xb70f84b8>

You need explicitly call str to get more useful information. This is awkward when Tcl object hidden deeply in tuples or other data structure, or reported in a backtrace. Actually every Tcl object can be represented as a string. I propose to expose this representation in repr(). With proposed patch the output of the last command will be: <color object: 'blue'>.

----------
components: Tkinter
files: tkinter_repr.patch
keywords: patch
messages: 197881
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: More useful repr for Tcl_Obj
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31791/tkinter_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19034>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:51:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 08:51:36 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1379321496.22.0.947235439616.issue18975@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Inconsistency: "sec per loop" vs. "loops/s".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Mon Sep 16 10:52:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 08:52:19 +0000
Subject: [issue19029] tix.py uses StringType
In-Reply-To: <1379278784.45.0.495441517749.issue19029@psf.upfronthosting.co.za>
Message-ID: <1379321539.46.0.916451796105.issue19029@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19029>
_______________________________________

From report at bugs.python.org  Mon Sep 16 11:02:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Sep 2013 09:02:46 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379320610.32.0.0643181219351.issue19030@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dYuNE1dNWtPqgBARg7TxU9+uSAFCmeLN3pqAXuEkZBGg@mail.gmail.com>


Nick Coghlan added the comment:

Right, we definitely want inspect to swallow the exceptions from
descriptors. My suggestion is merely to switch the order to be:
1. Try getattr
2. If that throws an exception, check __dict__ directly
3. If neither works (e.g. due to a buggy __dir__ method), ignore the
attribute entirely.

The problem at the moment is *working* descriptors that are designed to
fall back on the metaclass lookup are being mishandled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 11:06:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Sep 2013 09:06:24 +0000
Subject: [issue19030] inspect.getmembers and
 inspect.classify_class_attrs	mishandle descriptors
In-Reply-To: <CADiSq7dYuNE1dNWtPqgBARg7TxU9+uSAFCmeLN3pqAXuEkZBGg@mail.gmail.com>
Message-ID: <1644809202.66595338.1379322378470.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Right, we definitely want inspect to swallow the exceptions from
> descriptors. My suggestion is merely to switch the order to be:
> 1. Try getattr
> 2. If that throws an exception, check __dict__ directly
> 3. If neither works (e.g. due to a buggy __dir__ method), ignore the
> attribute entirely.

Are you talking about descriptors defined on the class or the metaclass? :-)

----------
title: inspect.getmembers and inspect.classify_class_attrs mishandle descriptors -> inspect.getmembers and inspect.classify_class_attrs	mishandle descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 11:54:48 2013
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 16 Sep 2013 09:54:48 +0000
Subject: [issue18975] timeit: Use thousands separators and print number of
 loops per second
In-Reply-To: <1378656031.3.0.527824204676.issue18975@psf.upfronthosting.co.za>
Message-ID: <1379325288.98.0.0235482475377.issue18975@psf.upfronthosting.co.za>


Jakub Stasiak added the comment:

That's right, I was actually wondering about it few minutes before you pointed it out. Find new patch attached.

----------
Added file: http://bugs.python.org/file31792/timeit-v4-actual-changes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18975>
_______________________________________

From report at bugs.python.org  Mon Sep 16 12:17:04 2013
From: report at bugs.python.org (Akira Kitada)
Date: Mon, 16 Sep 2013 10:17:04 +0000
Subject: [issue1065986] Fix pydoc crashing on unicode strings
Message-ID: <1379326624.72.0.555691249744.issue1065986@psf.upfronthosting.co.za>


Akira Kitada added the comment:

Attaching a modified version of issue1065986.patch.
The differences are:

- Added _binstr(), which is str() that works with unicode objects.
- Changed getdoc() to return encoded docstrings/comments
- Used _binstr() to convert __version__, __date__, __author__ and
  __credits__ to str

----------
Added file: http://bugs.python.org/file31793/issue1065986-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1065986>
_______________________________________

From report at bugs.python.org  Mon Sep 16 12:29:32 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 16 Sep 2013 10:29:32 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>
Message-ID: <1379327372.1.0.210513446716.issue19032@psf.upfronthosting.co.za>


Ram Rachum added the comment:

I use that to test whether an object is pickleable or not. It used to work in Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Mon Sep 16 12:30:49 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 Sep 2013 10:30:49 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379327449.49.0.133538687865.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

If we're sure suite._cleanupis a *good* api for this then fine to expose it (and document) it as a public api. I'll take a look at it in a bit. 

Test suites will still have to do *some* monkeying around to set suite.cleanup (presumably in load_tests), so I'm not sure it's much more convenient...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Mon Sep 16 12:33:13 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 Sep 2013 10:33:13 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <1379327593.76.0.629301183309.issue19016@psf.upfronthosting.co.za>


Michael Foord added the comment:

The problem is that the change you're proposing is backwards incompatible. Code using MagicMock and objects with length will break.

----------
assignee:  -> michael.foord
versions: +Python 3.4 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Mon Sep 16 12:40:45 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 Sep 2013 10:40:45 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1379328045.13.0.116017648734.issue18996@psf.upfronthosting.co.za>


Michael Foord added the comment:

Awesome, thanks for this work. 

The only thing I'd say is that if  _common_shorten is always called with two args - and safe_repr is always called on them - then why not have it take two args and call safe_repr on them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Mon Sep 16 12:51:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Sep 2013 10:51:05 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <CADiSq7dYuNE1dNWtPqgBARg7TxU9+uSAFCmeLN3pqAXuEkZBGg@mail.gmail.com>
Message-ID: <CADiSq7fOp49JtOc+=gpENr4vNpqp3fLBFykZUagT6Kra0Tz0WQ@mail.gmail.com>


Nick Coghlan added the comment:

On the class, since that's the case which is breaking here (instances are
already OK, since they trigger the success path in the custom descriptors)

----------
title: inspect.getmembers and inspect.classify_class_attrs	mishandle descriptors -> inspect.getmembers and inspect.classify_class_attrs mishandle descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 13:36:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Sep 2013 11:36:12 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379327372.1.0.210513446716.issue19032@psf.upfronthosting.co.za>
Message-ID: <97561673.67028860.1379331366550.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I use that to test whether an object is pickleable or not. It used to
> work in Python 2.

Well, the obvious way to do it would be to call pickle.dumps() on
the object, IMO :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Mon Sep 16 13:38:45 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 16 Sep 2013 11:38:45 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>
Message-ID: <1379331525.1.0.671606709836.issue19032@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Wrong, because the object itself could be pickleable but refer to a different object which is non-pickleable. I want to know whether the object itself, without any object it refers to, is pickleable.

Also, pickling an object could be very resource-intensive, depending on its size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Mon Sep 16 13:58:44 2013
From: report at bugs.python.org (Brecht Van Lommel)
Date: Mon, 16 Sep 2013 11:58:44 +0000
Subject: [issue16129] No good way to set 'PYTHONIOENCODING' when embedding
 python.
In-Reply-To: <1349355495.01.0.406130423626.issue16129@psf.upfronthosting.co.za>
Message-ID: <1379332724.25.0.857346569961.issue16129@psf.upfronthosting.co.za>


Brecht Van Lommel added the comment:

With the language summit passed some time ago, is there now a more clear picture of how this would fit in the initialisation process?

Any idea of what a proper implementation would look like, or is the message still to wait?

----------
nosy: +Brecht.Van.Lommel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16129>
_______________________________________

From report at bugs.python.org  Mon Sep 16 14:45:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Sep 2013 12:45:49 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379331525.1.0.671606709836.issue19032@psf.upfronthosting.co.za>
Message-ID: <592689831.67189616.1379335542825.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Wrong, because the object itself could be pickleable but refer to a
> different object which is non-pickleable. I want to know whether the
> object itself, without any object it refers to, is pickleable.

I think you're being too picky. Unless you're manually added stuff
to your Lock's attributes, there isn't a practical difference between
the two situations.

> Also, pickling an object could be very resource-intensive, depending
> on its size.

Well, this is a Lock here, not an ISO file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Mon Sep 16 14:47:11 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 Sep 2013 12:47:11 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379335631.06.0.223335792556.issue14984@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

@RDM: Please commit to 2.6 and null merge to 2.7.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep 16 15:32:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 13:32:16 +0000
Subject: [issue18050] embedded interpreter or virtualenv fails with
 "ImportError: cannot import name MAXREPEAT"
In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za>
Message-ID: <1379338336.87.0.61951917902.issue18050@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Well. While the running different versions of binaries and Python files is not a good idea, perhaps we can apply this change. But only for 2.7 and 3.3. There is no need in this garbage in 3.4.

I'm still not sure that there are no other inconsistencies between old static binaries and newer Python files.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
versions:  -Python 3.4
Added file: http://bugs.python.org/file31794/sre_MAXREPEAT.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18050>
_______________________________________

From report at bugs.python.org  Mon Sep 16 15:51:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Sep 2013 13:51:08 +0000
Subject: [issue18985] Improve the documentation in fcntl module
In-Reply-To: <1378722919.93.0.901392318122.issue18985@psf.upfronthosting.co.za>
Message-ID: <1379339468.79.0.745822091747.issue18985@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Updated patch based on Ezio's review. I reverted back the changes to Nul and module documentation (since it is not so clear whether we should categorize flock as Unix routine or not).

----------
Added file: http://bugs.python.org/file31795/fix_documentation_on_fcntl_module_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18985>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:12:54 2013
From: report at bugs.python.org (Alexey Umnov)
Date: Mon, 16 Sep 2013 14:12:54 +0000
Subject: [issue19035] tokenize.generate_tokens treat '\f' symbol as the end of
 file (when reading in unicode)
Message-ID: <1379340774.03.0.601384573394.issue19035@psf.upfronthosting.co.za>


New submission from Alexey Umnov:

I execute the following code on the attached file 'text.txt':


import tokenize
import codecs

with open('text.txt', 'r') as f:
    reader = codecs.getreader('utf-8')(f)
    tokens = tokenize.generate_tokens(reader.readline)


The file 'text.txt' has the following structure: first line with some text, then '\f' symbol (0x0c) on the second line and then some text on the last line. The result is that the function 'generate_tokens' ignores everything after '\f'.

I've made some debugging and found out the following. If the file is read without using codecs (in ascii-mode), there are considered to be 3 lines in the file: 'text1\n', '\f\n', 'text2\n'. However in unicode-mode there are 4 lines: 'text1\n', '\f', '\n', 'text2\n'. I guess this is an intended behaviour since 2.7.x, but this causes a bug in tokenize module.

Consider the lines 317-329 in tokenize.py:

...
column = 0
while pos < max:                   # measure leading whitespace
    if line[pos] == ' ':
        column += 1
    elif line[pos] == '\t':
        column = (column//tabsize + 1)*tabsize
    elif line[pos] == '\f':
        column = 0
    else:
        break
    pos += 1
if pos == max:
    break
...

The last 'break' corresponds to the main parsing loop and makes the parsing stop. Thus the lines that consist of (' ', '\t', '\f') characters and don't end with '\n' are treated as the end of file.

----------
components: Library (Lib)
files: tokens.txt
messages: 197899
nosy: Alexey.Umnov
priority: normal
severity: normal
status: open
title: tokenize.generate_tokens treat '\f' symbol as the end of file (when reading in unicode)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31796/tokens.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19035>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:18:44 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 16 Sep 2013 14:18:44 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1379341124.87.0.986966625299.issue18857@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

No problem, David, working on these patches is just an occasion for me to learn more and be useful at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:21:58 2013
From: report at bugs.python.org (R. Jayakrishnan)
Date: Mon, 16 Sep 2013 14:21:58 +0000
Subject: [issue18704] IDLE: PEP8 Style Check Integration
In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za>
Message-ID: <1379341318.77.0.0326784343074.issue18704@psf.upfronthosting.co.za>


R. Jayakrishnan added the comment:

I would prefer this issue concludes with a navigation to the new proposed enhancement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:31:38 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 14:31:38 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379341898.19.0.933877435503.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Switching the order to try getattr first is going to make getting the doc from the descriptor problematic -- we have no way of knowing if the descriptor doc goes with the object we got back from getattr.

Current patch adds VirtualAttribute to types, and reworks inspect.classify_class_attrs, inspect.getmembers, and Enum to use that instead of _RouteClassAttributeToGetattr (which has been removed).

Tests are still needed for the new VirtualAttribute.

Not sure VirtualAttribute is the best name; other ideas:

  - InstanceProperty
  - AttributeProperty
  - HiddenClassProperty

----------
stage:  -> patch review
Added file: http://bugs.python.org/file31797/issue19030.stoneleaf.02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:39:27 2013
From: report at bugs.python.org (irdb)
Date: Mon, 16 Sep 2013 14:39:27 +0000
Subject: [issue1519638] Unmatched Group issue - workaround
Message-ID: <1379342367.36.0.622743572335.issue1519638@psf.upfronthosting.co.za>


Changes by irdb <dalba.wiki at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519638>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:48:26 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Sep 2013 14:48:26 +0000
Subject: [issue16129] No good way to set 'PYTHONIOENCODING' when embedding
 python.
In-Reply-To: <1349355495.01.0.406130423626.issue16129@psf.upfronthosting.co.za>
Message-ID: <1379342906.15.0.844169909346.issue16129@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The gory details of the current startup situation are in PEP 432. However, the comprehensive solution described in that PEP isn't going to make it into Python 3.4, so a simpler interim fix would be worthwhile.

Since Blender is designed to support building against the system Python, the trick of forcing Python to link to an alternate implementation of a function won't work.

Inspired by http://docs.python.org/3/c-api/init.html#Py_SetPath, I suggest offering an API like:

int Py_SetStandardStreamEncoding(char *encoding, char *errors)
{
    if (Py_IsInitialized()) {
        return -1;
    }
    Py_StandardStreamEncoding = _PyMem_Strdup(encoding);
    Py_StandardStreamErrors = _PyMem_Strdup(errors);
}

The initstdio function in pythonrun.c would then be updated to use the specified Py_StandardStreamEncoding and Py_StandardStreamErrors if they weren't NULL (since that would indicate an embedding application had called SetStandardStreamEncoding).

----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16129>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:48:56 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Mon, 16 Sep 2013 14:48:56 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1379342936.45.0.980983044029.issue18857@psf.upfronthosting.co.za>


Joshua Johnston added the comment:

I know that languages like php will treat ?josh= the same as ?josh

Using the attached test form in Google Chrome, you will see the data passed as josh= when empty in both GET and POST requests. This is probably the way to go, key=str(value) if value is not None else ''

----------
Added file: http://bugs.python.org/file31798/test.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:49:22 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 16 Sep 2013 14:49:22 +0000
Subject: [issue18526] Add resource management/guarding to unittest
In-Reply-To: <1374470490.47.0.980625465837.issue18526@psf.upfronthosting.co.za>
Message-ID: <1379342962.69.0.766029476609.issue18526@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Having thought about this more, I think I agree that this is the wrong approach to the issue and that a more general ability to add command line options to unittest would be better.  Closing this issue.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18526>
_______________________________________

From report at bugs.python.org  Mon Sep 16 16:51:17 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Sep 2013 14:51:17 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379341898.19.0.933877435503.issue19030@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dkrYgG6CfvWnuf-ocpFaRWAaG3QMo4LFbsH+jdp9Dbwg@mail.gmail.com>


Nick Coghlan added the comment:

The current behaviour is broken for *any* descriptor which doesn't
return itself when retrieved from the class. It just so happens that
all the *other* descriptors in the standard library work that way, so
it doesn't matter if you retrieve them directly from __dict__ or
retrieve them with getattr - you'll get the descriptor object either
way.

So we should be calling getattr first, and always taking __doc__ (if
any) from the returned object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 16 17:05:31 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 16 Sep 2013 15:05:31 +0000
Subject: [issue18948] deliberately crashing tests should prevent core dumps
In-Reply-To: <1378493765.27.0.466855736327.issue18948@psf.upfronthosting.co.za>
Message-ID: <1379343931.29.0.234534778952.issue18948@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Perhaps it would be best to either combine SuppressCoreFiles and suppress_crash_popup, or provide a new construct that does so since both are used in almost every place one is used.  Also, test_daemon_threads_fatal_error in test_threading should be using suppress_crash_popup, but isn't currently, which I believe falls under the scope of this issue.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18948>
_______________________________________

From report at bugs.python.org  Mon Sep 16 17:12:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 15:12:58 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379344378.34.0.771982280824.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, I was planning to merge it, since 2.7 needs the fix as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep 16 17:18:44 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 Sep 2013 15:18:44 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1379344378.34.0.771982280824.issue14984@psf.upfronthosting.co.za>
Message-ID: <20130916111841.70ebcfd6@anarchist>


Barry A. Warsaw added the comment:

On Sep 16, 2013, at 03:12 PM, R. David Murray wrote:

>Well, I was planning to merge it, since 2.7 needs the fix as well.

Oh yeah, that's fine of course.  And thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep 16 17:28:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 15:28:49 +0000
Subject: [issue19035] tokenize.generate_tokens treat '\f' symbol as the end of
 file (when reading in unicode)
In-Reply-To: <1379340774.03.0.601384573394.issue19035@psf.upfronthosting.co.za>
Message-ID: <1379345329.24.0.401578771261.issue19035@psf.upfronthosting.co.za>


R. David Murray added the comment:

I suspect this isn't the only place where the change in what is considered a (unicode) line ending character between 2.6 and 2.7/python3 is an issue.  As you observe, it causes very subtle bugs.  I'm going to have to go trolling through the python3 email package looking for places where this could break things :(.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19035>
_______________________________________

From report at bugs.python.org  Mon Sep 16 17:58:13 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 15:58:13 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1379347093.7.0.581168072692.issue17226@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

This works for me...

--- configure.ac.old    2013-09-10 14:37:20.000000000 +0000
+++ configure.ac        2013-09-10 14:56:27.000000000 +0000
@@ -2190,7 +2190,11 @@
 AC_CHECK_LIB(intl, textdomain,
        [AC_DEFINE(WITH_LIBINTL, 1,
        [Define to 1 if libintl is needed for locale functions.])
-        LIBS="-lintl $LIBS"])
+        LIBS="-lintl $LIBS"],
+       [AC_SEARCH_LIBS(textdomain, intl,
+               [AC_DEFINE(WITH_LIBINTL, 1,
+               [Define to 1 if libintl is needed for locale functions.])
+               LIBS="-lintl -liconv $LIBS"], , "-liconv")])
 
 # checks for system dependent C++ extensions support
 case "$ac_sys_system" in

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Mon Sep 16 17:59:02 2013
From: report at bugs.python.org (Sam Ferencik)
Date: Mon, 16 Sep 2013 15:59:02 +0000
Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python
 on	a	64-bit machine
In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za>
Message-ID: <1379347142.07.0.854286493647.issue18987@psf.upfronthosting.co.za>


Sam Ferencik added the comment:

Thanks for the context.

> A compatibility issue here is that the value provided by get_platform() is
> also used outside of Distutils, in particular by pkg_resources (provided by
> setuptools) and by pip, in both cases to help determine whether a binary
> distribution of an extension module is compatible with the python being used.

If your wording is correct, and get_platform() really is used to determine "the
python being used," then we could actually be improving things by fixing this.
Currently, get_platform() doesn't tell you the bitness of the *python* being
used, but the bitness of the *OS* being used (the two of which only differ on
32-on-64).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18987>
_______________________________________

From report at bugs.python.org  Mon Sep 16 18:01:54 2013
From: report at bugs.python.org (Shawn Krisman)
Date: Mon, 16 Sep 2013 16:01:54 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <1379347314.59.0.129946783332.issue19016@psf.upfronthosting.co.za>


Shawn Krisman added the comment:

Yeah in my head I was thinking it would affect relatively few people who depended on the change, but it's definitely hard to prove that!

How about a change that special cases namedtuple?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Mon Sep 16 18:02:37 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 16:02:37 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
Message-ID: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

Patch....

--- Python/fileutils.c.old	2013-09-11 07:04:42.000000000 +0000
+++ Python/fileutils.c	2013-09-11 07:05:01.000000000 +0000
@@ -4,8 +4,8 @@
 #  include <windows.h>
 #endif
 
-#ifdef HAVE_LANGINFO_H
 #include <locale.h>
+#ifdef HAVE_LANGINFO_H
 #include <langinfo.h>
 #endif

----------
components: Build
messages: 197914
nosy: alanh
priority: normal
severity: normal
status: open
title: setlocale fails due to locale.h being wrapped up in LANGINFO check.
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 18:08:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 16:08:07 +0000
Subject: [issue18230] test_builtin fails/hangs when run after test_getopt
In-Reply-To: <1371395860.64.0.905722760068.issue18230@psf.upfronthosting.co.za>
Message-ID: <1379347687.39.0.983560083601.issue18230@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, it is related. test_getopt uses doctests, doctest uses pdb, pdb imports readline.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
status: open -> closed
superseder:  -> readline-related test_builtin failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18230>
_______________________________________

From report at bugs.python.org  Mon Sep 16 18:10:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 16:10:30 +0000
Subject: [issue17734] Failure when running test_builtin after test_genexps
In-Reply-To: <1366029613.93.0.971367432491.issue17734@psf.upfronthosting.co.za>
Message-ID: <1379347830.7.0.330544744649.issue17734@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes. test_genexps uses doctests, doctest uses pdb, pdb imports readline.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
status: open -> closed
superseder:  -> readline-related test_builtin failure

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17734>
_______________________________________

From report at bugs.python.org  Mon Sep 16 18:33:26 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Sep 2013 16:33:26 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>
Message-ID: <1379349206.37.0.502072051064.issue19017@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Interesting issue.  ISTM that closing the FD before unregistering it is a programmer's mistake that shouldn't pass silently.  And closing it in a separate thread while the selector is active sounds like an even bigger bug.

Could we report an new event type for this situation?  E.g. EVENT_CLOSED.  The proper response would be to unregister the FD.  (And yes, unregistering the FD when it was previously registered should not be an error, even if it has been closed.)

I'm not sure I care that there will be an infinite loop if the caller doesn't take action -- it's the same for any event, if you don't read from an FD when you get an EVENT_READ event, you'll get an infinite loop too.

Note that this is not exactly the same as the "invalid fd" that Victor proposes -- although they aren't always distinguishable, the logic errors in the app are different: in one case, closing a FD (that was valid and registered) without unregistering, in the other case, registering an FD that isn't valid.  (Ideally the register() call should fail, but I suppose we can't detect that without an extra syscall -- although in some cases there's a syscall in register() anyway, and then we can use that to reject the register() call.

----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Mon Sep 16 18:44:24 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 16 Sep 2013 16:44:24 +0000
Subject: [issue18961] Non-UTF8 encoding line
In-Reply-To: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>
Message-ID: <1379349864.98.0.587148402272.issue18961@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Terry: the comment isn't self-contradictory. Instead, the file constitutes a perfectly fine iso-8859-15 byte sequence (albeit a meaningless one: any byte sequence is perfectly fine iso-8559-15, and, in a comment, any characters are allowed by the Python syntax).

AFAICT, the file also follows the wording of PEP 263, as it does not disallow additional text on the encoding line. Therefore, I think tokenize should accept the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18961>
_______________________________________

From report at bugs.python.org  Mon Sep 16 19:06:22 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 16 Sep 2013 17:06:22 +0000
Subject: [issue18626] Make "python -m inspect <name>" meaningful
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <1379351182.64.0.764936309437.issue18626@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello, here's a basic patch. Currently, the header info is printed by default, while the source can be retrieved by using --source (although I would prefer them to be switched, the source should be shown by default and the header info only when requested). It understands the entry point notation, like 'unittest:util.safe_repr'.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31799/inspect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18626>
_______________________________________

From report at bugs.python.org  Mon Sep 16 19:39:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 17:39:46 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379353186.19.0.987172431671.issue19036@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you provide more information about the circumstances in which this is a problem?  Presumably there is a reason why the code is currently the way it is, especially since it is done this way in several of the source files, and has been that way for a *long* time.

----------
assignee:  -> lemburg
nosy: +lemburg, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 19:41:01 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 16 Sep 2013 17:41:01 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379353261.34.0.605255647485.issue16038@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Looks legitimate to me. I will come up with a separate patch for later Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:10:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 18:10:28 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379355028.08.0.320757828583.issue19036@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oops, didn't mean to assign this to anyone.

----------
assignee: lemburg -> 
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:24:36 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 18:24:36 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379355876.83.0.670228966151.issue19036@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

Sure, Look in the function.....

check_force_ascii()

You'll see a hunk of code that is ifdef'd for ...

#if defined(HAVE_LANGINFO_H) && defined(CODESET)

Then you'll see 

setlocale()

is called outside of that check, just before another hunk of code is
ifdef'd with the same....

#if defined(HAVE_LANGINFO_H) && defined(CODESET)

Basically making setlocale() outside of the check, and therefore requiring the #include <locale.h> outside of the above check as well.

In pythonrun.c the setlocale() call is already wrapped inside the #ifdef so the problem is bumped into there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:25:19 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 18:25:19 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379355919.86.0.964244063881.issue19036@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

Oops, meant to say.....


In pythonrun.c the setlocale() call is already wrapped inside the #ifdef so the problem ISN'T bumped into there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:27:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 18:27:41 +0000
Subject: [issue18961] Non-UTF8 encoding line
In-Reply-To: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>
Message-ID: <1379356061.32.0.278272788036.issue18961@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about first line? Currently both Python interpreter and the tokenize module decode it from UTF-8 (actually due to bug #18960 Python interprets it twice, in different encodings). PEP 263 says:

    1. The complete Python source file should use a single encoding.
       Embedding of differently encoded data is not allowed and will
       result in a decoding error during compilation of the Python
       source code.

I conclude that the first line should be decoded with the encoding specified in the second line. We first should read the first line, check if it isn't a comment or contains encoding cookie, otherwise read the second line, determine the encoding, and decode read lines. Perhaps it will untangle issue18960 too.

----------
assignee:  -> serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18961>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:35:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Sep 2013 18:35:03 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <3cdx2Z0ctYz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset e5c4eb6b8e05 by R David Murray in branch '2.6':
#14984: On POSIX, enforce permissions when reading default .netrc.
http://hg.python.org/cpython/rev/e5c4eb6b8e05

New changeset 2e19c65d6688 by R David Murray in branch '2.7':
Merge #14984: On POSIX, enforce permissions when reading default .netrc.
http://hg.python.org/cpython/rev/2e19c65d6688

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:36:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 18:36:41 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379356601.21.0.0775967769092.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Removing 2.6 and 2.7 from versions since it is now fixed there.  I'll work on porting it to python3.

----------
versions:  -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:41:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 18:41:23 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379356883.17.0.297821189945.issue19036@psf.upfronthosting.co.za>


R. David Murray added the comment:

So the real problem is that the setlocale call is outside the ifdef, which means Victor is the right person to look at this, since it was his patch that introduced the code in question.  I'll remove MAL from nosy, since I only added him by accident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:41:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 18:41:34 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379356894.52.0.237991190215.issue19036@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:41:52 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 16 Sep 2013 18:41:52 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379349206.37.0.502072051064.issue19017@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1Y4EwANX4SC-0cJ7GS3she-SarzSQ23Ua6Za=C6EsJwQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Interesting issue.  ISTM that closing the FD before unregistering it is a programmer's mistake that shouldn't pass silently.  And closing it in a separate thread while the selector is active sounds like an even bigger bug.

Agreed.

> Could we report an new event type for this situation?  E.g. EVENT_CLOSED.  The proper response would be to unregister the FD.  (And yes, unregistering the FD when it was previously registered should not be an error, even if it has been closed.)

The problem is that for epoll (and kqueue I think) the FD is
automagically removed from the backend, which means that we won't get
any notification for this FD, hence we're unable to report it as
closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:57:17 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Sep 2013 18:57:17 +0000
Subject: [issue18960] First line can be executed twice
In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>
Message-ID: <1379357837.54.0.560350971557.issue18960@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18960>
_______________________________________

From report at bugs.python.org  Mon Sep 16 20:58:36 2013
From: report at bugs.python.org (janzert)
Date: Mon, 16 Sep 2013 18:58:36 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
Message-ID: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>


New submission from janzert:

The Maildir.add and Maildir.__setitem__ methods in the mailbox module attempts to change the file mtime after moving the file into the new directory. This allows a race condition since other programs are can move or otherwise modify the file as soon as it is placed in the new directory. If the file is moved from the new directory before the mtime is set this results in an unexpected OSError exception.

The fix seems to simply be setting the file mtime before moving the file into its final position.

----------
components: Library (Lib)
messages: 197930
nosy: janzert, petri.lehtinen
priority: normal
severity: normal
status: open
title: mailbox module modifies maildir file times after moving from tmp directory
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:03:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 19:03:55 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379358235.17.0.548402111168.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

The patch for 3.1 is very close to the 2.7 patch, and is attached.

Benjamin and Georg, I'd like to apply this to 3.1 and merge it up through default.  May I and can I?

----------
Added file: http://bugs.python.org/file31800/netrc-py3.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:04:54 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Sep 2013 19:04:54 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>
Message-ID: <1379358294.26.0.73253292702.issue19017@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

> The problem is that for epoll (and kqueue I think) the FD is
> automagically removed from the backend, which means that we won't get
> any notification for this FD, hence we're unable to report it as
> closed.

That makes it sound like it will be hard to respond the same way on all platforms. :-(

Even silently removing the registration for select and poll still leaves the behavior different: if you register a bad FD with select or poll, the register() call will accept it but the select() call will silently remove it; however if you register a bad FD with epoll or kqueue, register() will raise EBADF.

I would prefer to see an EBADF exception in all four cases, even if it happens in register() for some platforms and in select() for others.

There is also the issue of trying to unregister (or modify?) an FD that has gone bad after successful registration -- this will also have different behavior on the different platform, right?

Maybe we'll get better design guidance if we look at this from the POV of a server loop that doesn't fully control the code that may be registering and unregistering FDs.  It seems a good idea to make it so that if some bad piece of code tries to register a bad FD or close a FD without unregistering doesn't bring down the entire server, but the bad code always sees an exception.  Maybe we should be silent in select() but cause unregister() to fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:10:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 19:10:11 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379358611.98.0.672166548313.issue19037@psf.upfronthosting.co.za>


R. David Murray added the comment:

That sounds reasonable.  Would you be interested in trying your hand at a patch, ideally with a test?

----------
components: +email
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:17:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 19:17:18 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1379359038.43.0.812307696465.issue18996@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed, I'll rename _common_shorten() to _common_shorten_repr() and call safe_repr() inside. As for two vs multiple args, first I wrote a variant with two args (you can see it in my first unlinked patch), but then I seen that general variant is not harder and even shorter.

I'm open for bikeshedding. Perhaps we should change the placeholder to something better (e.g. to "[... skipped ...]")? Is the number of skipped characters is useful? Note that it is a number of skipped characters in the repr, not in the original strings and can be misguided for strings. Perhaps we should change minimal lengths of head, tail, and interior part? Why part is most important and should be larger? Perhaps add a keyword-only parameter maxlen (or other parameters for customization)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:25:44 2013
From: report at bugs.python.org (janzert)
Date: Mon, 16 Sep 2013 19:25:44 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379359544.09.0.127453460645.issue19037@psf.upfronthosting.co.za>


janzert added the comment:

I can certainly write a patch if wanted. It should be simply moving and modifying two lines in each of the two methods. My understanding is that it should be against 2.7 so it can be applied there first then merged forward?

Unfortunately while I can consistently reproduce the problem, with a script using pyinotify, I'm pretty lost how to write a test that would catch this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:35:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 19:35:35 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379360135.39.0.813943260423.issue19036@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like a real issue, but on which platform did you get the error?

> setlocale fails due to locale.h being wrapped up in LANGINFO check.

What do you mean by "fail"? Is it an error at runtime? Or during the compilation?

--

The include was added recently:

changeset:   81257:c256764e2b3f
branch:      3.2
parent:      81253:c4a4863b85b2
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Thu Jan 03 01:08:58 2013 +0100
files:       Misc/NEWS Objects/unicodeobject.c Python/fileutils.c
description:
Issue #16455: On FreeBSD and Solaris, if the locale is C, the
ASCII/surrogateescape codec is now used, instead of the locale encoding, to
decode the command line arguments. This change fixes inconsistencies with
os.fsencode() and os.fsdecode() because these operating systems announces an
ASCII locale encoding, whereas the ISO-8859-1 encoding is used in practice.


The commit was integrated in Python 3.2.5 and Python 3.3.2 .

If I remember correctly, I copied/pasted the code from Python/pythonrun.c:

#ifdef HAVE_LANGINFO_H 
#include <locale.h>
#include <langinfo.h>
#endif

Many other files use "#include <locale.h>" without #ifdef HAVE_LANGINFO_H: Modules/main.c, Modules/python.c, Modules/readline.c, Python/frozenmain.c, Python/pystrtod.c and Modules/_localemodule.c. The #include in Modules/main.c was added 5 years ago by changeset 22a74eaf6b22.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:36:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 19:36:55 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379360215.93.0.951132246548.issue19036@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:37:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 19:37:16 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379360236.16.0.412742777897.issue19036@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh by the way, please attach the patch as a file to the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:41:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 19:41:55 +0000
Subject: [issue18960] First line can be executed twice
In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za>
Message-ID: <1379360515.14.0.950052577924.issue18960@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It also makes non-working a common idiom for running Python files on Windows. When add first line "@python -x", it will be interpreted by Python and will cause SyntaxError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18960>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:46:33 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 19:46:33 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379360793.91.0.983387473402.issue19036@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

Yes, it's a "Build" issue as mentioned using the "Components" field.

But cut & pasting from other files is incorrect in this case because setlocale() is still used outside of the #ifdef.

File attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file31801/python-3.3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:50:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 19:50:40 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379361040.24.0.613041812367.issue19036@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Yes, it's a "Build" issue as mentioned using the "Components" field.

Again, what is your platform (OS name, OS version)?

What is the compiler error message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 21:51:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Sep 2013 19:51:35 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379361095.5.0.274783797523.issue19037@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hopefully a 2.7 patch would also apply to 3.3, so yes, start there.

For the test, I was thinking that in 3.3+ we could use mock to introduce a delay.  But looking at the code again it isn't obvious that there is a meaningful way to do it that is worth the effort required.  So let's forget about the test for this one...a comment about why the time set is done before the move would be worthwhile, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Mon Sep 16 22:03:11 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 16 Sep 2013 20:03:11 +0000
Subject: [issue19036] setlocale fails due to locale.h being wrapped up in
 LANGINFO check.
In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za>
Message-ID: <1379361791.49.0.733492906803.issue19036@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

You'll see the error on any platform that doesn't include "locale.h" when it should, i.e. a platform that doesn't have NL_LANGINFO. This is the build error.....

Python/fileutils.c: In function 'check_force_ascii':
Python/fileutils.c:101:5: warning: implicit declaration of function 'setlocale' [-Wimplicit-function-declaration]
Python/fileutils.c:101:21: error: 'LC_CTYPE' undeclared (first use in this function)
Python/fileutils.c:101:21: note: each undeclared identifier is reported only once for each function it appears in

You can simulate it on Linux, by just commenting out the #include for "locale.h" and voila.

But for completeness, it's an m68k Atari platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19036>
_______________________________________

From report at bugs.python.org  Mon Sep 16 22:18:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Sep 2013 20:18:26 +0000
Subject: =?utf-8?q?=5Bissue17003=5D_Unification_of_read=28=29=C2=A0and_readline=28?=
 =?utf-8?q?=29_argument_names?=
In-Reply-To: <1358698394.54.0.180835263252.issue17003@psf.upfronthosting.co.za>
Message-ID: <3cdzKs2vnqzS13@mail.python.org>


Roundup Robot added the comment:

New changeset 46c1c2b34e2b by Serhiy Storchaka in branch 'default':
Issue #17003: Unified the size argument names in the io module with common
http://hg.python.org/cpython/rev/46c1c2b34e2b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17003>
_______________________________________

From report at bugs.python.org  Mon Sep 16 22:26:11 2013
From: report at bugs.python.org (janzert)
Date: Mon, 16 Sep 2013 20:26:11 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379363171.64.0.218734418243.issue19037@psf.upfronthosting.co.za>


Changes by janzert <janzert at janzert.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31802/mailbox.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Mon Sep 16 22:41:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Sep 2013 20:41:15 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1379364075.93.0.0869178956685.issue18873@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

One of the problem with encoding recognition is that the same logic is more-or-less reproduced multiple places, so any fix needs to be applied multiple places. From the detect_encoding_in_comments_only.patch:
Lib/idlelib/IOBinding.py
Lib/lib2to3/pgen2/tokenize.py
Lib/tokenize.py
Tools/scripts/findnocoding.py
Any fix for issues *18960 and *18961 may also need multiple applications.

If there is not now, it would be nice if there were just one python-coded function in Lib/tokenize.py that could be imported and used by the other python code. (I was going to suggest exposing the function in tokenize.c, but I believe the point of tokenize.py is to not be dependent on CPython.)

I believe the Idle support for \r became obsolete when support for MacOS9 was dropped in 2.4. I notice that it is not part of io universal newline support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Mon Sep 16 23:02:14 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Mon, 16 Sep 2013 21:02:14 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
Message-ID: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>


New submission from Tae-Wong SEO:

This patch fixes sort order in file Misc/ACKS.

----------
assignee: docs at python
components: Documentation
files: ACKS
messages: 197945
nosy: docs at python, taewong.seo
priority: normal
severity: normal
status: open
title: Fix sort order in Misc/ACKS.
type: enhancement
Added file: http://bugs.python.org/file31803/ACKS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Mon Sep 16 23:05:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Sep 2013 21:05:24 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <3cf0N35NLczRG0@mail.python.org>


Roundup Robot added the comment:

New changeset 2dfe8262093c by Serhiy Storchaka in branch '3.3':
Issue #18873: The tokenize module, IDLE, 2to3, and the findnocoding.py script
http://hg.python.org/cpython/rev/2dfe8262093c

New changeset 6b747ad4a99a by Serhiy Storchaka in branch 'default':
Issue #18873: The tokenize module, IDLE, 2to3, and the findnocoding.py script
http://hg.python.org/cpython/rev/6b747ad4a99a

New changeset 3d46ef0c62c5 by Serhiy Storchaka in branch '2.7':
Issue #18873: IDLE, 2to3, and the findnocoding.py script now detect Python
http://hg.python.org/cpython/rev/3d46ef0c62c5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Mon Sep 16 23:08:36 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 16 Sep 2013 21:08:36 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379365716.2.0.437133735656.issue19038@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The ? sorts correctly after the Z.
Have you changed anything else other than that?
(If you upload a diff file it's better)

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Mon Sep 16 23:19:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Sep 2013 21:19:40 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1379366380.56.0.685274946577.issue18873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> If there is not now, it would be nice if there were just one python-coded function in Lib/tokenize.py that could be imported and used by the other python code.

Agree. But look how many tokenize issues are opened around.

Thank you for your report Paul.

I left PEP 263 not fixed yet. Perhaps it needs rewording (especially in the light of other issues, such as #18960 and #18961).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Mon Sep 16 23:21:33 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Mon, 16 Sep 2013 21:21:33 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379366493.78.0.501007304523.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

Letter a-with-ring is used in Swedish, Danish, Norwegian, Finnish and several other languages.
You have accentuated some contributor names (for example: Bozon, Donmez and Niksic).
You want to make a diff file for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 00:29:01 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 16 Sep 2013 22:29:01 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379370541.7.0.285916803238.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Ok, I'm adding a more comprehensive patch.  It adds support for
peek, readline, and read1 for both regular and chunked responses.
readline falls back to IOBase.readline for chunked, which again makes use of peek() for performance.
read1() is available for other kinds of client buffering, e.g. when reading the stream incrementally using other delimiters than newline.

The real work is done by the _read1_or_peek_chunked() method.  the code for both cases is almost identical so a dual purpose method is warranted.

Added test cases to test this.  The test cases don't attempt to test that we don't block on partial resopnses, though.  I'm not sure how I would write such a test.  I'd probably have to extend FakeSocket to work on some stream that can be appended to...

----------
Added file: http://bugs.python.org/file31804/httpresponse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Tue Sep 17 00:50:26 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Sep 2013 22:50:26 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1379371826.76.0.927138404578.issue1615@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Tue Sep 17 00:57:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 22:57:28 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379372248.93.0.499885972533.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file31805/5d8817cc9e69.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:02:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 23:02:21 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379372541.63.0.455363709686.issue18874@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file31806/21f7c3df0f15.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:02:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 23:02:41 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379372561.24.0.997181261826.issue18874@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31805/5d8817cc9e69.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:02:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 23:02:43 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379372563.94.0.474977299367.issue18874@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31545/tracemalloc-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:02:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 23:02:46 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379372566.28.0.218855868443.issue18874@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file31517/tracemalloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:44:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 23:44:41 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379375081.46.0.999916128268.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Include/tracemalloc.h: PyTraceMalloc_DisableTemporary() and PyTraceMalloc_RestoreTemporary() should be removed, they were tests to try to fix issues with subinterpreter when tracing PyMem_RawMalloc().

Lib/test/regrtest.py: These changes should not be commited, they are just here to create easily snapshot files (./python -X tracemalloc -m test).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:45:25 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 16 Sep 2013 23:45:25 +0000
Subject: [issue18961] Non-UTF8 encoding line
In-Reply-To: <1378568149.13.0.824239204214.issue18961@psf.upfronthosting.co.za>
Message-ID: <1379375125.74.0.313982558493.issue18961@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

One issue at a time, please, and issue18960 is already its own issue.

In any case, item "1" in "Concepts" of PEP 263 is clear that any deviation from the declared encoding should cause a decoding error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18961>
_______________________________________

From report at bugs.python.org  Tue Sep 17 01:46:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Sep 2013 23:46:23 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1379375183.27.0.787817449659.issue18874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

TODO list:

* remove dependency to psutil
* enable PYMEM_RAW: fix subinterpreter issue, check which variables are protected by which lock
* test the command line interface?
* don't trace objects created by get_stats(), reentrant flag should be a thread-local variable
* add an hash table of tracebacks: 86% of tracebacks are duplicated

See also the TODO.txt file in the tracemalloc repository.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18874>
_______________________________________

From report at bugs.python.org  Tue Sep 17 02:29:19 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Sep 2013 00:29:19 +0000
Subject: [issue18050] embedded interpreter or virtualenv fails with
 "ImportError: cannot import name MAXREPEAT"
In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za>
Message-ID: <1379377759.84.0.510981556611.issue18050@psf.upfronthosting.co.za>


Ned Deily added the comment:

The patch LGTM. And I agree that the fix is not needed for 3.4.  Thanks, Serhiy.

I verified that it does solve the "embedded" problem (case 1 above) when using embedded versions of all previous releases of 2.7.x (except 2.7.0) and 3.3.x.

For the record, it appears 2.7.1 introduced a separate incompatibility issue that causes a similar initialization crash with an embedded version of 2.7.0:

Traceback (most recent call last):
  File "/py/test_issue18050/root/lib/python2.7/site.py", line 62, in <module>
    import os
  File "/py/test_issue18050/root/lib/python2.7/os.py", line 398, in <module>
    import UserDict
  File "/py/test_issue18050/root/lib/python2.7/UserDict.py", line 83, in <module>
    import _abcoll
  File "/py/test_issue18050/root/lib/python2.7/_abcoll.py", line 11, in <module>
    from abc import ABCMeta, abstractmethod
  File "/py/test_issue18050/root/lib/python2.7/abc.py", line 8, in <module>
    from _weakrefset import WeakSet
  File "/py/test_issue18050/root/lib/python2.7/_weakrefset.py", line 5, in <module>
    from _weakref import ref
ImportError: No module named _weakref

Googling shows a number of reports of users who have run into that one, too, though no one seems to have opened an issue here about it.  I don't think it's worth trying to fix that one at this point as there probably aren't that many instances of system executables that still have embedded static 2.7.0 interpreters anymore (I hope).  Unfortunately, that's not the case for embedded static 2.7.2, e.g. vim on OS X 10.8.x.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18050>
_______________________________________

From report at bugs.python.org  Tue Sep 17 03:18:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Sep 2013 01:18:42 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1379380722.63.0.742147219068.issue18873@psf.upfronthosting.co.za>


R. David Murray added the comment:

This appears to be resulting in buildbot lib2to3 test failures.  ex:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%202.7/builds/2319/steps/test/logs/stdio

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%202.7/builds/206/steps/test/logs/stdio

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Tue Sep 17 04:44:37 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Sep 2013 02:44:37 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379385877.4.0.265696418024.issue16038@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Yep, confirmed that ftplib.patch causes test_ftplib to fail, at least on Ubuntu 10.04 chroot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 05:02:21 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Sep 2013 03:02:21 +0000
Subject: [issue18050] embedded interpreter or virtualenv fails with
 "ImportError: cannot import name MAXREPEAT"
In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za>
Message-ID: <1379386941.48.0.789942832452.issue18050@psf.upfronthosting.co.za>


Ned Deily added the comment:

To answer your earlier question, there are other inter-version incompatibilities in some of the non-static standard library modules such that test_re cannot be run without errors.  However, applying the patch at least allows the embedded interpreter to not crash during initialization, a big improvement over the current situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18050>
_______________________________________

From report at bugs.python.org  Tue Sep 17 05:05:51 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 17 Sep 2013 03:05:51 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379387151.7.0.554817347336.issue16038@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Succeeds on OS X 10.8 (although there are other failures)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 07:05:58 2013
From: report at bugs.python.org (paul j3)
Date: Tue, 17 Sep 2013 05:05:58 +0000
Subject: [issue10984] argparse add_mutually_exclusive_group should accept
 existing arguments to register conflicts
In-Reply-To: <1295737320.83.0.942830837874.issue10984@psf.upfronthosting.co.za>
Message-ID: <1379394358.48.0.0521882559471.issue10984@psf.upfronthosting.co.za>


paul j3 added the comment:

Another situation in which this MultiGroupHelpFormatter helps is when one or more of the groups includes an optional positional.  

The regular formatter moves all the positionals to the end, after the optionals.  This move could easily break up a mutually exclusive group, and make formatting it impossible.  But the MultiGroupHelpFormatter gives the group order priority.

Thus for example:

    p=argparse.ArgumentParser()
    # (formatter_class=argparse.MultiGroupHelpFormatter)
    g=p.add_mutually_exclusive_group()
    g.add_argument('-f')
    g.add_argument('foo',nargs='?')
    g=p.add_mutually_exclusive_group()
    g.add_argument('-b')
    g.add_argument('-c')
    g.add_argument('bar',nargs='*',default='X')
    print(p.format_usage())

produces (positionals at end, no group markings)

    usage: PROG [-h] [-f F] [-b B] [-c C] [foo] [bar [bar ...]]

But the MultiGroupHelpFormatter produces:

    usage: PROG [-h] [-f F | foo] [-b B | -c C | bar [bar ...]]

In this last case, the positionals are listed with their respective groups, and the groups are ordered by the relative ordering of the positionals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10984>
_______________________________________

From report at bugs.python.org  Tue Sep 17 07:08:48 2013
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 Sep 2013 05:08:48 +0000
Subject: [issue3173] external strftime for Python?
In-Reply-To: <1214189093.82.0.548435251403.issue3173@psf.upfronthosting.co.za>
Message-ID: <1379394528.63.0.139177474836.issue3173@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3173>
_______________________________________

From report at bugs.python.org  Tue Sep 17 07:35:52 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 05:35:52 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379396152.54.0.882095502627.issue14984@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I would welcome a "versionchanged" block in the docs addition.

There seems to be a stray space in the string in the last line here:

+                            try:
+                                user = pwd.getpwuid(os.getuid())[0]
+                            except KeyError:
+                                user = 'uid %s ' % os.getuid()

Otherwise, fine for 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Tue Sep 17 08:32:52 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 06:32:52 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379399572.56.0.688244964483.issue19038@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Please do not change the ordering of ? -- it is correct after Z, at least in Swedish, Danish and Norwegian.

If you want to sort German umlauts correctly, in lists of names they are treated as [aou]+e, so "L?wis" goes before "Lowe".

As for Aahz, he appears by that name alone and should not be changed.

It's Jean-Paul, not Jean-Pierre Calderone.  This change makes me wary of accepting any of your other changes.  How did you come to your spellings of the names?

If you do, please resubmit in diff form.

----------
nosy: +georg.brandl
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 08:51:46 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Sep 2013 06:51:46 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379400706.25.0.894021315175.issue19038@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 08:52:07 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Sep 2013 06:52:07 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379400727.43.0.480727964222.issue19038@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 09:01:40 2013
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Sep 2013 07:01:40 +0000
Subject: [issue19039] sphinx search, result sorting
Message-ID: <1379401300.31.0.855533984181.issue19039@psf.upfronthosting.co.za>


New submission from Thomas Guettler:

If you search for "printf" in the docs you get this result:

http://docs.python.org/3.3/search.html?q=printf&check_keywords=yes&area=default

Please have a look at the first results. I guess most people don't want to see docs about "PyOS_snprintf"

Most people want to see this: http://docs.python.org/3.3/library/stdtypes.html?highlight=printf#printf-style-string-formatting

The good page (stdtypes.html) is the fourth search result.
And this page is huge. Unfortunately the link from the search result does not link to the section, it links to the top of the page.

 Since "printf" is in the heading, sphinx should be able to create a link to the relevant section in this page (in this example #printf-style-string-formatting).


Thank you

----------
assignee: docs at python
components: Documentation
messages: 197963
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: sphinx search, result sorting

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19039>
_______________________________________

From report at bugs.python.org  Tue Sep 17 09:09:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Sep 2013 07:09:31 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <3cfFn661sdz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset f16855d6d4e1 by Serhiy Storchaka in branch '2.7':
Remove the use of non-existing re.ASCII.
http://hg.python.org/cpython/rev/f16855d6d4e1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Tue Sep 17 09:11:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Sep 2013 07:11:20 +0000
Subject: [issue18873] "Encoding" detected in non-comment lines
In-Reply-To: <1377733828.84.0.187873686894.issue18873@psf.upfronthosting.co.za>
Message-ID: <1379401880.71.0.167186248337.issue18873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks, David.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18873>
_______________________________________

From report at bugs.python.org  Tue Sep 17 09:43:10 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 17 Sep 2013 07:43:10 +0000
Subject: [issue4080] unittest: display time used by each test case
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1379403790.12.0.716328459911.issue4080@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Tue Sep 17 09:55:55 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 07:55:55 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379404555.3.0.92987928561.issue18967@psf.upfronthosting.co.za>


Georg Brandl added the comment:

[MAL]

> * Commit messages only provide a very terse hint at what a
>   particular patch set was meant for. The target audience
>   is other core developers.
>
> * News entries explain these patches (there may be more than one
>   for a particular issue or project) to Python programmers who
>   need to know what to watch out for when upgrading to a new
>   version.

I agree.  But if you have to write two different versions, putting them
both in the commit message has two advantages:

- it's arguably easier not to have to touch another file
- the extended explanation can be useful for core developers too :)

In any case, I would very much like to see a unified style for commit messages a la Mercurial: a very terse, but self-sufficient first line, and more explanation below.

Not to speak of the non-arguable advantage of getting rid of merge conflicts in Misc/NEWS.

So if the script had a mode to "set off" the intended NEWS entry from both a header (the terse 1-line commit message) and an optional footer (explanation of technical details only of interest to committers), I would say +1.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Tue Sep 17 09:58:42 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 07:58:42 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379404722.26.0.509892548318.issue18553@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Senthil: your 3.3->default merge removed the Availability from fpathconf().

----------
nosy: +georg.brandl
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Tue Sep 17 10:03:08 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Tue, 17 Sep 2013 08:03:08 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379404988.71.0.921134133815.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

You want to submit a diff file.
You are not signing contributor agreement.
Letter a-with-ring is also usd in transliteration of Avestan language.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 10:05:09 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 08:05:09 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379405109.88.0.951138758873.issue18986@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Note that I'm strongly against this name of the getitem() method.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 10:11:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Sep 2013 08:11:36 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1379405109.88.0.951138758873.issue18986@psf.upfronthosting.co.za>
Message-ID: <539491035.69373682.1379405489053.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Georg Brandl added the comment:
> 
> Note that I'm strongly against this name of the getitem() method.

Any suggestion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 10:28:17 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 08:28:17 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1379406497.41.0.805268095439.issue19023@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks for the patch! The amount of unrelated changes (mostly removing ">>>" empty prompts) makes this a bit hard to review.

Also, I don't think it is too important to link to the "ctypes" module from within the docs of ctypes :)

Please separate out the implementation of the Union classes into a separate patch.

The Array docs look good to me.  The _Pointer docs talk about "reading and writing the elements using standard subscript and slice accesses".  That is true for pointers pointing to arrays, but ".contents" should be mentioned as well.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Tue Sep 17 10:31:39 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 08:31:39 +0000
Subject: [issue19026] OrderedDict should not accept dict as parameter
In-Reply-To: <1379263563.34.0.887004049034.issue19026@psf.upfronthosting.co.za>
Message-ID: <1379406699.96.0.874950018416.issue19026@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> Right. That's why it should not accept input that can only be
> unordered (including dict and **kwargs) - this is what I mean by
> strict mode.

That's not even true: the empty and the one-element dict are always ordered.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19026>
_______________________________________

From report at bugs.python.org  Tue Sep 17 10:57:08 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 08:57:08 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379408228.4.0.392702864137.issue18986@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Not really. Would "entry" be acceptable instead of "item"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 11:09:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Sep 2013 09:09:11 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379408951.52.0.912015409177.issue18967@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I agree the "different audiences" problem can be addressed by using appropriate commit message formatting to say "this bit goes in NEWS" (perhaps with some metadata to say which section).

However, that doesn't solve the question of how we fix inevitable mistakes. One thought that occurs to me is a "fixNEWS" subdir where we can put text files named after commit hashes. If there is a file in fixNEWS, then the script would ignore the corresponding commit and use the file contents instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Tue Sep 17 11:10:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Sep 2013 09:10:38 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1379408228.4.0.392702864137.issue18986@psf.upfronthosting.co.za>
Message-ID: <1628504091.69543647.1379409030523.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Georg Brandl added the comment:
> 
> Not really. Would "entry" be acceptable instead of "item"?

getentry() sounds decent to me, but it loses the parallel to popitem() and items().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 11:19:45 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 17 Sep 2013 09:19:45 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1379408951.52.0.912015409177.issue18967@psf.upfronthosting.co.za>
Message-ID: <52381EAE.7060506@egenix.com>


Marc-Andre Lemburg added the comment:

On 17.09.2013 11:09, Nick Coghlan wrote:
> 
> Nick Coghlan added the comment:
> 
> I agree the "different audiences" problem can be addressed by using appropriate commit message formatting to say "this bit goes in NEWS" (perhaps with some metadata to say which section).
> 
> However, that doesn't solve the question of how we fix inevitable mistakes. One thought that occurs to me is a "fixNEWS" subdir where we can put text files named after commit hashes. If there is a file in fixNEWS, then the script would ignore the corresponding commit and use the file contents instead.

I don't think commit messages are the right place for such text.
They cannot be corrected after the fact, which makes them less
than ideal for the intended purposes: to produce an edited news
compilation.

I'm still not convinced we actually have a problem that needs to
be solved. Please consider the time it takes to resolve a merge
conflict vs. the time it takes to correct mistakes in commit
message formatting, educating committers and tweaking the script
to handle the inevitable mistakes.

Aside: It may be better to add support for news entries to the
tracker. At eGenix we're using a custom field called "News" which
is then listed in a report to build the change log. These can be
edited, there's only one entry per ticket and the report can be
sorted by priority/component/etc, putting the more important
news item at the top.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Tue Sep 17 11:43:18 2013
From: report at bugs.python.org (Sjoerd)
Date: Tue, 17 Sep 2013 09:43:18 +0000
Subject: [issue19012] liburl2: bad proxy configuration throws "getaddrinfo"
 error
In-Reply-To: <1379098642.08.0.213959473701.issue19012@psf.upfronthosting.co.za>
Message-ID: <1379410998.62.0.713287655073.issue19012@psf.upfronthosting.co.za>


Sjoerd added the comment:

That happens when citing things from the top of my head... it is not liburl2 but urllib2 that I used, excuse me. (And urlopen instead of openurl...)

From
  http://docs.python.org/2/library/urllib2.html
it seems to be a Standard Library module to me, am I mistaken? If so, how do I find the urllib2 maintainers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19012>
_______________________________________

From report at bugs.python.org  Tue Sep 17 11:50:57 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 17 Sep 2013 09:50:57 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379411457.93.0.540582683464.issue18967@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

An alternative would be to have separate files NEWS-3.2, NEWS-3.3, NEWS-3.4 etc.  If a fix is added to 3.2 and will be merged to 3.3 and 3.4 then you add an entry to NEWS-3.2 and append some sort of tags to indicate merges:

    - Issue #1234: Fix something that was not working properly.
      #Merge-3.3 #Merge-3.4

Then NEWS can be auto-generated from NEWS-3.*.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Tue Sep 17 12:10:37 2013
From: report at bugs.python.org (Drekin)
Date: Tue, 17 Sep 2013 10:10:37 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
Message-ID: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>


New submission from Drekin:

I tried to implement an Enum variant OptionalEnum such that OptionalEnum(value) leaves value alone and returnes it (if there is no corresponding enum member) rather than raising ValueError. My use case is following: I'm trying to parse some keyboard layout related data. There is a table which maps virtual keys to unicode codepoints, however there are some special values which don't represent a codepoint but the fact that the key is a deadkey and more information is provided in the next table entry. Or that the key produces a ligature. So I wanted to define enums for those special values.

This brought me to the following naive approach:
class OptionalEnum(Enum):
    def __new__(cls, value):
        try:
            return super(cls, cls).__new__(cls, value)
        except ValueError:
            return value

This ends with a weird exception. As I ran through enum code I found out that there are actually two flavors of EnumSubclass.__new__. The first one is for precreating the enum members (during creation of EnumSubclass). This is the intended usage. The second flavor is what happens when EnumSubclass(value) is called later. This flavor is represented by Enum.__new__ which returns existing member corresponding to the value or raises ValueError. However this Enum.__new__ is rather special. It doesn't take place in the process of the first flavor, it is explicitly by-passed. On the other hand it is forced behavior of the second flavor since it is explicitly assigned to EnumSubclass.__new__. So there seems to be no way to customize the second flavor (as I tried in my use case).

So could the customization of the second flavor of __new__ be added? (One maybe naive solution would be to let user explicitly define __new_member__ rather than __new__ to customize the first flavor and leave __new__ for the second flavor.) Or could at least be done something with the exceptions produced when one tries to? (The exception in my case was 'TypeError: object() takes no parameters' and was result of having custom __new__ and hence use_args==True but having member_type==object and __new__ not creating member with _value_ attribute so object(*args) was called.)

In any case additional documentation on customizing __new__ could help. There are points like that one should avoid the pattern of falling back to super().__new__ since that is Enum.__new__ which is for something else. Also the custom __new__ should return an object with _value_ attribute or object() with some argument may be called which leads to uninformative exception.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 197979
nosy: Drekin, docs at python
priority: normal
severity: normal
status: open
title: Problems with overriding Enum.__new__
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Tue Sep 17 12:16:31 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 Sep 2013 10:16:31 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379412991.79.0.256245246287.issue18986@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Hmm, I didn't consider popitem().  Maybe I'm too paranoid about users confusing __getitem__() and getitem() after all :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 13:15:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Sep 2013 11:15:29 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379416529.57.0.895763546454.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But why not getkey()? Why you need return value too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 14:06:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Sep 2013 12:06:36 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1379416529.57.0.895763546454.issue18986@psf.upfronthosting.co.za>
Message-ID: <1827605798.70018600.1379419590155.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> But why not getkey()? Why you need return value too?

Because it's more useful to return both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 15:08:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Sep 2013 13:08:56 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379423336.15.0.114671157469.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, I don't understand why it's more useful. We need create a tuple and then index it or unpack it and drop one of elements. This only muddles away a time and programmer's attention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 15:34:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Sep 2013 13:34:17 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379424857.28.0.36214787221.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because most often the time at which you want the original key is the point at which you are about to re-serialize the data...so you need the value too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 15:57:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Sep 2013 13:57:24 +0000
Subject: [issue19012] urllib2: bad proxy configuration throws "getaddrinfo"
 error
In-Reply-To: <1379098642.08.0.213959473701.issue19012@psf.upfronthosting.co.za>
Message-ID: <1379426244.46.0.722892060674.issue19012@psf.upfronthosting.co.za>


R. David Murray added the comment:

urllib2 is a python2 stdlib module, yes.

Can you provide a traceback?  I would have thought that the traceback would give a clue as to what the real problem was, so I'm very curious to see it.  Maybe it only gives a clue if you already know what you are looking at :)

----------
resolution: invalid -> 
stage: committed/rejected -> 
status: closed -> open
title: liburl2: bad proxy configuration throws "getaddrinfo" error -> urllib2: bad proxy configuration throws "getaddrinfo" error
versions: +Python 2.7 -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19012>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:00:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Sep 2013 14:00:52 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1379426452.09.0.259827633449.issue19040@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:03:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Sep 2013 14:03:07 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379426587.37.0.631895900376.issue18986@psf.upfronthosting.co.za>


R. David Murray added the comment:

I do think getitem is the most natural name for the method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:08:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Sep 2013 14:08:57 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379426937.24.0.033528779914.issue18986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, could anyone borrow Guido's time machine and rename either __getitem__() to __getvalue__() or items() to entries()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:10:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Sep 2013 14:10:04 +0000
Subject: [issue19039] sphinx search, result sorting
In-Reply-To: <1379401300.31.0.855533984181.issue19039@psf.upfronthosting.co.za>
Message-ID: <1379427004.08.0.352579356563.issue19039@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a Sphinx issue and should be reported on the Sphinx tracker...although I think Sphinx uses a 3rd party tool for the sorting, so it might go back up even a level further :).  

I don't think there's any reason to keep this issue open here, but I'll leave that up to Georg.

----------
assignee: docs at python -> 
nosy: +georg.brandl, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19039>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:12:43 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Sep 2013 14:12:43 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1379424857.28.0.36214787221.issue18986@psf.upfronthosting.co.za>
Message-ID: <52386357.3060701@trueblade.com>


Eric V. Smith added the comment:

On 09/17/2013 09:34 AM, R. David Murray wrote:
> 
> R. David Murray added the comment:
> 
> Because most often the time at which you want the original key is the point at which you are about to re-serialize the data...so you need the value too.

I can't think of a case where I'd need (original_key, value) where I
wouldn't also be iterating over items(). Especially so if I'm serializing.

On the other hand, I don't have a use case for the original key, anyway.
So I don't have a strong feeling about this, other than it feels odd
that the answer to the original question (I think on python-dev) "how do
we get the original key back?" is answered by "by giving you the
original key and its value".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:19:52 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Sep 2013 14:19:52 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <52386357.3060701@trueblade.com>
Message-ID: <52386504.8060102@trueblade.com>


Eric V. Smith added the comment:

On 09/17/2013 10:12 AM, Eric V. Smith wrote:
> On the other hand, I don't have a use case for the original key, anyway.
> So I don't have a strong feeling about this, other than it feels odd
> that the answer to the original question (I think on python-dev) "how do
> we get the original key back?" is answered by "by giving you the
> original key and its value".

I meant: I don't have a use case for finding the original key outside of
iterating over items().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:28:10 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Sep 2013 14:28:10 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1379428090.18.0.395073023219.issue1615@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Benjamin Peterson added the comment:
>
> I consider this to be a feature. Properties can raise AttributeError to defer to
> __getattr__.

Micah Friesen added the comment:
>
>I submit that this is not a feature - I can't imagine a real-world scenario [...]

No need to imagine.  The new Enum class uses this ability to support having both protected properties on enum members and enum members of the same name:

--> from enum import Enum
--> class Field(Enum):
-->     name = 1
...     age = 2
...     location = 3
... 
--> Field.name
<Field.name: 1>
--> Field.name.name
'name'

Enum's custom __getattr__ is located in the metaclass, however, not in the class.  For future reference, here is a short test script and it's output in 3.4.0a2+:
=====================================================================================
class WithOut:
    @property
    def huh(self):
        return self.not_here

class With:
    @property
    def huh(self):
        return self.not_here
    def __getattr__(self, name):
        print('looking up %s' % name)
        raise AttributeError('%s not in class %s' % (name, type(self)))

try:
    WithOut().huh
except AttributeError as exc:
    print(exc)

print()
try:
    With().huh
except AttributeError as exc:
    print(exc)

print()
import enum  # broken value property tries to access self.not_here
class TestEnum(enum.Enum):
    one = 1

print(TestEnum.one.value)
=====================================================================================
'WithOut' object has no attribute 'not_here'

looking up not_here
looking up huh
huh not in class <class '__main__.With'>

meta getattr with __new_member__
meta getattr with __new_member__
meta getattr with one
'TestEnum' object has no attribute 'not_here'
=====================================================================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:30:18 2013
From: report at bugs.python.org (Akira Kitada)
Date: Tue, 17 Sep 2013 14:30:18 +0000
Subject: [issue1065986] Fix pydoc crashing on unicode strings
Message-ID: <1379428218.86.0.675915343835.issue1065986@psf.upfronthosting.co.za>


Akira Kitada added the comment:

With this patch applied, the example from issue15791 works fine.

$ echo "__author__ = u'Michele Orr\xf9'" > foo.py && ./python -c "import foo; print foo.__author__; help(foo)"
Michele Orr?
Help on module foo:

NAME
    foo

FILE
    /tmp/cpython/foo.py

DATA
    __author__ = u'Michele Orr\xf9'

AUTHOR
    Michele Orr?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1065986>
_______________________________________

From report at bugs.python.org  Tue Sep 17 16:48:22 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Tue, 17 Sep 2013 14:48:22 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379429302.99.0.29242541237.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

You want to add the packaging coordinator Laca (real name L?szl? P?ter in Hungarian) to Misc/ACKS.

And you want to add a bunch of real names from the python-bugs-list mailing list (from August 2007 to September 2013).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Tue Sep 17 17:51:26 2013
From: report at bugs.python.org (Tcll)
Date: Tue, 17 Sep 2013 15:51:26 +0000
Subject: [issue19041] requested (DLL) module could not be found
Message-ID: <1379433086.01.0.0639990242441.issue19041@psf.upfronthosting.co.za>


New submission from Tcll:

I think this issue more revolves around PyGLEW, but LaunchPad won't let me report to them...

I've taken a screenshot of the issue rather than trying to explain it:
http://lh3.ggpht.com/-d6gM0Qlq9Ek/UjhxFDFOmAI/AAAAAAAAFIU/Vwell0V1Vo8/s1400/error.jpg

I've also notified the PyGPU developers who require the installation for their project.

----------
components: Extension Modules
messages: 197994
nosy: Tcll
priority: normal
severity: normal
status: open
title: requested (DLL) module could not be found
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19041>
_______________________________________

From report at bugs.python.org  Tue Sep 17 18:36:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Sep 2013 16:36:45 +0000
Subject: [issue19041] requested (DLL) module could not be found
In-Reply-To: <1379433086.01.0.0639990242441.issue19041@psf.upfronthosting.co.za>
Message-ID: <1379435805.02.0.14999133871.issue19041@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are correct, this is not likely to be a problem with Python itself (the interactive prompt in your screen capture doesn't look like what Python would produce by itself).  So, since it is almost certainly not a bug in Python, it's not appropriate for this issue tracker.

(The fact that the import fails probably means that PyGLEW didn't compile or install correctly.)

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: compile error -> 
versions: +3rd party -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19041>
_______________________________________

From report at bugs.python.org  Tue Sep 17 18:48:35 2013
From: report at bugs.python.org (Tcll)
Date: Tue, 17 Sep 2013 16:48:35 +0000
Subject: [issue19041] requested (DLL) module could not be found
In-Reply-To: <1379435805.02.0.14999133871.issue19041@psf.upfronthosting.co.za>
Message-ID: <CAOtBmLnKRezx6ETC40SbX9XsG_qdL+QK0gvBz0imJfgmMonQKg@mail.gmail.com>


Tcll added the comment:

yeh... the only thing I was thinking was on Python's end was the DLL
(Highlighted in the img) failing to register.
(I have seen cases of PYD modules used in the same manner, such as PyWin32
modules)

but yea, I see now that isn't the case, so thank you :)

On Tue, Sep 17, 2013 at 12:36 PM, R. David Murray <report at bugs.python.org>wrote:

>
> R. David Murray added the comment:
>
> You are correct, this is not likely to be a problem with Python itself
> (the interactive prompt in your screen capture doesn't look like what
> Python would produce by itself).  So, since it is almost certainly not a
> bug in Python, it's not appropriate for this issue tracker.
>
> (The fact that the import fails probably means that PyGLEW didn't compile
> or install correctly.)
>
> ----------
> nosy: +r.david.murray
> resolution:  -> invalid
> stage:  -> committed/rejected
> status: open -> closed
> type: compile error ->
> versions: +3rd party -Python 2.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue19041>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19041>
_______________________________________

From report at bugs.python.org  Tue Sep 17 19:20:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Sep 2013 17:20:54 +0000
Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window
Message-ID: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

The General tab of the IDLE Preferences dialog has this section with two radiobuttons:

Autosave Preferences
At Start of Run (F5)  () Prompt to Save   () No Prompt

The latter option actually means "No prompt unless the window is a new window ('Untitled') that has never been saved." In the latter case, there is a prompt anyway.

This issue proposes that the current No Prompt option be more truthfully labelled and that a true no-prompt option be added. Currently in .cnf configuration files, autosave = 0 or 1. The new option would be 2 ('really true' ;-).

The motivation is to provide a default scratch file for throwaway code and thereby encourage more use of the editor even for single multi-line statements, which are harder to edit in the Shell than single-line statements. The behavior of Untitled windows would not otherwise change.

----------------
Possible dialog forms

Autosave Preferences
When Running (F5) a window with unsaved changes, prompt to save
() Always   () Only for Untitled    () Never

I find it slightly confusing that Autosave yes is selected in the negative with 'no prompt'. An alternative:

Autosave Preferences
When Running (F5) a window with unsaved changes,
autosave instead of prompting to save
() Never   () Always except for Untitled    () Always

Another alternative is to retitle the section

Prompt to Save versus Autosave
When Running (F5) a window with unsaved changes, prompt to save
() Always   () Only for Untitled    () Never
--------------

However the dialog is worded, the new option would mean that unsaved new windows would be autosaved on Run to .idlerc/untitled.py. (I picked this directory because it already contains 4 per-user files, including recent-files.lst, and has to be writable.) This would be a common scratch file for all Untitled windows.

The particular Untitled window saved should not be 'associated' with that path. Its title would not change to 'untitled.py'. Idle allows only one edit window per disk file (path) but allows multiple Untitled windows not associated with any path.

The 'unsaved' flag on the window would not be cleared, so that closing the window would still bring up the 'save this untitled window' message box. (The alternative would be to clear it, but unclear it if any other Untitled window were saved.)

The full path to untitled.py would be added (or moved) to the top of the Recent Files list, just as with any other file. The file could then be retrieved (if not overwritten) in a later session. This would be particularly useful if running it caused a crash or freeze.
------------------

This proposal is based on Bruce Sherwood's vague description of a feature coded by G. Polo. I could not find a tracker issue for it. One apparent difference is that I propose adding a third option to the existing set instead of a new binary option. I have no idea whether Polo proposed to silently save the file (as I propose) or add a mechanism to truly run without saving (which is how a user will see it unless they look at Recent Files). In any case, my proposal is for a pretty minimal change. I believe it would take extra code to prevent the Recent Files listing.

----------
components: IDLE
messages: 197997
nosy: bsherwood, roger.serwy, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: add option to autosave 'Untitled' edit window
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19042>
_______________________________________

From report at bugs.python.org  Tue Sep 17 20:15:52 2013
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 17 Sep 2013 18:15:52 +0000
Subject: [issue19042] Idle: add option to autosave 'Untitled' edit window
In-Reply-To: <1379438454.05.0.402533666166.issue19042@psf.upfronthosting.co.za>
Message-ID: <1379441751.99.0.720615436568.issue19042@psf.upfronthosting.co.za>


Bruce Sherwood added the comment:

Very nice, Terry. Good point about positive vs. negative specifications. I think maybe your "Prompt to Save versus Autosave" is the best scheme, because one is specifying whether or not to do something "active" (namely, put up a save dialog).

----------
nosy: +Bruce.Sherwood

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19042>
_______________________________________

From report at bugs.python.org  Tue Sep 17 22:34:51 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 17 Sep 2013 20:34:51 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379450091.17.0.861914187577.issue14984@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Fine for 3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 01:23:33 2013
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 17 Sep 2013 23:23:33 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379460213.01.0.197338983262.issue19038@psf.upfronthosting.co.za>


Brian Curtin added the comment:

I don't believe we want to do those things. Changes should be in a diff file and limited to the minimum amount of required changes to fix your sort ordering bug - not adding people or changing the spelling of people's names.

----------
nosy: +brian.curtin
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 01:35:18 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Tue, 17 Sep 2013 23:35:18 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379460918.11.0.58431544143.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

You want to make diff file to get changes from the ACKS file.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 02:11:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Sep 2013 00:11:45 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <3cfhSc5QmmzPdn@mail.python.org>


Roundup Robot added the comment:

New changeset 1b673e0fd8f3 by R David Murray in branch '2.6':
Add versionchanged for #14984, remove extra blank from string.
http://hg.python.org/cpython/rev/1b673e0fd8f3

New changeset 48be42b94381 by R David Murray in branch '2.7':
Merge: Add versionchanged for #14984, remove extra blank from string.
http://hg.python.org/cpython/rev/48be42b94381

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 03:39:08 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Sep 2013 01:39:08 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379468348.9.0.910682573406.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, I got the answer to the "may" question, but not the "can" question.  The answer to that question is "no":

remote:  - changeset 6396d1fc72da on disallowed branch '3.1'!
remote: * Please strip the offending changeset(s)
remote: * and re-do them, if needed, on another branch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 03:46:36 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 18 Sep 2013 01:46:36 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1379468348.9.0.910682573406.issue14984@psf.upfronthosting.co.za>
Message-ID: <CAPZV6o-m1xmFcTrg4iwo7v-Otan35ijpi3vYDP5-Ls0FUFRAbA@mail.gmail.com>


Benjamin Peterson added the comment:

You should be able to push now.

2013/9/17 R. David Murray <report at bugs.python.org>:
>
> R. David Murray added the comment:
>
> Well, I got the answer to the "may" question, but not the "can" question.  The answer to that question is "no":
>
> remote:  - changeset 6396d1fc72da on disallowed branch '3.1'!
> remote: * Please strip the offending changeset(s)
> remote: * and re-do them, if needed, on another branch!
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14984>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 04:08:44 2013
From: report at bugs.python.org (Mike Hoy)
Date: Wed, 18 Sep 2013 02:08:44 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379470124.44.0.669439713454.issue19024@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Wed Sep 18 04:25:31 2013
From: report at bugs.python.org (Mike Hoy)
Date: Wed, 18 Sep 2013 02:25:31 +0000
Subject: [issue18918] help('FILES') finds no documentation
In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>
Message-ID: <1379471131.24.0.63715203926.issue18918@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18918>
_______________________________________

From report at bugs.python.org  Wed Sep 18 04:31:18 2013
From: report at bugs.python.org (Mike Hoy)
Date: Wed, 18 Sep 2013 02:31:18 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1379471478.07.0.408691383384.issue18855@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Wed Sep 18 08:43:39 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Sep 2013 06:43:39 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>
Message-ID: <1379486619.91.0.777755315887.issue19032@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This does not look like a bug to me.
I think this should be closed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Wed Sep 18 09:05:36 2013
From: report at bugs.python.org (Dmitry Shachnev)
Date: Wed, 18 Sep 2013 07:05:36 +0000
Subject: [issue17761] platform._parse_release_file doesn't close the
 /etc/lsb-release file, doesn't know about 'Ubuntu'
In-Reply-To: <1366123744.99.0.817269180469.issue17761@psf.upfronthosting.co.za>
Message-ID: <1379487936.39.0.0850156000595.issue17761@psf.upfronthosting.co.za>


Changes by Dmitry Shachnev <Mitya57 at gmail.com>:


----------
nosy: +mitya57

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17761>
_______________________________________

From report at bugs.python.org  Wed Sep 18 10:29:11 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 Sep 2013 08:29:11 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379492951.32.0.361503551898.issue19038@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, it is customary for the patch submitter to make the diff.  This makes it much easier for us to review.

Closing for now; please note our suggestions and reopen/resubmit as a diff file if you feel like it.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 10:34:04 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 Sep 2013 08:34:04 +0000
Subject: [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1379493244.75.0.271485605491.issue18855@psf.upfronthosting.co.za>


Georg Brandl added the comment:

AFAIR renaming the lowercased versions might lead to trouble with hg on case-insensitive file systems. Anyone know if that's still the case?

Otherwise README.txt is fine.  Although, Windows users will then complain about the Unix-style line endings because the files will be opened with Notepad by default :|

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18855>
_______________________________________

From report at bugs.python.org  Wed Sep 18 10:52:56 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Wed, 18 Sep 2013 08:52:56 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379494376.4.0.142572859059.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

Your Gmail account tried to send spam for this account.

Be careful with this message. Many people marked similar messages as spam.

Open this bug and have someone made a diff file to fix sort order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 10:56:38 2013
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 18 Sep 2013 08:56:38 +0000
Subject: [issue19032] __reduce_ex__ on lock object
In-Reply-To: <1379292184.95.0.492650505844.issue19032@psf.upfronthosting.co.za>
Message-ID: <1379494598.42.0.771854244442.issue19032@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19032>
_______________________________________

From report at bugs.python.org  Wed Sep 18 11:05:54 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 Sep 2013 09:05:54 +0000
Subject: [issue19039] sphinx search, result sorting
In-Reply-To: <1379401300.31.0.855533984181.issue19039@psf.upfronthosting.co.za>
Message-ID: <1379495154.84.0.942041158434.issue19039@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Searching in headings is implemented in Sphinx 1.2 (soon to be released).  We'll switch to that version at least for 3.3 and 3.4 when it's out, so you will get the result for the heading there.

The PyOS_snprintf will still be the first result, since results in "object names" are always the first preference.  But the second preference will be heading names.

----------
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19039>
_______________________________________

From report at bugs.python.org  Wed Sep 18 11:05:56 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 Sep 2013 09:05:56 +0000
Subject: [issue19039] sphinx search, result sorting
In-Reply-To: <1379401300.31.0.855533984181.issue19039@psf.upfronthosting.co.za>
Message-ID: <1379495156.06.0.659077498248.issue19039@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Searching in headings is implemented in Sphinx 1.2 (soon to be released).  We'll switch to that version at least for 3.3 and 3.4 when it's out, so you will get the result for the heading there.

The PyOS_snprintf will still be the first result, since results in "object names" are always the first preference.  But the second preference will be heading names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19039>
_______________________________________

From report at bugs.python.org  Wed Sep 18 11:06:49 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Wed, 18 Sep 2013 09:06:49 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379495209.26.0.710542794395.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

New diff file to change Bozon's last name.

----------
keywords: +patch
status: closed -> pending
Added file: http://bugs.python.org/file31807/ACKS.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 12:13:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Sep 2013 10:13:36 +0000
Subject: [issue18997] Crash when using pickle and ElementTree
In-Reply-To: <1378820960.56.0.761098520663.issue18997@psf.upfronthosting.co.za>
Message-ID: <3cfxq36TWVz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset 111a74819192 by doko in branch '3.3':
- followup for issue #18997, make _clear_joined_ptr static.
http://hg.python.org/cpython/rev/111a74819192

New changeset 269be4aacb8e by doko in branch 'default':
- followup for issue #18997, make _clear_joined_ptr static.
http://hg.python.org/cpython/rev/269be4aacb8e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18997>
_______________________________________

From report at bugs.python.org  Wed Sep 18 12:19:23 2013
From: report at bugs.python.org (koobs)
Date: Wed, 18 Sep 2013 10:19:23 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1379499563.85.0.626221623734.issue4366@psf.upfronthosting.co.za>


koobs added the comment:

Confirming identical failures on all branches:

tip: /usr/bin/ld: cannot find -lpython3.4m
3.3: /usr/bin/ld: cannot find -lpython3.3m
3.2: /usr/bin/ld: cannot find -lpython3.2m
3.1: /usr/bin/ld: cannot find -lpython3.1
2.7: /usr/bin/ld: cannot find -lpython2.7
2.6: /usr/bin/ld: cannot find -lpython2.6

Tested attached patch with success, will carry this patch locally in all FreeBSD Python ports until it merged. Let's close this 5 year old nasty :)

----------
assignee:  -> eric.araujo
components: +Distutils
nosy: +eric.araujo, koobs, tarek
title: cannot find -lpythonX.X when buinding Python on FreeBSD -> cannot find -lpythonX.X when building Python on FreeBSD with --enable-shared
versions: +Python 2.6, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Sep 18 12:28:22 2013
From: report at bugs.python.org (Dmi Baranov)
Date: Wed, 18 Sep 2013 10:28:22 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379500102.52.0.954576711968.issue19038@psf.upfronthosting.co.za>


Dmi Baranov added the comment:

Guys, don't talk with bot - here is a summary [1] and his "history of glory" with patches to contributors lists [2]. Better way is cut-off this email from python.org services.

[1] http://wiki.gbatemp.net/wiki/User:TaeWong
[2] https://www.google.com/search?q=seotaewong40 at gmail.com

----------
nosy: +dmi.baranov
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 13:38:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Sep 2013 11:38:28 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <3cfzhz6HjLz7Lm9@mail.python.org>


Roundup Robot added the comment:

New changeset 6396d1fc72da by R David Murray in branch '3.1':
#14984: On POSIX, enforce permissions when reading default .netrc.
http://hg.python.org/cpython/rev/6396d1fc72da

New changeset 0d9e471221da by R David Murray in branch '3.2':
Merge #14984: On POSIX, enforce permissions when reading default .netrc.
http://hg.python.org/cpython/rev/0d9e471221da

New changeset b657196b9fc2 by R David Murray in branch '3.3':
Merge #14984: On POSIX, enforce permissions when reading default .netrc.
http://hg.python.org/cpython/rev/b657196b9fc2

New changeset bfc86caf98ae by R David Murray in branch 'default':
Merge #14984: On POSIX, enforce permissions when reading default .netrc.
http://hg.python.org/cpython/rev/bfc86caf98ae

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 13:40:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Sep 2013 11:40:47 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <1379504447.32.0.0177290127698.issue14984@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Benjamin.  And Thank you, Bruno.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 14:32:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Sep 2013 12:32:53 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1379507573.03.0.0779120072243.issue4366@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Why special-case FreeBSD in the patch? Shouldn't this be done for nearly all Unix systems? (or, at the very least or BSD-likes)?

----------
components: +Library (Lib)
nosy: +pitrou
stage:  -> patch review
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Sep 18 14:34:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Sep 2013 12:34:23 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379507663.35.0.626052250614.issue19037@psf.upfronthosting.co.za>


R. David Murray added the comment:

Janzert: Thanks for the patch.  A contributor agreement is not needed for this patch, since it just moves code around, but you might want to submit one in case you make any other contributions.  Also let us know what name to use in the Misc/ACKS file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Wed Sep 18 14:39:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Sep 2013 12:39:32 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <3cg13R6fQpz7Ljk@mail.python.org>


Roundup Robot added the comment:

New changeset 68e5e416e8af by R David Murray in branch '3.3':
#19037: adjust file times *before* moving maildir files into place.
http://hg.python.org/cpython/rev/68e5e416e8af

New changeset 041caa64486b by R David Murray in branch '2.7':
#19037: adjust file times *before* moving maildir files into place.
http://hg.python.org/cpython/rev/041caa64486b

New changeset 261910257af6 by R David Murray in branch 'default':
Merge #19037: adjust file times *before* moving maildir files into place.
http://hg.python.org/cpython/rev/261910257af6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Wed Sep 18 14:39:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Sep 2013 12:39:59 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379507999.65.0.67642745289.issue19037@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Wed Sep 18 14:48:49 2013
From: report at bugs.python.org (koobs)
Date: Wed, 18 Sep 2013 12:48:49 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1379508529.54.0.343282117553.issue4366@psf.upfronthosting.co.za>


koobs added the comment:

Concur, and then also, why special case linux, gnu and sunos?

The comment is:

# Python's library directory [[must]] be appended to library_dirs (emphasis mine)

Is the real question then "in what cases should the library path NOT be added?" ?

I also note Christian used a different approach (#msg76118), electing to unconditionally add the path in setup.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Wed Sep 18 15:00:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Sep 2013 13:00:17 +0000
Subject: [issue14984] netrc module allows read of non-secured .netrc file
In-Reply-To: <1338641621.72.0.0114973811866.issue14984@psf.upfronthosting.co.za>
Message-ID: <3cg1WN6Yw8z7Lmf@mail.python.org>


Roundup Robot added the comment:

New changeset fb3ad8a749c8 by R David Murray in branch '2.6':
#14984: only import pwd on POSIX.
http://hg.python.org/cpython/rev/fb3ad8a749c8

New changeset 88e62c43e443 by R David Murray in branch '2.7':
Merge #14984: only import pwd on POSIX.
http://hg.python.org/cpython/rev/88e62c43e443

New changeset 713d71048ab9 by R David Murray in branch '3.1':
#14984: only import pwd on POSIX.
http://hg.python.org/cpython/rev/713d71048ab9

New changeset ef90c40fe6cf by R David Murray in branch '3.2':
Merge #14984: only import pwd on POSIX.
http://hg.python.org/cpython/rev/ef90c40fe6cf

New changeset b8206cb2c4ee by R David Murray in branch '3.3':
Merge #14984: only import pwd on POSIX.
http://hg.python.org/cpython/rev/b8206cb2c4ee

New changeset ad9a5ded5cf6 by R David Murray in branch 'default':
Merge #14984: only import pwd on POSIX.
http://hg.python.org/cpython/rev/ad9a5ded5cf6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14984>
_______________________________________

From report at bugs.python.org  Wed Sep 18 16:50:03 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Wed, 18 Sep 2013 14:50:03 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379515803.11.0.700920505418.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

The first link is a GBAtemp page.
The second link is a search.
You want to apply this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 16:58:58 2013
From: report at bugs.python.org (Bastien Montagne)
Date: Wed, 18 Sep 2013 14:58:58 +0000
Subject: [issue16129] No good way to set 'PYTHONIOENCODING' when embedding
 python.
In-Reply-To: <1349355495.01.0.406130423626.issue16129@psf.upfronthosting.co.za>
Message-ID: <1379516338.26.0.566325124631.issue16129@psf.upfronthosting.co.za>


Bastien Montagne added the comment:

Hi,

Decided to give it a try and implement suggested Py_SetStandardStreamEncoding, see attached patch.

A quick test with Blender under Linux (with an ASCII console) seems to work OK, unfortunatly I do not have Windows to test it where it really matters...

That's my first piece of code ever written for Python, I hope it does not contain too much obvious errors!

----------
nosy: +mont29
Added file: http://bugs.python.org/file31808/setstdio.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16129>
_______________________________________

From report at bugs.python.org  Wed Sep 18 17:06:41 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 Sep 2013 15:06:41 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379516801.12.0.778774919209.issue19038@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Let's try a plain rejection first.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 17:11:36 2013
From: report at bugs.python.org (Tae-Wong SEO)
Date: Wed, 18 Sep 2013 15:11:36 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379517096.66.0.626571074266.issue19038@psf.upfronthosting.co.za>


Tae-Wong SEO added the comment:

Let's restore status and resolution without rejecting.

You want to apply this.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 17:53:13 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 18 Sep 2013 15:53:13 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1379519593.42.0.506579232619.issue19038@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Wed Sep 18 18:16:19 2013
From: report at bugs.python.org (janzert)
Date: Wed, 18 Sep 2013 16:16:19 +0000
Subject: [issue19037] mailbox module modifies maildir file times after moving
 from tmp directory
In-Reply-To: <1379357916.81.0.287125303462.issue19037@psf.upfronthosting.co.za>
Message-ID: <1379520979.36.0.503916141075.issue19037@psf.upfronthosting.co.za>


janzert added the comment:

Thanks for committing the fix.

Figured I should finally get it done and signed the online CLA when I submitted this issue. I assume it just takes a while for someone to go through and apply the appropriate flag?

This change seems rather insubstantial for an ACKS line so I certainly don't mind waiting. Since a certain Birkenfeld became Brandl I know names are a bit sensitive for some python core devs. So while my personal preference would go to Janzert* the one that fits Python custom is Brian Haskin.

* Janzert is the most widely used and distinct identifier for my open source and online activity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19037>
_______________________________________

From report at bugs.python.org  Wed Sep 18 19:15:43 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 18 Sep 2013 17:15:43 +0000
Subject: [issue18918] help('FILES') finds no documentation
In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>
Message-ID: <1379524543.38.0.789973072249.issue18918@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello. The 'File objects' section was removed in Python 3, with this issue http://bugs.python.org/issue7508, but not the topic from pydoc.py. As I understand, there is no point in having this, because there isn't a `file` type anymore.
The attached patched removes the `FILES` topic, which used an undefined reference ('bltin-file-objects', removed in the mentioned issue).

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31809/pydoc_files.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18918>
_______________________________________

From report at bugs.python.org  Wed Sep 18 19:26:59 2013
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 18 Sep 2013 17:26:59 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379525219.32.0.610793485735.issue19019@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

If you find it difficult to find people with 10.6 systems to build a Python dmg for that platform, give me a shout. I'm not planning on replacing my system anytime soon. I have 10.6.8 installed, and what I believe to be the last Xcode version to support it, 3.2.something.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Wed Sep 18 19:41:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Sep 2013 17:41:51 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379526111.14.0.188922042675.issue19019@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks, Skip. At the moment, finding platforms for building and testing is not a problem: I have at hand running versions of the latest releases for 10.3 onwards. :)  (Buildbots for automated testing are another issue, though. We have a critical need for buildbots running more recent versions of OS X, though.  At the moment, the only OS X buildbot is one running 10.4 (Tiger).  If anyone is able to provide newer ones, please see http://python.org/dev/buildbot/.  Or, if someone would like to donate hardware, I may be able to arrange hosting for it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Wed Sep 18 20:50:33 2013
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 18 Sep 2013 18:50:33 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379530233.4.0.473161033914.issue19019@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

I guess snakebite (http://www.snakebite.net/) never materialized?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Wed Sep 18 21:05:45 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Sep 2013 19:05:45 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379531145.07.0.718679704105.issue19019@psf.upfronthosting.co.za>


Ned Deily added the comment:

Snakebite did provide some additional OS X buildbots for a while but, AFAIK, they have been offline for some months now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Wed Sep 18 21:41:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Sep 2013 19:41:09 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379533269.18.0.670010606976.issue19019@psf.upfronthosting.co.za>


R. David Murray added the comment:

Snakebite is live, and python committers can get shell access on the bots, as originally planned.  Some of the bots are offline, but most are running.  I don't see any OS X servers in the list, though, unless Antoine deleted them (but there are several other currently-offline ones he hasn't deleted, so I doubt that).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Wed Sep 18 22:17:50 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 18 Sep 2013 20:17:50 +0000
Subject: [issue18790] incorrect text in argparse add_help example
In-Reply-To: <1377025104.92.0.641943823333.issue18790@psf.upfronthosting.co.za>
Message-ID: <1379535470.49.0.298733438438.issue18790@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This was reported a couple of times before on the docs list.

- https://mail.python.org/pipermail/docs/2013-April/015145.html
- https://mail.python.org/pipermail/docs/2013-June/015016.html
- https://mail.python.org/pipermail/docs/2013-September/015505.html

----------
nosy: +berker.peksag, ezio.melotti
stage:  -> patch review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18790>
_______________________________________

From report at bugs.python.org  Wed Sep 18 22:30:26 2013
From: report at bugs.python.org (intgr)
Date: Wed, 18 Sep 2013 20:30:26 +0000
Subject: [issue16512] imghdr doesn't support jpegs with an ICC profile
In-Reply-To: <1353406880.2.0.236043197389.issue16512@psf.upfronthosting.co.za>
Message-ID: <1379536226.62.0.157885589448.issue16512@psf.upfronthosting.co.za>


intgr added the comment:

I vote we forget about JFIF/Exif headers and only use \xff\xd8 to identify the file. They are optional and there are tons of files out in the wild without such headers, for example: https://coverartarchive.org/release/5044b557-a9ed-4a74-b763-e20580ced85d/3354872309.jpg

Proposed patch at https://bitbucket.org/intgr/cpython/commits/012cde305316e22a999d674a0a009200d3e76fdb

----------
hgrepos: +210
nosy: +intgr

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16512>
_______________________________________

From report at bugs.python.org  Thu Sep 19 00:16:57 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 18 Sep 2013 22:16:57 +0000
Subject: [issue16878] argparse: positional args with nargs='*' defaults to []
In-Reply-To: <1357465299.57.0.35284685768.issue16878@psf.upfronthosting.co.za>
Message-ID: <1379542617.12.0.892250068954.issue16878@psf.upfronthosting.co.za>


paul j3 added the comment:

On a related point, the 'action.required' value is set differently for '?' and '*' positionals.  

    if kwargs.get('nargs') not in [OPTIONAL, ZERO_OR_MORE]:
        kwargs['required'] = True
    if kwargs.get('nargs') == ZERO_OR_MORE and 'default' not in kwargs:
        kwargs['required'] = True

OPTIONAL is always not required, ZERO_OR_MORE is not required if it has a default.  But for reasons discussed here, that 'required' value makes little difference.  

`parse_args` checks that all 'required' arguments have been seen, but a ZERO_OR_MORE positional is always seen (i.e. it matches an empty string).  

Usage formatting always uses '[%s [%s ...]]' with ZERO_OR_MORE, regardless of the 'required' attribute.

The only place where this 'required' value seems to matter is when adding such an argument to a mutually exclusive group.  But if an unused '*' positional is going to get a '[]' value anyways, why should it be excluded from such a use?

If I remove the 

    if kwargs.get('nargs') == ZERO_OR_MORE and 'default' not in kwargs:

test, test_argparse.py still runs fine.

http://bugs.python.org/issue18943 is a possibly related issue, involving  a 'is not action.default' test in a mutually exclusive group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16878>
_______________________________________

From report at bugs.python.org  Thu Sep 19 02:59:57 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 Sep 2013 00:59:57 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
Message-ID: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>


New submission from Georg Brandl:

As discussed on python-dev.

----------
assignee: docs at python
components: Documentation
files: license_fixup_33.patch
keywords: patch
messages: 198036
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Remove detailed listing of all versions from LICENSE, Doc/license.rst
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31810/license_fixup_33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Thu Sep 19 03:00:13 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 Sep 2013 01:00:13 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
In-Reply-To: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>
Message-ID: <1379552413.17.0.1679347932.issue19043@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Added file: http://bugs.python.org/file31811/license_fixup_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Thu Sep 19 03:13:17 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 Sep 2013 01:13:17 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1379553197.1.0.874366081974.issue4366@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Thu Sep 19 03:23:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 19 Sep 2013 01:23:52 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379553832.93.0.351257845229.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, some slight reorganizing.  Current patch gives preferential treatment to getattr, falling back on dict lookup if getattr raises an exception or if the resulting object's class is not found in the mro (including the metaclass mro).

Amazingly, nothing appeared to break in the test suite.  :)

If no kibitzing in the next couple days I'll write some tests to better excercise the metaclass portion (I used Enum for interactive testing).

----------
Added file: http://bugs.python.org/file31812/issue19030.stoneleaf.03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Thu Sep 19 03:24:14 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 19 Sep 2013 01:24:14 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
In-Reply-To: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>
Message-ID: <1379553854.46.0.537628258387.issue19043@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Thu Sep 19 03:40:57 2013
From: report at bugs.python.org (paul j3)
Date: Thu, 19 Sep 2013 01:40:57 +0000
Subject: [issue11708] argparse: suggestion for formatting optional positional
 args
In-Reply-To: <1301372470.63.0.394832292121.issue11708@psf.upfronthosting.co.za>
Message-ID: <1379554857.35.0.777539053411.issue11708@psf.upfronthosting.co.za>


paul j3 added the comment:

This is a HelpFormatter function that takes a list of formatted actions, and groups contiguous blocks of optional positional actions.  It accounts for optionals (via prefix_chars) and mutually exclusive groups.

Since it assumes 'parts' is a list, rather than string, it works best with the '_format_actions_usage' method in the patch that I submitted to http://bugs.python.org/issue11874 

    def _positionals_regroup(self, parts):
        # change '[arg1] [arg2]' to '[arg1 [arg2]]'
        # apply to a list of formatted arguments
        # don't apply to optionals (with prefix chars) or groups
        chars = getattr(self, 'prefix_chars',set('-'))
        R = _re.compile(r'\] \[(.*)\]')
        result = []
        text = None
        while  parts:
            part = parts.pop()
            if part:
                if part[0]=='[' and part[1] not in chars and '|' not in part:
                    if text:
                        text = ' '.join([part, text])
                    else:
                        text = part
                    if R.search(text):
                        text = R.sub(' [\g<1>]]',text)
                else:
                    if text:
                        result.insert(0,text)
                        text = None
                    result.insert(0,part)
        if text:
            result.insert(0,text)
        return result

To avoid compatibility issues it could implemented in a subclassed HelpFormatter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11708>
_______________________________________

From report at bugs.python.org  Thu Sep 19 03:49:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Sep 2013 01:49:15 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
In-Reply-To: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>
Message-ID: <1379555355.89.0.0420101346006.issue19043@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Thu Sep 19 05:38:53 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Thu, 19 Sep 2013 03:38:53 +0000
Subject: [issue19044] getaddrinfo raises near-useless exception
Message-ID: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

I received a bugreport for a Python application that contains the following stacktrace:

>   File "/usr/lib/python3.3/http/client.py", line 1057, in endheaders
>     self._send_output(message_body)
>   File "/usr/lib/python3.3/http/client.py", line 902, in _send_output
>     self.send(msg)
>   File "/usr/lib/python3.3/http/client.py", line 840, in send
>     self.connect()
>   File "/usr/lib/python3.3/http/client.py", line 1194, in connect
>     self.timeout, self.source_address)
>   File "/usr/lib/python3.3/socket.py", line 417, in create_connection
>     for res in getaddrinfo(host, port, 0, SOCK_STREAM):
> OSError: [Errno 0] Error

My guess is that something went wrong with the name resolution, but it seems near impossible to handle this in the application because apparently the exception contains no machine usable useful informaton at all. 


It would be nice if whatever information Python used to determine that the getaddrinfo call failed could be included in the exception, so that it can be properly caught and handled.

----------
components: Library (Lib)
messages: 198039
nosy: Nikratio
priority: normal
severity: normal
status: open
title: getaddrinfo raises near-useless exception
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19044>
_______________________________________

From report at bugs.python.org  Thu Sep 19 06:00:55 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Sep 2013 04:00:55 +0000
Subject: [issue19044] getaddrinfo raises near-useless exception
In-Reply-To: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>
Message-ID: <1379563255.47.0.215603004762.issue19044@psf.upfronthosting.co.za>


Ned Deily added the comment:

This looks like a platform bug. What platform was this running on?  A web search turns up other reports of the system getaddrinfo() returning errno = 0 due to a glibc bug, for example, https://bugzilla.redhat.com/show_bug.cgi?id=958652.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19044>
_______________________________________

From report at bugs.python.org  Thu Sep 19 08:10:50 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 19 Sep 2013 06:10:50 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379571050.96.0.7043715593.issue18553@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Georg: Thanks for spotting. I feel bad for the mistake. I shall correct it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Thu Sep 19 08:25:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 06:25:37 +0000
Subject: [issue19044] getaddrinfo raises near-useless exception
In-Reply-To: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>
Message-ID: <1379571937.03.0.510471447527.issue19044@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19044>
_______________________________________

From report at bugs.python.org  Thu Sep 19 09:02:59 2013
From: report at bugs.python.org (Borut Podlipnik)
Date: Thu, 19 Sep 2013 07:02:59 +0000
Subject: [issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed
Message-ID: <1379574179.05.0.180767783928.issue19045@psf.upfronthosting.co.za>


New submission from Borut Podlipnik:

# make
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/grammar1.o Parser/grammar1.c
"Parser/grammar1.c", line 39: Warning: String literal converted to char* in initialization.
1 Warning(s) detected.
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/listnode.o Parser/listnode.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/node.o Parser/node.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/parser.o Parser/parser.c
CC -c  -g -DNDEBUG -O  -I. -IInclude -I./Include  -DPy_BUILD_CORE -o Parser/parsetok.o Parser/parsetok.c
"Parser/parsetok.c", line 250: Error: Cannot assign void* to char*.
1 Error(s) detected.
*** Error code 2
make: Fatal error: Command failed for target `Parser/parsetok.o'

----------
components: Build
messages: 198042
nosy: podlipnik
priority: normal
severity: normal
status: open
title: Make on Solaris 11 x64 with OracleStudio12.3 failed
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19045>
_______________________________________

From report at bugs.python.org  Thu Sep 19 09:10:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Sep 2013 07:10:24 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <3cgTjC6cFBz7Ljs@mail.python.org>


Roundup Robot added the comment:

New changeset 2b7f11ba871c by Senthil Kumaran in branch '3.3':
Correcting the mistake in 14ba90816930
http://hg.python.org/cpython/rev/2b7f11ba871c

New changeset e839e524a7d5 by Senthil Kumaran in branch 'default':
Correcting the mistake in 678e3c0d2d99
http://hg.python.org/cpython/rev/e839e524a7d5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Thu Sep 19 09:12:55 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 19 Sep 2013 07:12:55 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379574775.89.0.454050350546.issue18553@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed now. Ascertained myself by doing hg diff -r tip^ -U 10 on local commits before pushing. :-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Thu Sep 19 09:14:58 2013
From: report at bugs.python.org (Michael Herrmann)
Date: Thu, 19 Sep 2013 07:14:58 +0000
Subject: [issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad
 argument to internal function
Message-ID: <1379574898.14.0.174335958635.issue19046@psf.upfronthosting.co.za>


New submission from Michael Herrmann:

I'm on 32 bit Python 2.7.3 and 64 bit Windows 7. I am working on a complex, multithreaded application which uses COM to communicate with other processes.

My application uses regular expressions in a few (but not very many) places. An example re I am trying to match is 'quit(\\(.*\\))?', an example input would be 'quit()'. Nothing exciting.

Very frustratingly, even though the regular expressions and inputs are the same, I spuriously get errors of the following form:

Traceback (most recent call last):
  ...
  File "re.pyc", line 137, in match
SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function

I have seen the bug many times on 2.7.3. I briefly tried to reproduce it on 2.7.5 and it did not occur. This may be because the bug only occurs spuriously and I was unlucky, or because the bug no longer exists in 2.7.5. My (unverified) hunch is that the bug is not in 2.7.5 anymore. 

I have a C unhandled exception handler installed in my application. What's interesting is that the bug frequently seems to occur together with an unhandled memory access violation (exception code C0000005). When this is the case, the Python interpreter hangs or crashes.

I have not seen similar crashes in my application at other points; only when working with regular expressions and seeing the above stack trace.

----------
components: Regular Expressions, Windows
messages: 198045
nosy: ezio.melotti, mherrmann.at, mrabarnett
priority: normal
severity: normal
status: open
title: SystemError: ..\Objects\weakrefobject.c:903: bad argument to internal function
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19046>
_______________________________________

From report at bugs.python.org  Thu Sep 19 09:54:55 2013
From: report at bugs.python.org (Balazs)
Date: Thu, 19 Sep 2013 07:54:55 +0000
Subject: [issue19044] getaddrinfo raises near-useless exception
In-Reply-To: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>
Message-ID: <1379577295.79.0.419843282919.issue19044@psf.upfronthosting.co.za>


Changes by Balazs <czviin at gmail.com>:


----------
nosy: +balazs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19044>
_______________________________________

From report at bugs.python.org  Thu Sep 19 10:03:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Sep 2013 08:03:54 +0000
Subject: [issue19047] Clarify weakref.finalize objects are kept alive
 automatically
Message-ID: <1379577834.67.0.113922099701.issue19047@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I was just looking at weakref.finalize objects trying to figure out if they solve a problem I'm thinking about (they do), and I couldn't figure out from the class documentation ([1]) whether or not I needed to take care of keeping the object returned from weakref.finalize alive.

I don't (the module keeps finalizers alive automatically), but this critical piece of information is only mentioned in the example much further down in the documentation ([2]).

[1] http://docs.python.org/dev/library/weakref#weakref.finalize
[2] http://docs.python.org/dev/library/weakref#finalizer-objects

The 3.4 What's New should also explicitly mention weakref.finalize as an alternative to __del__ methods (perhaps as a comment in the section on PEP 422, perhaps just in the weakref section)

----------
assignee: docs at python
components: Documentation
messages: 198046
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify weakref.finalize objects are kept alive automatically
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19047>
_______________________________________

From report at bugs.python.org  Thu Sep 19 10:25:12 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Sep 2013 08:25:12 +0000
Subject: [issue19047] Assorted weakref docs improvements
In-Reply-To: <1379577834.67.0.113922099701.issue19047@psf.upfronthosting.co.za>
Message-ID: <1379579112.33.0.393587432785.issue19047@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Changing the title, since I spotted a few other problems as well.

The weakref docs still refer to module globals being set to None during shutdown. That is no longer the case. There are also some assumptions about cycles with __del__ methods not being garbage collected, which is no longer true given PEP 442's improvements to module finalization.

I also realised that the introduction of weakref.finalize and the elimination of the "set globals to None" hack gives Python relatively straightforward module destructors [1]:

    import weakref, sys
    mod = sys.modules[__name__]
    def del_this():
        # implicit ref to the module globals from the function body
    weakref.finalize(mod, del_this)

[1] https://mail.python.org/pipermail/import-sig/2013-September/000748.html

----------
title: Clarify weakref.finalize objects are kept alive automatically -> Assorted weakref docs improvements

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19047>
_______________________________________

From report at bugs.python.org  Thu Sep 19 11:19:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 09:19:50 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
Message-ID: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

An itertools.tee object can cache an arbitrary number of objects (pointers), but its sys.getsizeof() value will always remain the same.

----------
components: Library (Lib)
messages: 198048
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: itertools.tee doesn't have a __sizeof__ method
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 11:21:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 09:21:08 +0000
Subject: [issue19049] itertools.tee isn't 64-bit compliant
Message-ID: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

itertools.tee uses ints rather than Py_ssize_t for indices. Using Py_ssize_t would not make the object bigger, since other fields will already be pointer-aligned.

----------
messages: 198049
nosy: pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: itertools.tee isn't 64-bit compliant
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 12:04:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 10:04:12 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379585052.9.0.618365035017.issue19048@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I find the implementation of itertools.tee a bit weird: why does teedataobject have to be a PyObject? It seems to complicate things and make them less optimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 12:06:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 10:06:09 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379585169.64.0.0767475065298.issue19048@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Anywhere, here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file31813/tee_sizeof.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 12:43:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 10:43:16 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379587396.71.0.0359187504262.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue15475.

----------
superseder:  -> Correct __sizeof__ support for itertools

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 12:49:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 10:49:21 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379587761.01.0.841355569477.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Hmm, no, I'm wrong, it's not a duplication.

----------
superseder: Correct __sizeof__ support for itertools -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 12:50:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 10:50:20 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379587820.97.0.464438123145.issue19048@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:02:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 11:02:04 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379588524.57.0.671283183822.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure that sys.getsizeof() should recursively count all Python subobjects. That is why I had omitted tee() in my patch.

>>> sys.getsizeof([[]])
36
>>> sys.getsizeof([list(range(10000))])
36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:05:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 11:05:41 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379588524.57.0.671283183822.issue19048@psf.upfronthosting.co.za>
Message-ID: <88539910.3656202.1379588735439.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I'm not sure that sys.getsizeof() should recursively count all Python
> subobjects.

Those are private subobjects. They are not visible to the programmer
(except perhaps by calling __reduce__ or __setstate__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:29:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 11:29:32 +0000
Subject: [issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad
 argument to internal function
In-Reply-To: <1379574898.14.0.174335958635.issue19046@psf.upfronthosting.co.za>
Message-ID: <1379590172.69.0.986067650654.issue19046@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is there any reason why you don't switch to 2.7.5 and let your application run longer?

(FWIW, this may be issue #16602)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19046>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:31:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 11:31:36 +0000
Subject: [issue19047] Assorted weakref docs improvements
In-Reply-To: <1379577834.67.0.113922099701.issue19047@psf.upfronthosting.co.za>
Message-ID: <1379590296.78.0.420360275719.issue19047@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Doc patches certainly welcome :-)

----------
nosy: +pitrou, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19047>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:32:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 11:32:29 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
In-Reply-To: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>
Message-ID: <1379590349.78.0.802773724129.issue19043@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks good to me. Python 1.5.2 (which I've never used) is the best Python anyway!

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:37:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 11:37:17 +0000
Subject: [issue19049] itertools.tee isn't 64-bit compliant
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379590637.81.0.0425819284688.issue19049@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Simple patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file31814/tee_64b.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:47:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 11:47:47 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379591267.45.0.528959024059.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ideally, test specification should be separate from test execution. That is, it should be possible to keep the TestCase around (or whatever instantiates it, e.g. a factory) but get rid of its per-test-execution attributes.

Perhaps restoring the original __dict__ contents would do the trick?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:48:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 11:48:13 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379591293.2.0.269395220303.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thy are visible by calling gc.get_referents(). High-level function can use this to count recursive size of objects.

>>> import sys, gc, itertools
>>> def gettotalsizeof(*args, seen=None):
...     if seen is None:
...         seen = {}
...     sum = 0
...     for obj in args:
...         if id(obj) not in seen:
...             seen[id(obj)] = obj
...             sum += sys.getsizeof(obj)
...             sum += gettotalsizeof(*gc.get_referents(obj), seen=seen)
...     return sum
... 
>>> a, b = tee(range(10000))
>>> sum(next(a) for i in range(1000))
499500
>>> gettotalsizeof(a)
750
>>> gettotalsizeof(b)
18734

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 13:58:35 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 19 Sep 2013 11:58:35 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379591915.71.0.336158598516.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

That would only be a shallow copy, so I'm not sure it's worth the effort. The test has the opportunity in the setUp to ensure that initial state is correct - so I would leave that per test. Obviously sharing state between tests is prima facie bad, but any framework reusing test suites is doing that already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 14:39:47 2013
From: report at bugs.python.org (Florent Rougon)
Date: Thu, 19 Sep 2013 12:39:47 +0000
Subject: [issue12944] Accept arbitrary files for packaging's upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1379594387.59.0.348093509629.issue12944@psf.upfronthosting.co.za>


Changes by Florent Rougon <frougon at users.sourceforge.net>:


----------
nosy: +frougon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12944>
_______________________________________

From report at bugs.python.org  Thu Sep 19 14:58:29 2013
From: report at bugs.python.org (Daniel Rohlfing)
Date: Thu, 19 Sep 2013 12:58:29 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
Message-ID: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>


New submission from Daniel Rohlfing:

This snippet let my interpreter crash immediately:

> import sys, io
> io.open(sys.stdout.fileno(), 'wb')
> fd.close()
> sys.stdout.write("now writing on stdout will cause a crash")

That's happened on
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32
Windows 7 SP1 x64

The same code let Python 3.3.2 throw an exception like this:
Exception OSError: OSError(9, 'Bad file descriptor') in <_io.TextIOWrapper name='<stdout>' mode='w' encoding='cp850'> ignored

----------
components: Library (Lib)
messages: 198063
nosy: damiro
priority: normal
severity: normal
status: open
title: crash while writing to a closed file descriptor
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:00:44 2013
From: report at bugs.python.org (Daniel Rohlfing)
Date: Thu, 19 Sep 2013 13:00:44 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1379595644.52.0.586116970797.issue19050@psf.upfronthosting.co.za>


Daniel Rohlfing added the comment:

the correct snippet is:

> fd = io.open(sys.stdout.fileno(), 'wb')
> fd.close()
> sys.stdout.write("now writing on stdout will cause a crash")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:03:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 13:03:47 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379591293.2.0.269395220303.issue19048@psf.upfronthosting.co.za>
Message-ID: <1097685621.4067359.1379595821047.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Thy are visible by calling gc.get_referents().

That's totally besides the point. The point is that those
objects are invisible in normal conditions, not that they can't
be read using advanced implementation-dependent tricks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:06:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 13:06:50 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1379591915.71.0.336158598516.issue11798@psf.upfronthosting.co.za>
Message-ID: <384150135.4076465.1379596004302.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> That would only be a shallow copy, so I'm not sure it's worth the
> effort. The test has the opportunity in the setUp to ensure that
> initial state is correct - so I would leave that per test.

I don't understand your objection. The concern is to get rid of old
state after test execution.

> Obviously
> sharing state between tests is prima facie bad, but any framework
> reusing test suites is doing that already.

What do you mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:09:06 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Sep 2013 13:09:06 +0000
Subject: [issue19047] Assorted weakref docs improvements
In-Reply-To: <1379590296.78.0.420360275719.issue19047@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fniWnDvesBF8j6-G+uxGR3ZRhwzxt2mvCm5-susL6L8Q@mail.gmail.com>


Nick Coghlan added the comment:

I was initially thinking to myself "I have a source checkout right
here, I should just fix it, even though I'm at work and want to go
home"... and then I realised the potential scope of the fixes needed,
given the longstanding misbehaviours these docs assume still exist :)

(I also just realised the clone on my work system is ridiculously
stale, so even updating it will likely take a while at this point)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19047>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:13:47 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 19 Sep 2013 13:13:47 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <384150135.4076465.1379596004302.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <4118697B-204A-402F-AF22-80EDF60F9594@voidspace.org.uk>


Michael Foord added the comment:

On 19 Sep 2013, at 14:06, Antoine Pitrou <report at bugs.python.org> wrote:

> 
> Antoine Pitrou added the comment:
> 
>> That would only be a shallow copy, so I'm not sure it's worth the
>> effort. The test has the opportunity in the setUp to ensure that
>> initial state is correct - so I would leave that per test.
> 
> I don't understand your objection. The concern is to get rid of old
> state after test execution.
> 

If the object state includes mutable objects then restoring the previous dictionary will just restore the same mutable (and likely mutated) object. To *properly* restore state you'd either need to deepcopy the dictionary or reinstantiate the testcase (not reuse it in other words). I'd rather leave it up to each test to ensure it reinitialises attributes in setUp than add further complexity that only does part of the job.

>> Obviously
>> sharing state between tests is prima facie bad, but any framework
>> reusing test suites is doing that already.
> 
> What do you mean?

Any framework that is currently reusing test suites is re-using testcase instances. They are already sharing state between the runs.

In fact messing with testcase dictionaries is a further possible cause of backwards incompatibility for those suites. 

> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11798>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:36:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 13:36:54 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <4118697B-204A-402F-AF22-80EDF60F9594@voidspace.org.uk>
Message-ID: <1372998580.4176767.1379597807947.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> If the object state includes mutable objects then restoring the
> previous dictionary will just restore the same mutable (and likely
> mutated) object.

I don't understand what you're talking about. Which mutable objects
exactly? I'm talking about copying the dict before setUp.

> >> Obviously
> >> sharing state between tests is prima facie bad, but any framework
> >> reusing test suites is doing that already.
> > 
> > What do you mean?
> 
> Any framework that is currently reusing test suites is re-using
> testcase instances. They are already sharing state between the runs.

They are not sharing it, since setUp will usually create the state
anew. What we're talking about is cleaning up the state after tearDown
is run, instead of waiting for the next setUp call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:39:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 13:39:52 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379597992.98.0.0112220976822.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The point is that your patch breaks functions like gettotalsizeof(). It makes impossible to get a total size of general object.

It will be better to add gettotalsizeof() to the stdlib (or add an optional parameter to sys.getsizeof() for recursive counting).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:40:14 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 19 Sep 2013 13:40:14 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379598014.37.0.875403427342.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

Ah right, my mistake. Before setUp there shouldn't be test state. (Although tests are free to do whatever they want in __init__ too and I've seen plenty of TestCase subclasses using __init__ when they should be using setUp.)

Essentially though _cleanup is a backwards compatibility feature - and suites that need _cleanup as a public api are already living without testcase dict cleanup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 15:56:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 13:56:04 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379598964.34.0.712557324226.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That said, I agree that the __dict__ proposal is a hack, but as is the current _removetestAtIndex mechanism.

The only clean solution I can think of would be to have two separate classes:
- a TestSpec which contains execution-independent data about a test case, and knows how to instantiate it
- a TestCase that is used for the actual test execution, but isn't saved in the test suite

Maybe it's possible to do this without any backwards compat problem by making TestSuite.__iter__ always return TestCases (but freshly-created ones, from the inner test specs). The main point of adaptation would be TestLoader.loadTestsFromTestCase().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:02:18 2013
From: report at bugs.python.org (Drekin)
Date: Thu, 19 Sep 2013 14:02:18 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
 correctly
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1379599338.21.0.942329121924.issue10042@psf.upfronthosting.co.za>


Drekin added the comment:

Hello, I have run into this when I wanted to use OrderedEnum and the example in enum docs seemed too repetitive to me. It's nice to know that it's being worked on.

----------
nosy: +Drekin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:02:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 14:02:21 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379597992.98.0.0112220976822.issue19048@psf.upfronthosting.co.za>
Message-ID: <661895577.4252100.1379599334685.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> The point is that your patch breaks functions like gettotalsizeof().
> It makes impossible to get a total size of general object.

The thing is, "Total size" is generally meaningless. It can include
things such as the object's type, or anything transitively referenced
by the object, such as modules.

> It will be better to add gettotalsizeof() to the stdlib (or add an
> optional parameter to sys.getsizeof() for recursive counting).

This patch has *nothing* to do with recursive counting. It counts
the internal arrays of itertools.tee() as part of its memory size,
which is reasonable and expected. It does *not* count memory recursively:
it doesn't count the size of the itertools.tee()'s cached objects,
for example.

Recursive counting doesn't make sense with Python. Where do you stop
counting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:22:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 14:22:09 +0000
Subject: [issue19051] Unify buffered readers
Message-ID: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are some classes in gzip, bz2, lzma, and zipfile modules which implement buffered reader interface. They read chunks of data from underlied file object, decompress it, save in internal buffer, and provide common methods to read from this buffer. Maintaining of duplicated code is cumbersome and error prone. Proposed preliminary patch moves common code into new private class _io2._BufferedReaderMixin. If the proposition will be accepted in general, I'm going to write C version and move it into the io module. Perhaps even then merge it with io.BufferedIOBase.

The idea is that all buffered reading functions (read(), read1(), readline(), peek(), etc) can be expressed in the term of one function which returns raw unbuffered data. Subclasses need define only one such function and will got all buffered reader interface. In case of mentioned above classes this functions reads and decompresses a chunk of data from underlied file. The HTTPResponse class perhaps will benefit too (issue19009).

----------
components: IO, Library (Lib)
files: buffered_reader.diff
keywords: patch
messages: 198075
nosy: alanmcintyre, benjamin.peterson, nadeem.vawda, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: patch review
status: open
title: Unify buffered readers
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31815/buffered_reader.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:31:43 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 19 Sep 2013 14:31:43 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1379601103.12.0.0743073494196.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

Having TestLoader.loadTestsFromTestCase() return a "lazy suite" that defers testcase instantiation until iteration is a nice idea.

Unfortunately the TestSuite.addTests api iterates over a suite to add new tests. i.e. the code that builds a TestSuite for module probably already iterates over the suites returned by TestLoader.loadTestsFromTestCase - so the change would need to be more pervasive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:33:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 14:33:17 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379601197.25.0.663805040217.issue19051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here are benchmark script and its results.

----------
Added file: http://bugs.python.org/file31816/read_bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:34:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 14:34:26 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379601266.74.0.773713454176.issue19051@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31817/read_bench_cmp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:47:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 14:47:25 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379602045.65.0.718231422505.issue19051@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

See issue12053 for a more flexible primitive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 16:47:28 2013
From: report at bugs.python.org (Dmi Baranov)
Date: Thu, 19 Sep 2013 14:47:28 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379602048.23.0.214793011945.issue18553@psf.upfronthosting.co.za>


Dmi Baranov added the comment:

I found a little difference in isatty implementaions:

Windows
Determines whether a file descriptor is associated with a character device [1]

Unix
Test whether a file descriptor refers to a terminal [2]

So, we having a same behavior for pipes, but different for I/O redirection with pseudo-character devices:

$ ./python -c "import os;print(os.isatty(0))" < /dev/null
False

e:\PCbuild>python_d.exe -c "import os;print(os.isatty(0))" < NUL
True

Other pseudo devices works simular:
e:\PCbuild>python_d.exe -c "import os;print(os.isatty(0))" < CON
True

I having a snippet to fix that, should I open a new issue for patch?


[1] http://msdn.microsoft.com/en-us/library/f4s0ddew.aspx
[2] http://man7.org/linux/man-pages/man3/isatty.3.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:16:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 15:16:05 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1379601103.12.0.0743073494196.issue11798@psf.upfronthosting.co.za>
Message-ID: <1409825530.4487012.1379603759418.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Unfortunately the TestSuite.addTests api iterates over a suite to add
> new tests. i.e. the code that builds a TestSuite for module probably
> already iterates over the suites returned by
> TestLoader.loadTestsFromTestCase - so the change would need to be
> more pervasive.

addTests() could easily be tweaked to recognize that it gets passed a
TestSuite, and special-case that.

Also, TestCase objects could probably get an optional "spec" attribute
pointing to their TestSpec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:16:44 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 19 Sep 2013 15:16:44 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za>
Message-ID: <1379603804.26.0.457312085185.issue18553@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Hello Dmi,

> I having a snippet to fix that, should I open a new issue for patch?

Please open a new issue.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:26:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 15:26:00 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379604360.94.0.699623815139.issue19051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This primitive doesn't not well fit a case of compressed streams. A chunk of compressed data read from underlied file object can be uncompressed to unpredictable large data. We can't limit the size of buffer.

Another point is that buffer interface is not very appropriate for Python implementation. And we want left as much Python code in gzip, bz2, lzma and zipfile as possible. Copying from bytes into buffer and back will just waste resources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:26:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 15:26:22 +0000
Subject: [issue12053] Add prefetch() for Buffered IO (experiment)
In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za>
Message-ID: <1379604382.29.0.690428029637.issue12053@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12053>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:26:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 15:26:50 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379604410.18.0.647419920434.issue19051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This primitive doesn't not well fit a case of compressed streams. A chunk of compressed data read from underlied file object can be uncompressed to unpredictable large data. We can't limit the size of buffer.

Another point is that buffer interface is not very appropriate for Python implementation. And we want left as much Python code in gzip, bz2, lzma and zipfile as possible. Copying from bytes into buffer and back will just waste resources.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:26:56 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 15:26:56 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
Message-ID: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>


New submission from Joseph Warren:

I will add as a disclaimer to this bug report that I am relatively new to both the http spec, and Python programming, so I may have completely misunderstood something.

When I make a post request with some data (using libCurl), It sends the headers first, including one header, "Expect: 100-continue" and then waits for around a second, or until receiving a "100 Continue" response, before sending the rest of the data. (I have attached WireShark capture data as html to show this, I've also attached a dump showing how Apache behaves given the same request). 

This means that when I make such a request to a CGI script, hosted using CGIHTTPServer, and the script tries to read in the data, (for instance, using cgi.FieldStorage() ). Then the CGI script takes around a second to parse the data, since it hasn't been sent yet.

I currently have a work-around for this, which is to override CGIHTTPRequestHandler, and have it send a "100 Continue" response before doing anything else. A dump showing this is attached, this makes the connection much faster. This is fine for my application, as all CGI requests will be made in the same way, However it is not a general solution. 

The W3C, when defining Expect Headers, state (taken from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html);

A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status. 


I would like to offer to implement handling of the Expect header in BaseHTTPServer, however I would like some feedback before doing this, and to check that the current behaviour is not intended for some reason.

This change would make CGIHTTPServer much faster in my use case, and I suspect it would help other people.

----------
components: Library (Lib)
files: Wireshark_Captures.html
messages: 198084
nosy: Joseph.Warren
priority: normal
severity: normal
status: open
title: Python's CGIHTTPServer does not handle Expect: 100-continue gracefully which results in some Post requests being handled slowly.
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31818/Wireshark_Captures.html

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:29:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 15:29:16 +0000
Subject: [issue19053] read1() from zipfile returns empty data
Message-ID: <1379604556.3.0.19871630565.issue19053@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Bzip2 is block-based compression with large (up to 800 Kb) size of block. It means that while decompressor not read enough data it can't produce any output (actually this issue exists for other compression algorithms too, but less frequent). And the read1() method which makes only one low-level read can return empty bytes when there is still data available. This issue was fixed for gzip, bz2, and lzma modules in issue15546, but left in the zipfile module. In zipfile this bug less catastrophic because other read functions do not use read1() directly, but use lower level internal function.

----------
assignee: serhiy.storchaka
components: Library (Lib)
messages: 198085
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: read1() from zipfile returns empty data
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19053>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:29:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 15:29:53 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379604593.69.0.555730341887.issue19052@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
type: performance -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:44:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Sep 2013 15:44:09 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379605449.17.0.0315630236684.issue19052@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue 1346874.  It seems that we do not currently handle 'continue' correctly in general.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:46:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 15:46:33 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379605593.23.0.0135991331342.issue19051@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg198083

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:47:17 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Sep 2013 15:47:17 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379605637.18.0.66872320824.issue19048@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I like the definition of __sizeof__ that was discussed some time ago:
http://bugs.python.org/issue14520#msg157798

With that definition (do we have it somewhere in the docs, by the way?)
The current code works gives the correct answer.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:51:10 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 15:51:10 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379605870.46.0.948500912738.issue19052@psf.upfronthosting.co.za>


Joseph Warren added the comment:

Issue1346874 seems similar, but is talking about a failure to handle 100 Continue responses sent by a server to the client, this issue is in server code, and is a failure of BaseHttpServer to send 100 Continue responses to a client which expects them.

Please tell me if I'm mistaken/not making sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:56:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 15:56:10 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379605637.18.0.66872320824.issue19048@psf.upfronthosting.co.za>
Message-ID: <768471873.4605637.1379606163930.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I like the definition of __sizeof__ that was discussed some time ago:
> http://bugs.python.org/issue14520#msg157798

The problem is that that definition isn't helpful.
If we ever change itertools.tee to use non-PyObjects internally, suddenly
its sys.getsizeof() would have to return much larger numbers despite
visible behaviour not having changed at all (and despite the memory
overhead being actually lower).

And gc.get_referents() is really a low-level debugging tool, certainly
not a "reflection API" (inspect would serve that role).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 17:57:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Sep 2013 15:57:17 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379606237.35.0.010008067541.issue19052@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are making perfect sense.  My point in referencing that issue was that you are not crazy, we do indeed not handle continue correctly ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 18:01:31 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 16:01:31 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379606491.99.0.972015061414.issue19052@psf.upfronthosting.co.za>


Joseph Warren added the comment:

Cheers, would you suggest I submit a patch then?

Also what version of python should I do this against? I've been working with 2.7, but the issue still exists in 3.* and I can conveniently work against 3.2.3-7, and less conveniently work against other versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 18:10:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Sep 2013 16:10:36 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379607036.98.0.943651981377.issue19052@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think we can fix this in maintenance releases without breaking anyone's code, so a patch against both 2.7 and 3.3 would be ideal.  A patch against 3.2 will probably apply cleanly to 3.3, so that should be fine as well.

Thanks for working on this, and could you please submit a contributor agreement at your earliest convenience?  It takes a few days for that to get processed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Thu Sep 19 18:24:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 16:24:40 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379607880.51.0.40446234626.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Isn't sys.getsizeof() a low-level debugging tool?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:06:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 17:06:06 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379607880.51.0.40446234626.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379610359.2511.0.camel@fsol>


Antoine Pitrou added the comment:

> Isn't sys.getsizeof() a low-level debugging tool?

What would it help debug exactly? :-)
I would hope it gives remotely useful information about the passed
object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:17:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 17:17:52 +0000
Subject: [issue19053] read1() from zipfile returns empty data
In-Reply-To: <1379604556.3.0.19871630565.issue19053@psf.upfronthosting.co.za>
Message-ID: <1379611072.92.0.974630538425.issue19053@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file31819/zipfile_read1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19053>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:18:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 17:18:42 +0000
Subject: [issue19053] read1() from zipfile returns empty data
In-Reply-To: <1379604556.3.0.19871630565.issue19053@psf.upfronthosting.co.za>
Message-ID: <1379611122.03.0.915470010423.issue19053@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19053>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:26:26 2013
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 19 Sep 2013 17:26:26 +0000
Subject: [issue19054] Descriptors howto
Message-ID: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>


New submission from Marco Buttu:

I think in the descriptor howto, at this point:

>>> class MyClass(object):
    x = RevealAccess(10, 'var "x"')
    y = 5

or the prompt should not have been, or there is a wrong indentation.
Furthermore, in Python 3:

http://docs.python.org/3/howto/descriptor.html

we can remove the explicit derivation from `object`

----------
assignee: docs at python
components: Documentation
messages: 198096
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Descriptors howto
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:33:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 17:33:00 +0000
Subject: [issue19049] itertools.tee isn't 64-bit compliant
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379611980.47.0.170159797009.issue19049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think we need Py_ssize_t for integers from 0 to 57.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:42:55 2013
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 19 Sep 2013 17:42:55 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379612575.51.0.0810467740533.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file31820/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:43:14 2013
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 19 Sep 2013 17:43:14 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379612594.58.0.960011528233.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Added file: http://bugs.python.org/file31821/py2howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:47:50 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Sep 2013 17:47:50 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379612870.78.0.983941461782.issue19048@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

getsizeof() is interesting only if it gives sensible results when used correctly, especially if you want to sum these values and get a global memory usage.

One usage is to traverse objects through gc.get_referents(); in this case the definition above is correct.

Now, are you suggesting to traverse objects differently? With dir(), or __dict__?

(btw, this discussion explains why pypy still does not implement getsizeof())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 19:57:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 17:57:21 +0000
Subject: [issue19049] itertools.tee isn't 64-bit compliant
In-Reply-To: <1379611980.47.0.170159797009.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379613438.2511.3.camel@fsol>


Antoine Pitrou added the comment:

> I don't think we need Py_ssize_t for integers from 0 to 57.

IMO it's better to use Py_ssize_t there, since it can get combined with
other Py_ssize_t values. Avoiding spurious conversions eliminates a
common source of errors. We don't gain anything by keeping it as an int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:05:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 18:05:19 +0000
Subject: [issue19049] itertools.tee isn't 64-bit compliant
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379613919.08.0.369856381851.issue19049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We gain stability.

I doubt we should change this. However in any case you forgot about tee_reduce().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:05:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:05:25 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379612870.78.0.983941461782.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379613920.2511.10.camel@fsol>


Antoine Pitrou added the comment:

> getsizeof() is interesting only if it gives sensible results when used
> correctly, especially if you want to sum these values and get a global
> memory usage.

"Getting a global memory usage" isn't a correct use of getsizeof(),
though, because it totally ignores the memory allocation overhead (not
to mention fragmentation, or any memory areas that may have been
allocated without being accounted for by __sizeof__).

If you want global Python memory usage, use sys._debugmallocstats(), not
sys.getsizeof().

> One usage is to traverse objects through gc.get_referents(); in this
> case the definition above is correct.

What are the intended semantics? get_referents() can give you references
you didn't expect, such as type objects, module objects...

> Now, are you suggesting to traverse objects differently? With dir(),
> or __dict__?

sys.getsizeof() gives you the memory usage of a given Python object, it
doesn't guarantee that "traversing objects" will give you the right
answer for any question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:06:32 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 19 Sep 2013 18:06:32 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379613992.26.0.266953054997.issue19048@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

> The problem is that that definition isn't helpful.
> If we ever change itertools.tee to use non-PyObjects internally, s
> suddenly its sys.getsizeof() would have to return much larger numbers 
> despite visible behaviour not having changed at all (and despite the 
> memory overhead being actually lower).

I see no problem with that. If the internal representation changes, nobody should be surprised if sizeof changes.

> I would hope it gives remotely useful information about the passed object.

It certainly does: it reports the memory consumption of the object itself, 
not counting the memory of other objects.

I proposed a precise definition of what "an other object" is. If you don't like it,
please propose a different definition that still allows to automatically sum up the
memory of a graph of objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:07:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:07:35 +0000
Subject: [issue19049] itertools.tee isn't 64-bit compliant
In-Reply-To: <1379613919.08.0.369856381851.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379614053.2511.12.camel@fsol>


Antoine Pitrou added the comment:

> I doubt we should change this.

Currently itertools.tee() will break if more than 2**31 elements are
saved in the inner structures. I certainly think it should be fixed,
rather than bite someone by surprise one day.

> However in any case you forgot about tee_reduce().

Will take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:09:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:09:24 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379613992.26.0.266953054997.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379614162.2511.14.camel@fsol>


Antoine Pitrou added the comment:

> I see no problem with that. If the internal representation changes,
> nobody should be surprised if sizeof changes.

Who is "nobody"? Users aren't aware of internal representation changes.
It sounds like you want sys.getsizeof() to be a tool for language
implementors anyway.

> I proposed a precise definition of what "an other object" is. If you don't like it,
> please propose a different definition that still allows to automatically sum up the
> memory of a graph of objects.

What is the use case for "summing up the memory of a graph of objects?
How do you stop walking your graph if it spans the whole graph of Python
objects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:11:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 18:11:29 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379614289.55.0.124532206889.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Well. itertools._tee is one Python object and itertools._tee_dataobject is another Python object. sys.getsizeof() gives you the memory usage of this objects separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:15:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:15:57 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379614289.55.0.124532206889.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379614554.2511.20.camel@fsol>


Antoine Pitrou added the comment:

> Well. itertools._tee is one Python object and
> itertools._tee_dataobject is another Python object. sys.getsizeof()
> gives you the memory usage of this objects separately.

This is great... And how do I know that I need to use gc.get_referents()
to get those objects in case I'm measuring the memory consumption of a
teeobject (rather than, say, trusting __dict__, or simply trusting the
getsizeof() output at face value)?

If sys.getsizeof() is only useful for people who know *already* how an
object is implemented internally, then it's actually useless, because
those people can just as well do the calculation themselves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:17:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:17:46 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379614666.43.0.926228207973.issue19048@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is why using get_referents() is stupid in the general case:

>>> class C: pass
... 
>>> c = C()
>>> gc.get_referents(c)
[<class '__main__.C'>]

With your method, measuring c's memory consumption also includes the memory consumption of its type object.
(and of course this is only a trivial example... one can only imagine what kind of mess it is with a non-trivial object)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:19:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:19:38 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379614778.8.0.59508071795.issue19048@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(By the way, OrderedDict.__sizeof__ already breaks the rule you are trying to impose)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:24:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:24:07 +0000
Subject: [issue19049] itertools.tee uses int for indices
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379615047.27.0.0504933825948.issue19049@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, my bad, it seems I misunderstood the tee() implementation. So apparenly even index cannot get past 57. It's more of a consistency patch then, and I agree it isn't very important.

----------
priority: normal -> low
stage: needs patch -> patch review
title: itertools.tee isn't 64-bit compliant -> itertools.tee uses int for indices
type: behavior -> enhancement
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:32:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 18:32:32 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379615552.89.0.484022817813.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> How do you stop walking your graph if it spans the whole graph of Python objects?

We can stop at specific types of objects (for example types and modules).

> If sys.getsizeof() is only useful for people who know *already* how an
object is implemented internally, then it's actually useless, because
those people can just as well do the calculation themselves.

It's why sys.getsizeof() is a low-level tool. We need high-level tool in the stdlib. Even imperfect recursive counting will be better than confusing for novices sys.getsizeof().

> (By the way, OrderedDict.__sizeof__ already breaks the rule you are trying to impose)

Yes, I know, and I think it is wrong.

Here is improved version of gettotalsizeof():

def gettotalsizeof(*args, exclude_types=(type, type(sys))):
    seen = {}
    stack = []
    for obj in args:
        if id(obj) not in seen:
            seen[id(obj)] = obj
            stack.append(obj)
    sum = 0
    while stack:
        obj = stack.pop()
        sum += sys.getsizeof(obj)
        for obj in gc.get_referents(obj):
            if id(obj) not in seen and not isinstance(obj, exclude_types):
                seen[id(obj)] = obj
                stack.append(obj)
    return sum


>>> gettotalsizeof(sys)
206575
>>> gettotalsizeof(gc)
2341
>>> gettotalsizeof(sys.getsizeof)
60
>>> gettotalsizeof(gettotalsizeof)
60854
>>> class C: pass
... 
>>> gettotalsizeof(C)
805
>>> gettotalsizeof(C())
28

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:39:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:39:55 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379615552.89.0.484022817813.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379615993.2511.25.camel@fsol>


Antoine Pitrou added the comment:

> It's why sys.getsizeof() is a low-level tool. We need high-level tool
> in the stdlib. Even imperfect recursive counting will be better than
> confusing for novices sys.getsizeof().

Ok, but I need to see a satisfying version of "gettotalsizeof" before
I'm convinced (see below).

> Here is improved version of gettotalsizeof():
> 
[...]
> >>> gettotalsizeof(gettotalsizeof)
> 60854

Why that big? Does it make sense?

What if say, a large object is "shared" between many small objects?
Should it count towards the memory size of any of those small objects?
What if that object is actually immortal (it is also a module global,
for example)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:41:42 2013
From: report at bugs.python.org (Augie Fackler)
Date: Thu, 19 Sep 2013 18:41:42 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1379616102.9.0.877399727454.issue3982@psf.upfronthosting.co.za>


Augie Fackler added the comment:

I'd like to put a nudge towards supporting the __mod__ interface on bytes - for Mercurial this is the single biggest impediment to even getting our testrunner working, much less starting the porting process.

----------
nosy: +durin42

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:44:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 18:44:07 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379616247.92.0.34627910106.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Optionally we can also not count objects which are referenced from outside of a graph of objects (this isn't so easy implement in Python). I.e. gettotalsizeof([1, 'abc', math.sqrt(22)], inner=True) will count only bare list and a square of 22, because 1 and 'abc' are interned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 20:45:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 18:45:56 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379616247.92.0.34627910106.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379616354.2511.27.camel@fsol>


Antoine Pitrou added the comment:

> Optionally we can also not count objects which are referenced from
> outside of a graph of objects (this isn't so easy implement in
> Python). I.e. gettotalsizeof([1, 'abc', math.sqrt(22)], inner=True)
> will count only bare list and a square of 22, because 1 and 'abc' are
> interned.

That's only part of the equation. What if I have an object which
references, for example, a logging.Logger? Loggers are actually eternal
(they live in a global dictionary somewhere in the logging module), but
gettotalsizeof() will still count it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Thu Sep 19 22:40:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Sep 2013 20:40:35 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1379623235.63.0.220823789222.issue15751@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I wanted to set issue10915 as duplicate but there is actually a tentative patch there. Unfortunately the discussions are now split apart...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Thu Sep 19 22:44:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Sep 2013 20:44:19 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1379623459.73.0.418017047631.issue15751@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Thu Sep 19 22:44:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Sep 2013 20:44:38 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1379623477.99.0.817343692457.issue10915@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:28:43 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Thu, 19 Sep 2013 22:28:43 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
Message-ID: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>


New submission from Jason Stumpf:

>>> re.match('(a|ab)*',('aba')).group(0)
'a'

According to the documentation, the * should match as many repetitions as possible.  2 are possible, it matches 1.

Reversing the order of the operands of | changes the behaviour.

>>> re.match('(ab|a)*',('aba')).group(0)
'aba'

----------
messages: 198116
nosy: Jason.Stumpf
priority: normal
severity: normal
status: open
title: Regular expressions: * does not match as many repetitions as possible.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:29:18 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Thu, 19 Sep 2013 22:29:18 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379629758.04.0.775805293398.issue19055@psf.upfronthosting.co.za>


Changes by Jason Stumpf <jstumpf at google.com>:


----------
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:34:34 2013
From: report at bugs.python.org (David Benbennick)
Date: Thu, 19 Sep 2013 22:34:34 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379630074.94.0.315737172365.issue19055@psf.upfronthosting.co.za>


Changes by David Benbennick <dbenbenn at gmail.com>:


----------
nosy: +dbenbenn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:36:12 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 22:36:12 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379630172.36.0.454430642585.issue19052@psf.upfronthosting.co.za>


Joseph Warren added the comment:

Have downloaded an up to date version of Python to develop with, and found that this issue had been fixed in it. This seems to have been done in changeset:   65028:7add45bcc9c6

changeset:   65028:7add45bcc9c6
user:        Senthil Kumaran <orsenthil at gmail.com>
date:        Thu Sep 30 06:09:18 2010 +0000
summary:     Issue1491 - BaseHTTPServer incorrectly implements response code 100

This change does not seem to appear in 2.7 , and could be converted to work with this, however failing this, this issue can probably be closed.

I appologise for not spotting this earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:37:20 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 22:37:20 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379630240.37.0.397213816526.issue19052@psf.upfronthosting.co.za>


Joseph Warren added the comment:

Sorry, this change does appear in 2.7.* I was looking at the wrong mercurial Tag

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:37:39 2013
From: report at bugs.python.org (Joseph Warren)
Date: Thu, 19 Sep 2013 22:37:39 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379630259.73.0.316233126912.issue19052@psf.upfronthosting.co.za>


Changes by Joseph Warren <hungryjoe.warren at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:39:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 22:39:56 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379630396.49.0.638947890125.issue19055@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:40:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Sep 2013 22:40:19 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379630419.61.0.801391237625.issue19055@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 00:52:06 2013
From: report at bugs.python.org (janzert)
Date: Thu, 19 Sep 2013 22:52:06 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379631126.58.0.773605364278.issue19055@psf.upfronthosting.co.za>


janzert added the comment:

The documentation on the | operator in the re module pretty explicitly covers this. http://docs.python.org/2/library/re.html

"A|B, where A and B can be arbitrary REs, creates a regular expression that will match either A or B. An arbitrary number of REs can be separated by the '|' in this way. This can be used inside groups (see below) as well. As the target string is scanned, REs separated by '|' are tried from left to right. When one pattern completely matches, that branch is accepted. This means that once A matches, B will not be tested further, even if it would produce a longer overall match. In other words, the '|' operator is never greedy."

----------
nosy: +janzert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 01:18:07 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Thu, 19 Sep 2013 23:18:07 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379632687.55.0.972976703326.issue19055@psf.upfronthosting.co.za>


Jason Stumpf added the comment:

Even with the documentation to |, the documentation to * is wrong.

>>> re.match('(a|ab)*c',('abac')).group(0)
'abac'

>From the doc: In general, if a string p matches A and another string q matches B, the string pq will match AB.

Since '(a|ab)*c' matches 'abac', and 'c' matches 'c', that means '(a|ab)*' matches 'aba'.  It does so with 2 repetitions.  Thus, in the example from my initial post, it was not matching with as many repetitions as possible.

I think what you mean is that * attempts to match again after each match of the preceding regular expression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 01:29:02 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Thu, 19 Sep 2013 23:29:02 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379633342.6.0.758461970154.issue19055@psf.upfronthosting.co.za>


Jason Stumpf added the comment:

Sorry, that implication was backwards.  I don't think I can prove from just the documentation that '(a|ab)*' can match 'aba' in certain contexts.

If the docs said: "* attempts to match again after each match of the preceding regular expression." I think it would describe the observed behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 02:00:51 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 20 Sep 2013 00:00:51 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379635251.7.0.53924115397.issue19055@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

The behaviour is correct.

Here's a summary of what's happening:-


First iteration of the repeated group:

    Try the first branch. Can match "a".

Second iteration of the repeated group:

    Try the first branch. Can't match "a".
    Try the second branch. Can't match "ab".

Continue with the remainder of the pattern.

Can't match "c", therefore backtrack to the first iteration of the repeated group:

    Try the second branch. Can match "ab".

Second iteration of the repeated group:

    Try the first branch. Can match "a".

Third iteration of the repeated group:

    Try the first branch. Can't match "a".
    Try the second branch. Can't match "ab".

Continue with the remainder of the pattern.

Can match "c".

Reached the end of the pattern. It has matched "abac".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 02:02:27 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Fri, 20 Sep 2013 00:02:27 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379635347.54.0.415159123379.issue19055@psf.upfronthosting.co.za>


Jason Stumpf added the comment:

I understand what's happening, but that is not what the documentation describes.  If the behaviour is correct, the documentation is incorrect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 02:29:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 00:29:42 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379636982.2.0.349469274303.issue19048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is advanced function which counts only objects on which there are no external references.

>>> import itertools
>>> a, b = itertools.tee(range(10000))
>>> max(zip(a, range(100)))
(99, 99)
>>> sys.getsizeof(a)
32
>>> gettotalinnersizeof(a)
32
>>> gettotalinnersizeof(b)
292
>>> gettotalinnersizeof(a, b)
608

Total size of a and b is larger than a sum of sizes of a and b. It's because it includes size of one shared between a and teedataobject and one shared range iterator.

----------
Added file: http://bugs.python.org/file31822/gettotalsizeof.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Fri Sep 20 02:39:04 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Sep 2013 00:39:04 +0000
Subject: [issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed
In-Reply-To: <1379574179.05.0.180767783928.issue19045@psf.upfronthosting.co.za>
Message-ID: <1379637544.6.0.912340097417.issue19045@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19045>
_______________________________________

From report at bugs.python.org  Fri Sep 20 02:51:04 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Sep 2013 00:51:04 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379638264.7.0.604679981134.issue19054@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +rhettinger
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Fri Sep 20 03:21:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 01:21:58 +0000
Subject: [issue19052] Python's CGIHTTPServer does not handle Expect:
 100-continue gracefully which results in some Post requests
 being handled slowly.
In-Reply-To: <1379604416.32.0.462048261907.issue19052@psf.upfronthosting.co.za>
Message-ID: <1379640118.16.0.925850531083.issue19052@psf.upfronthosting.co.za>


R. David Murray added the comment:

No need to apologize for missing the issue.  I missed it too, and I was looking for it because I thought I remembered something...but only found the one I referenced and assumed that that was what I was remembering.

----------
stage:  -> committed/rejected
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19052>
_______________________________________

From report at bugs.python.org  Fri Sep 20 03:36:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 01:36:38 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379640998.4.0.853923590419.issue19055@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documentation is correct and unambiguous.  Regular expressions just aren't very intuitive.

The documentation says "Causes the resulting RE to match 0 or more repetitions of the preceding RE, as many repetitions as are possible."  "as many repetitions of the preceding RE" means that:

  (a|ab)*

is equivalent to

  (a|ab)(a|ab)(a|ab)...

where "..." represents "add copies of the RE until it doesn't match".

Then you have to look at the documentation of '|' to see what it matches, and that documentation (already quoted) explains why the expanded pattern only matches 'a' in 'aba'.

Perhaps it would be clearer if it read "Causes the RE to be evaluated as if there were zero or more repetitions of the preceding RE, as many repetitions as produce matches"?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 06:42:15 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Sep 2013 04:42:15 +0000
Subject: [issue18990] Remove unnecessary API inconsistency from
 ElementTree.XMLPullParser.close()
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379652135.6.0.722124778505.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Inviting some more people to get this patch reviewed in a timely fashion. Given that it's a cleanup of a newly introduced API, it must go in before the first beta release of 3.4.

The even wider cleanup would be to make XMLPullParser inherit from XMLParser and simply drop most of its code (as done in lxml.etree, see ticket #19010), but this patch is all that is needed to keep that path open.

----------
nosy: +ncoghlan, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 20 07:27:31 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Sep 2013 05:27:31 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379654851.41.0.181178514964.issue18990@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I clarified the issue title to actually explain the concern and the proposed fix (i.e. close() on XMLPullParser doesn't currently return the root, which is inconsistent with the XMLParser API).

This sounds like a reasonable change to me, but the docs also need to be updated.

----------
title: Remove unnecessary API inconsistency from ElementTree.XMLPullParser.close() -> Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 20 07:59:23 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Sep 2013 05:59:23 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379656763.25.0.316968836882.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I'm not entirely happy about the docs anyway. Most people just want to loop over iterparse() and be done (use case being to save memory). The new parser class is a rather special and more complex thing that we shouldn't let innocent users run into that easily. But that's a different ticket, I guess, and in no way time critical.

I can't see a reference to "parser.root" in the ElementTree doc page, BTW, so maybe there's just nothing to do there?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 20 08:04:27 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 20 Sep 2013 06:04:27 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379657067.24.0.631489508766.issue19048@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Antoine: in (my experience of) memory analysis, the size of a single object is mostly irrelevant. If you need to know how much memory something consumes, you typically want to know the memory of a set of objects. So this is the case that really must be supported.

For that, users will have to use libraries that know how to count memory. It's not asked to much that the authors of such libraries know about internals of Python (such as the existence of sys.getsizeof, or gc.get_referents). The question is: can such a library reasonably implemented? For that, it is important that getsizeof behaves uniformly across objects.

If you really don't like the proposed uniformity, please propose a different rule. However, don't give deviations in other places (OrderedDict) as a reason to break the rule here as well. Instead, if OrderedDict.__getsizeof__ is broken, it needs to be fixed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Fri Sep 20 08:59:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Sep 2013 06:59:47 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1379656763.25.0.316968836882.issue18990@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cW5eUhGcM8avxk1G=T_O3pNt-MasgY0qaAkCWgzKgYtQ@mail.gmail.com>


Nick Coghlan added the comment:

It's the docs for XMLPullParser.close that need to be updated.

On 20 September 2013 15:59, Stefan Behnel <report at bugs.python.org> wrote:
>
> Stefan Behnel added the comment:
>
> I'm not entirely happy about the docs anyway. Most people just want to loop over iterparse() and be done (use case being to save memory). The new parser class is a rather special and more complex thing that we shouldn't let innocent users run into that easily. But that's a different ticket, I guess, and in no way time critical.
>
> I can't see a reference to "parser.root" in the ElementTree doc page, BTW, so maybe there's just nothing to do there?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18990>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 20 09:08:53 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Sep 2013 07:08:53 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379660933.54.0.0641409492217.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Ah, right - I forgot that it currently only implements a part of the parser API in ElementTree. Adding "Returns the toplevel document element." behind the current sentence would do, I guess. That will need updating once the XMLPullParser implements support for parser targets, though. Also, the description could just be dropped if XMLPullParser inherited from XMLParser (ticket #19010), because it's just (or should just be) a redundant repitition. All that's really new is the read_events() method and the constructor's arguments. Keeping the rest out would simplify both the interface and the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 20 10:31:26 2013
From: report at bugs.python.org (Balazs)
Date: Fri, 20 Sep 2013 08:31:26 +0000
Subject: [issue19044] getaddrinfo raises near-useless exception
In-Reply-To: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>
Message-ID: <1379665886.41.0.499085792902.issue19044@psf.upfronthosting.co.za>


Balazs added the comment:

Hi, this is the platform:

Linux cloudbackupbr 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x6db033ec6858b391e114e252b3354ddbf5a9f7be, stripped

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19044>
_______________________________________

From report at bugs.python.org  Fri Sep 20 11:01:11 2013
From: report at bugs.python.org (=?utf-8?q?Beno=C3=AEt_D_Vages?=)
Date: Fri, 20 Sep 2013 09:01:11 +0000
Subject: [issue11632] difflib.unified_diff loses context
In-Reply-To: <1300788570.13.0.524020554804.issue11632@psf.upfronthosting.co.za>
Message-ID: <1379667671.29.0.786701050745.issue11632@psf.upfronthosting.co.za>


Beno?t D Vages added the comment:

An other exemple if necessary (python 2.6 / 2.7)
Got same behavior than mal using his script and my files.

Seems to occur when the chunk of lines between 2 differences is repeated many times in the file

----------
nosy: +folder4ben
Added file: http://bugs.python.org/file31823/450.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11632>
_______________________________________

From report at bugs.python.org  Fri Sep 20 11:06:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 09:06:32 +0000
Subject: [issue19049] itertools.tee uses int for indices
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379667992.73.0.202278835906.issue19049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are disadvantages in the changing int to Py_ssize_t. Converting Py_ssize_t  to/from Python int is a little harder than converting C int or long. This change (as any other change) has a risk of introduce new bugs (as you can see on example of your patch).

I suggest just add (yet one) explicit comment.

    int index; /* 0 <= index <= LINKCELLS */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Fri Sep 20 11:28:48 2013
From: report at bugs.python.org (Thierry Seunevel)
Date: Fri, 20 Sep 2013 09:28:48 +0000
Subject: [issue19056] Windows 7,
 script exec not working without explicit cal of python.exe
Message-ID: <1379669328.14.0.507303810717.issue19056@psf.upfronthosting.co.za>


New submission from Thierry Seunevel:

Executing a script from the command prompt works if Python.exe called explicitly, doesn't work if script name only.
Example :
python.exe script.py is ok
script.py gives the following :
Traceback (most recent call last):
  File "D:\soft\python\lib\site.py", line 548, in <module>
    main()
  File "D:\soft\python\lib\site.py", line 530, in main
    known_paths = addusersitepackages(known_paths)
  File "D:\soft\python\lib\site.py", line 266, in addusersitepackages
    user_site = getusersitepackages()
  File "D:\soft\python\lib\site.py", line 241, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "D:\soft\python\lib\site.py", line 231, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "D:\soft\python\lib\sysconfig.py", line 516, in get_config_var
    return get_config_vars().get(name)
  File "D:\soft\python\lib\sysconfig.py", line 449, in get_config_vars
    import re
  File "D:\soft\python\lib\re.py", line 105, in <module>
    import sre_compile
  File "D:\soft\python\lib\sre_compile.py", line 14, in <module>
    import sre_parse
  File "D:\soft\python\lib\sre_parse.py", line 17, in <module>
    from sre_constants import *
  File "D:\soft\python\lib\sre_constants.py", line 18, in <module>
    from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT
Association of py extension to the python.exe is ok, Path contains the path for python directory (and also to \lib) and is the first dir in path.
Why is there a difference between the 2 invocations as they are calling the same exe?

----------
components: Windows
messages: 198136
nosy: tsunwell
priority: normal
severity: normal
status: open
title: Windows 7, script exec not working without explicit cal of python.exe
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19056>
_______________________________________

From report at bugs.python.org  Fri Sep 20 11:34:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 09:34:16 +0000
Subject: [issue19049] itertools.tee uses int for indices
In-Reply-To: <1379667992.73.0.202278835906.issue19049@psf.upfronthosting.co.za>
Message-ID: <440674449.6983871.1379669649830.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I suggest just add (yet one) explicit comment.
> 
>     int index; /* 0 <= index <= LINKCELLS */

Ok, I think a comment is good enough here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Fri Sep 20 11:41:33 2013
From: report at bugs.python.org (Borut Podlipnik)
Date: Fri, 20 Sep 2013 09:41:33 +0000
Subject: [issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed
In-Reply-To: <1379574179.05.0.180767783928.issue19045@psf.upfronthosting.co.za>
Message-ID: <1379670093.65.0.86540075747.issue19045@psf.upfronthosting.co.za>


Borut Podlipnik added the comment:

Using c compiler instead of c++ compiler, solved the problem:
setenv CC cc 
setenv CXX cc 
setenv LD_LIBRARY_PATH "/opt/solarisstudio12.3/lib:/usr/lib"

# ./configure --without-gcc --with-cxx-main=CC --prefix=/opt/python
# make
# make test

However, make test failed:
?.
352 tests OK.
3 tests failed:
    test_ctypes test_posix test_uuid
1 test altered the execution environment:
    test_distutils
36 tests skipped:
    test_aepack test_al test_applesingle test_bsddb185 test_bsddb3
    test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses
    test_epoll test_gdb test_gl test_imgfile test_kqueue
    test_linuxaudiodev test_macos test_macostools test_msilib
    test_ossaudiodev test_scriptpackages test_smtpnet
    test_socketserver test_startfile test_sunaudiodev test_timeout
    test_tk test_ttk_guionly test_urllib2net test_urllibnet
    test_winreg test_winsound test_zipfile64
4 skips unexpected on sunos5:
    test_gdb test_sunaudiodev test_tk test_ttk_guionly
*** Error code 1
make: Fatal error: Command failed for target `test'
# 

# ./python Lib/test/regrtest.py -v test_uuid
== CPython 2.7.5 (default, Sep 19 2013, 12:00:58) [C]
==   Solaris-2.11-i86pc-i386-32bit-ELF little-endian
==   /home/borut/admin/python/Python-2.7.5/build/test_python_14443
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_uuid
testIssue8621 (test.test_uuid.TestUUID) ... ok
test_UUID (test.test_uuid.TestUUID) ... ok
test_exceptions (test.test_uuid.TestUUID) ... ok
test_getnode (test.test_uuid.TestUUID) ... ok
test_ifconfig_getnode (test.test_uuid.TestUUID) ... ok
test_ipconfig_getnode (test.test_uuid.TestUUID) ... ok
test_netbios_getnode (test.test_uuid.TestUUID) ... ok
test_random_getnode (test.test_uuid.TestUUID) ... ok
test_unixdll_getnode (test.test_uuid.TestUUID) ... ok
test_uuid1 (test.test_uuid.TestUUID) ... ok
test_uuid3 (test.test_uuid.TestUUID) ... ok
test_uuid4 (test.test_uuid.TestUUID) ... FAIL
test_uuid5 (test.test_uuid.TestUUID) ... ok
test_windll_getnode (test.test_uuid.TestUUID) ... ok

======================================================================
FAIL: test_uuid4 (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_uuid.py", line 422, in test_uuid4
    equal(u.variant, uuid.RFC_4122)
AssertionError: 'reserved for future definition' != 'specified in RFC 4122'

----------------------------------------------------------------------
Ran 14 tests in 0.166s

FAILED (failures=1)
test test_uuid failed -- Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_uuid.py", line 422, in test_uuid4
    equal(u.variant, uuid.RFC_4122)
AssertionError: 'reserved for future definition' != 'specified in RFC 4122'

1 test failed:
    test_uuid
# 

# ./python Lib/test/regrtest.py -v test_ctypes
== CPython 2.7.5 (default, Sep 19 2013, 12:00:58) [C]
==   Solaris-2.11-i86pc-i386-32bit-ELF little-endian
==   /home/borut/admin/python/Python-2.7.5/build/test_python_14454
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_ctypes
test_incomplete_example (ctypes.test.test_incomplete.MyTestCase) ... ok
test_native (ctypes.test.test_unaligned_structures.TestStructures) ... ok
test_swapped (ctypes.test.test_unaligned_structures.TestStructures) ... ok


======================================================================
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/ctypes/test/test_bitfields.py", line 40, in test_ints
    self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name)))
AssertionError: Tuples differ: ('A', 1, -1) != ('A', 1, 1)

First differing element 2:
-1
1

- ('A', 1, -1)
?          -

+ ('A', 1, 1)

======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/ctypes/test/test_bitfields.py", line 47, in test_shorts
    self.assertEqual((name, i, getattr(b, name)), (name, i, func(byref(b), name)))
AssertionError: Tuples differ: ('R', 32, -32) != ('R', 32, 32)

First differing element 2:
-32
32

- ('R', 32, -32)
?           -

+ ('R', 32, 32)

----------------------------------------------------------------------
Ran 345 tests in 0.341s

FAILED (failures=2, skipped=1)
test test_ctypes failed -- multiple errors occurred
1 test failed:
    test_ctypes
# 

# ./python Lib/test/regrtest.py -v test_posix
== CPython 2.7.5 (default, Sep 19 2013, 12:00:58) [C]
==   Solaris-2.11-i86pc-i386-32bit-ELF little-endian
==   /home/borut/admin/python/Python-2.7.5/build/test_python_14477
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_posix
testNoArgFunctions (test.test_posix.PosixTester) ... ok
test_access (test.test_posix.PosixTester) ... ok
test_chdir (test.test_posix.PosixTester) ... ok
test_chflags (test.test_posix.PosixTester) ... skipped 'test needs os.chflags()'
test_chown (test.test_posix.PosixTester) ... FAIL
test_confstr (test.test_posix.PosixTester) ... ok
test_dup (test.test_posix.PosixTester) ... ok
test_dup2 (test.test_posix.PosixTester) ... ok
test_fchown (test.test_posix.PosixTester) ... FAIL
test_fdopen (test.test_posix.PosixTester) ... ok
test_fstat (test.test_posix.PosixTester) ... ok
test_fstatvfs (test.test_posix.PosixTester) ... ok
test_ftruncate (test.test_posix.PosixTester) ... ok
test_getcwd_long_pathnames (test.test_posix.PosixTester) ... ok
test_getgroups (test.test_posix.PosixTester) ... ok
test_initgroups (test.test_posix.PosixTester) ... ok
test_lchflags_regular_file (test.test_posix.PosixTester) ... skipped 'test needs os.lchflags()'
test_lchflags_symlink (test.test_posix.PosixTester) ... skipped 'test needs os.lchflags()'
test_lchown (test.test_posix.PosixTester) ... FAIL
test_lsdir (test.test_posix.PosixTester) ... ok
test_osexlock (test.test_posix.PosixTester) ... ok
test_osshlock (test.test_posix.PosixTester) ... ok
test_pipe (test.test_posix.PosixTester) ... ok
test_stat (test.test_posix.PosixTester) ... ok
test_statvfs (test.test_posix.PosixTester) ... ok
test_strerror (test.test_posix.PosixTester) ... ok
test_tempnam (test.test_posix.PosixTester) ... ok
test_tmpfile (test.test_posix.PosixTester) ... ok
test_umask (test.test_posix.PosixTester) ... ok
test_utime (test.test_posix.PosixTester) ... ok
test_initgroups (test.test_posix.PosixGroupsTester) ... ok
test_setgroups (test.test_posix.PosixGroupsTester) ... ok

======================================================================
FAIL: test_chown (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 293, in test_chown
    getattr(posix, 'stat', None))
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 258, in _test_all_chown_common
    check_stat(big_value, big_value)
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 230, in check_stat
    self.assertEqual(stat.st_uid, uid)
AssertionError: 60001 != 2147483648L

======================================================================
FAIL: test_fchown (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 304, in test_fchown
    getattr(posix, 'fstat', None))
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 258, in _test_all_chown_common
    check_stat(big_value, big_value)
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 230, in check_stat
    self.assertEqual(stat.st_uid, uid)
AssertionError: 60001 != 2147483648L

======================================================================
FAIL: test_lchown (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 314, in test_lchown
    getattr(posix, 'lstat', None))
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 258, in _test_all_chown_common
    check_stat(big_value, big_value)
  File "/home/borut/admin/python/Python-2.7.5/Lib/test/test_posix.py", line 230, in check_stat
    self.assertEqual(stat.st_uid, uid)
AssertionError: 60001 != 2147483648L

----------------------------------------------------------------------
Ran 32 tests in 0.019s

FAILED (failures=3, skipped=3)
test test_posix failed -- multiple errors occurred
1 test failed:
    test_posix
#

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19045>
_______________________________________

From report at bugs.python.org  Fri Sep 20 12:48:10 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Fri, 20 Sep 2013 10:48:10 +0000
Subject: [issue11220] Sometimes library raises URLError when trying POST with
 httpS
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1379674090.55.0.422661551919.issue11220@psf.upfronthosting.co.za>


mrDoctorWho0 . added the comment:

Trying to use POST-request to https://vk.com and sometimes library raise an error.
  File "library/vkApi.py", line 31, in post
    response = self.Opener.open(request)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
    raise URLError(err)
URLError: <urlopen error _ssl.c:489: The handshake operation timed out>

----------
components: +Library (Lib) -None
nosy: +mrDoctorWho0..
title: https sslv3 error 14077417: illegal parameter -> Sometimes library raises URLError when trying POST with httpS
versions: +Python 2.7 -Python 2.6, Python 3.1
Added file: http://bugs.python.org/file31824/code.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Fri Sep 20 12:49:23 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Fri, 20 Sep 2013 10:49:23 +0000
Subject: [issue11220] Sometimes library raises URLError when trying POST with
 httpS
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1379674163.86.0.796495146532.issue11220@psf.upfronthosting.co.za>


mrDoctorWho0 . added the comment:

oops! wrong place!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Fri Sep 20 12:49:41 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Fri, 20 Sep 2013 10:49:41 +0000
Subject: [issue11220] Sometimes library raises URLError when trying POST with
 httpS
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1379674181.2.0.55189390741.issue11220@psf.upfronthosting.co.za>


Changes by mrDoctorWho0 . <mrdoctorwho at gmail.com>:


Removed file: http://bugs.python.org/file31824/code.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Fri Sep 20 12:55:37 2013
From: report at bugs.python.org (mrDoctorWho0 .)
Date: Fri, 20 Sep 2013 10:55:37 +0000
Subject: [issue19057] Sometimes urllib2 raises URLError when trying POST with
 httpS
Message-ID: <1379674537.84.0.951539433247.issue19057@psf.upfronthosting.co.za>


New submission from mrDoctorWho0 .:

Trying to use POST-request to https://vk.com and sometimes library raise an error.
  File "library/vkApi.py", line 31, in post
    response = self.Opener.open(request)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
    '_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
    return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
    raise URLError(err)
URLError: <urlopen error _ssl.c:489: The handshake operation timed out>

This exception appears randomly, connection is ok 100%. I tried it on different machines with python 2.7.4 and 2.7.3.

----------
components: Library (Lib)
files: code.py
messages: 198141
nosy: mrDoctorWho0..
priority: normal
severity: normal
status: open
title: Sometimes urllib2 raises URLError when trying POST with httpS
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31825/code.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19057>
_______________________________________

From report at bugs.python.org  Fri Sep 20 13:25:43 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 Sep 2013 11:25:43 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1379676343.74.0.217407284631.issue11220@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy:  -mrDoctorWho0..
title: Sometimes library raises URLError when trying POST with httpS -> https sslv3 error 14077417: illegal parameter
versions: +Python 2.6, Python 3.1 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Fri Sep 20 13:26:01 2013
From: report at bugs.python.org (Christopher Benson)
Date: Fri, 20 Sep 2013 11:26:01 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
 of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1379676361.43.0.409955791517.issue6792@psf.upfronthosting.co.za>


Changes by Christopher Benson <chris.benson.sr at gmail.com>:


----------
nosy: +ChrisBenson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6792>
_______________________________________

From report at bugs.python.org  Fri Sep 20 13:27:00 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 Sep 2013 11:27:00 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1379676420.29.0.255627221251.issue11220@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
Removed message: http://bugs.python.org/msg198139

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Fri Sep 20 13:27:02 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 Sep 2013 11:27:02 +0000
Subject: [issue11220] https sslv3 error 14077417: illegal parameter
In-Reply-To: <1297829742.65.0.922916250537.issue11220@psf.upfronthosting.co.za>
Message-ID: <1379676422.64.0.495531603918.issue11220@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
Removed message: http://bugs.python.org/msg198140

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11220>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:04:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 12:04:53 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379678693.08.0.49966425873.issue19009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

After adding read1() and peek() what stop us from inheriting HTTPResponse from BufferedIOBase?

I suggest split _read1_or_peek_chunked() by two parts. First part calculates n bounded by chunk_left (it can read the next chunk size and close a connection if needed). Perhaps it can be reused in _readall_chunked() and _readinto_chunked(() too. Second part which is  controlled by boolean parameter should be moved out in read1() and peek().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:32:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 12:32:24 +0000
Subject: [issue19051] Unify buffered readers
In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za>
Message-ID: <1379680344.34.0.329213215859.issue19051@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If you want this, I think it should be somehow folded into existing classes (for example BufferedIOBase). Yet another implementation of readline() isn't really a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19051>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:32:44 2013
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Fri, 20 Sep 2013 12:32:44 +0000
Subject: [issue18756] os.urandom() fails under high load
In-Reply-To: <1376666498.06.0.618743202178.issue18756@psf.upfronthosting.co.za>
Message-ID: <1379680364.42.0.914606098399.issue18756@psf.upfronthosting.co.za>


Changes by Adam Biela?ski <abgans at gmail.com>:


----------
nosy: +Adam.Biela?ski

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18756>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:41:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 12:41:11 +0000
Subject: [issue18003] lzma module very slow with line-oriented reading.
In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za>
Message-ID: <1379680871.38.0.182646700486.issue18003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue19051. Even preliminary Python implementation noticeable speed up the reading of short lines.

$ ./python -m timeit -s "import lzma, io" "f=lzma.LZMAFile('words.xz', 'r')" "for line in f: pass"

Unpatched: 1.44 sec per loop
Patched: 1.06 sec per loop

With C implementation it should be as fast as with BufferedReader.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18003>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:43:40 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 20 Sep 2013 12:43:40 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379681020.58.0.715146435195.issue18990@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Hi Nick,

I disagree with this change. The way the APIs are currently defined, XMLParser and XMLPullParser are different animals. XMLParser can be considered to only have one "front" in the API - feed() and close(). You feed() until the document is done and then you close() and get the parsed tree. There's no other way to get the parsed tree (unless you use a custom builder, I guess).

On the other hand XMLPullParser has two clear "fronts" - an input front with feed() and close() and an output front with read_events(). For XMLPullParser, close() is just an input signal. The canonical way to get output from XMLPullParser is read_events(). close() has no better reason to return output than feed(). When we decided to change the method names (recall that Antoine's originals were completely different), we perhaps forgot this detail. Even though XMLPullParser's method is named close(), it's *not* like XMLParser's close(). If someone is using XMLPullParser for its close() he's likely using the class incorrectly.

Just as an example: consider that in a lot of use cases the programmer will want to discard parts of the tree that's parsed iteratively (similarly to the main use case of iterparse()), because the XML itself is too huge. It's a convenient streaming API, in other words. Now, if the reader discards parts of the tree (by deleting subtrees), then returning the root from close() becomes even more meaningless, because it's no longer the root and we have no idea what it actually is.

Finally, I will add that we can always err on the side of under-specifying. We plan to change the implementation of the class in the future, so we can always add to the API. Specifying that close() returns the root is something we can't back out of, but we can always add in a future release without hurting backwards compatibility, if we do reach the conclusion that it's better.

---

P.S. all of this makes me wonder if we should mark the API of XMLPullParser provisional for 3.4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:49:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 12:49:38 +0000
Subject: [issue18003] lzma module very slow with line-oriented reading.
In-Reply-To: <1379680871.38.0.182646700486.issue18003@psf.upfronthosting.co.za>
Message-ID: <57301288.7505845.1379681372265.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> With C implementation it should be as fast as with BufferedReader.

So why not simply use BufferedReader?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18003>
_______________________________________

From report at bugs.python.org  Fri Sep 20 14:55:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 12:55:52 +0000
Subject: [issue19057] Sometimes urllib2 raises URLError when trying POST with
 httpS
In-Reply-To: <1379674537.84.0.951539433247.issue19057@psf.upfronthosting.co.za>
Message-ID: <1379681752.82.0.219890829428.issue19057@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would guess that if you did a network trace you'd find out there really was a packet that did not arrive (a timeout).  Note that detecting this is complicated by the fact that ssl is involved.  (I don't know the details, but I remember someone saying that more than one packet may be involved in something that looks like a single event at the OpenSSL level.)

It is certainly *possible* that there is a bug at the OpenSSL or (less likely) the _ssl module level, but the first step in debugging it would be to get that network trace, I think...

As I said, though, I'm not an expert in this area, perhaps someone who is will have other suggestions.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19057>
_______________________________________

From report at bugs.python.org  Fri Sep 20 15:58:42 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 20 Sep 2013 13:58:42 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379685522.93.0.738369589167.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Ok, I have refactored this a bit.
A separate new function now takes care of the reading of chunk-header and tail.  This simplifies the other functions.

I'm not sure what you mean by inheriting from the buffered class.  Do we gain anything by doing that, would it change the code? or would it merely be for the benefit of ABC?

Note that the chunk protocol was wrong and I fixed the unittests:  The final chunk is a _valid_ zero length chunk, i.e. 0\r\n\r\n.  It contains two eol tokens like other chunks, one at the end of the length, the other at the end of the(null) payload.

----------
Added file: http://bugs.python.org/file31826/httpresponse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 16:36:55 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 20 Sep 2013 14:36:55 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379687815.82.0.0909790316555.issue19019@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Fri Sep 20 16:51:50 2013
From: report at bugs.python.org (Connor Osborn)
Date: Fri, 20 Sep 2013 14:51:50 +0000
Subject: [issue18764] The pdb print command prints repr instead of str in
 python3
In-Reply-To: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>
Message-ID: <1379688710.58.0.234769552796.issue18764@psf.upfronthosting.co.za>


Connor Osborn added the comment:

Should the pretty print behavior remain?

----------
nosy: +cdosborn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18764>
_______________________________________

From report at bugs.python.org  Fri Sep 20 17:28:08 2013
From: report at bugs.python.org (Josh Lee)
Date: Fri, 20 Sep 2013 15:28:08 +0000
Subject: [issue10976] json.loads() raises TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1379690888.89.0.682624090044.issue10976@psf.upfronthosting.co.za>


Changes by Josh Lee <jleedev at gmail.com>:


----------
nosy: +jleedev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10976>
_______________________________________

From report at bugs.python.org  Fri Sep 20 17:42:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 15:42:52 +0000
Subject: [issue18764] The pdb print command prints repr instead of str in
 python3
In-Reply-To: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>
Message-ID: <1379691772.55.0.120316279767.issue18764@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, that's a very good question.  So perhaps the print command should be renamed 'pprint'.

Anyone else have thoughts about the API?  Do we instead need to fix the print command, for backward compatibility reasons?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18764>
_______________________________________

From report at bugs.python.org  Fri Sep 20 19:00:41 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 20 Sep 2013 17:00:41 +0000
Subject: [issue19056] Windows 7,
 script exec not working without explicit cal of python.exe
In-Reply-To: <1379669328.14.0.507303810717.issue19056@psf.upfronthosting.co.za>
Message-ID: <1379696441.44.0.412028107695.issue19056@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Can you print out sys.executable and sys.path in both cases, and post the results here?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19056>
_______________________________________

From report at bugs.python.org  Fri Sep 20 19:06:27 2013
From: report at bugs.python.org (Jason Stumpf)
Date: Fri, 20 Sep 2013 17:06:27 +0000
Subject: [issue19055] Regular expressions: * does not match as many
 repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1379696787.24.0.188864266508.issue19055@psf.upfronthosting.co.za>


Jason Stumpf added the comment:

I like that clearer description.  "as produce matches" is more correct than "as possible".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19055>
_______________________________________

From report at bugs.python.org  Fri Sep 20 19:10:40 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Sep 2013 17:10:40 +0000
Subject: [issue19056] Windows 7,
 script exec not working without explicit cal of python.exe
In-Reply-To: <1379669328.14.0.507303810717.issue19056@psf.upfronthosting.co.za>
Message-ID: <1379697040.94.0.835794142663.issue19056@psf.upfronthosting.co.za>


Ned Deily added the comment:

You may have a mismatch with two different versions of Python 2.7 installed.  Issue18050 documents the basic problem: a change introduced in Python 2.7.4 causes problems if a pre-2.7.4 interpreter executable is launched with a 2.7.4 or later Python standard library.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19056>
_______________________________________

From report at bugs.python.org  Fri Sep 20 19:14:38 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Sep 2013 17:14:38 +0000
Subject: [issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed
In-Reply-To: <1379574179.05.0.180767783928.issue19045@psf.upfronthosting.co.za>
Message-ID: <1379697278.52.0.283116064992.issue19045@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19045>
_______________________________________

From report at bugs.python.org  Fri Sep 20 19:39:56 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 Sep 2013 17:39:56 +0000
Subject: [issue18907] urllib2.open FTP open times out at 20 secs despite
 timeout parameter
In-Reply-To: <1379178919.09.0.701878177992.issue18907@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3Hd_mfDyn-Te36f3DurJrponrOsh5br6LO2NE3zCOD-Q@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> So this may have been a DNS related issue, perhaps a load balancer referring the connection to a dead machine.  Yet, for some reason, the Windows command line FTP client can recover from this problem after 20 seconds? What are they doing right? Completely retrying the open?

Do you mean you're able to pass a timeout greater than 20 seconds to
the Windows command line FTP client?

In any case, there's nothing much we can do: if the TCP stack returns
the connection broken (timed out), we can't do much.
On Linux, you can increase the sysctls I mentioned in my previous
message, but that's it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18907>
_______________________________________

From report at bugs.python.org  Fri Sep 20 19:43:43 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 Sep 2013 17:43:43 +0000
Subject: [issue19044] getaddrinfo raises near-useless exception
In-Reply-To: <1379561932.98.0.549572888497.issue19044@psf.upfronthosting.co.za>
Message-ID: <1379699023.65.0.231916971703.issue19044@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Well, as Ned explained, that's a libc bug.
If getaddrinfo() fails with EAI_SYSTEM, errno should be set.

There's nothing more Python can do.
If the error is reproducible, you can run the failing code with strace, to see what's going on (and check if there's a more recent glib version which could fix this bug).

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19044>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:30:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Sep 2013 18:30:34 +0000
Subject: [issue18050] embedded interpreter or virtualenv fails with
 "ImportError: cannot import name MAXREPEAT"
In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za>
Message-ID: <3chNlY56YZzSfK@mail.python.org>


Roundup Robot added the comment:

New changeset 68a7d77a90c3 by Serhiy Storchaka in branch '3.3':
Issue #18050: Fixed an incompatibility of the re module with Python 3.3.0
http://hg.python.org/cpython/rev/68a7d77a90c3

New changeset f27af2243e2a by Serhiy Storchaka in branch '2.7':
Issue #18050: Fixed an incompatibility of the re module with Python 2.7.3
http://hg.python.org/cpython/rev/f27af2243e2a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18050>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:34:48 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Sep 2013 18:34:48 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1379702088.37.0.069071501411.issue1615@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: high -> normal
versions:  -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:39:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 18:39:02 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379702342.94.0.212751349636.issue19009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> A separate new function now takes care of the reading of chunk-header and tail.  This simplifies the other functions.

Good. It is even better than I expected.

> Do we gain anything by doing that, would it change the code? or would it merely be for the benefit of ABC?

Yes, it for the benefit of ABC. Some code tests isinstance(file, io.BufferedIOBase) and wraps stream in BufferedReader if it is false.

> Note that the chunk protocol was wrong and I fixed the unittests:  The final chunk is a _valid_ zero length chunk, i.e. 0\r\n\r\n.  It contains two eol tokens like other chunks, one at the end of the length, the other at the end of the(null) payload.

How new code processes invalid final chunk 0\r\n? We need test to check that there is no degradation.

Perhaps it relates to behavior change which I mention in the comment on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:41:31 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Sep 2013 18:41:31 +0000
Subject: [issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in
 descriptors
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1379702491.5.0.454292350593.issue1615@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Marking this for Python 3.4.  It isn't a bug in the descriptor protocol; rather, it is an implementation detail that is sometimes helpful but is mostly annoying.

----------
title: descriptor protocol bug -> PyObject_GenericGetAttr suppresses AttributeErrors in descriptors

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:42:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 18:42:48 +0000
Subject: [issue18050] embedded interpreter or virtualenv fails with
 "ImportError: cannot import name MAXREPEAT"
In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za>
Message-ID: <1379702568.61.0.499785495044.issue18050@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Samuel for your report and suggested solution. Thank you Ned for additional investigating.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18050>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:49:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 18:49:32 +0000
Subject: [issue18003] lzma module very slow with line-oriented reading.
In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za>
Message-ID: <1379702972.61.0.977618539162.issue18003@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> So why not simply use BufferedReader?

Because we want good performance LZMAFile and compatibility with older versions. And I guess that it will be even faster than wrapping in BufferedReader (due to the avoiding of double buffering).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18003>
_______________________________________

From report at bugs.python.org  Fri Sep 20 20:53:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 18:53:39 +0000
Subject: [issue18003] lzma module very slow with line-oriented reading.
In-Reply-To: <1379702972.61.0.977618539162.issue18003@psf.upfronthosting.co.za>
Message-ID: <1379703216.2501.3.camel@fsol>


Antoine Pitrou added the comment:

> > So why not simply use BufferedReader?
> 
> Because we want good performance LZMAFile and compatibility with older
> versions.

You're reading me wrong. I'm simply suggesting that users interested in
readline() performance wrap LZMAFile in a BufferedReader. The
documentation can mention it.

>  And I guess that it will be even faster than wrapping in
> BufferedReader (due to the avoiding of double buffering).

Let's wait for the numbers, then. The performance increase would have to
be quite large to justify such code duplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18003>
_______________________________________

From report at bugs.python.org  Fri Sep 20 21:24:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 19:24:34 +0000
Subject: [issue18575] Fixing tarfile._mode when using gzip via ":gz"
In-Reply-To: <1375000514.51.0.865237758651.issue18575@psf.upfronthosting.co.za>
Message-ID: <1379705074.35.0.268092908918.issue18575@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps we should rather change GzipFile.mode to be a string?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18575>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:08:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 20:08:34 +0000
Subject: [issue3015] tkinter with wantobjects=False has been broken for some
 time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <1379707714.7.0.373343946162.issue3015@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:12:31 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 20 Sep 2013 20:12:31 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379707951.37.0.757784745316.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Ok, I can change the base class inheritance and see if it changes things.

Note for the different interpretation of the final chunk:
Chunked encoding allows for adding headers after the final chunk.  This is what _read_and_discard_trailer() does, but discarding the trailing headers.  So, if support is ever added for reading those trailing headers, then we need make sure that we consume the last chunk correctly.
It is, of course, a matter of resilience, v.s. correctness, but the lesson of Internet Explorer should tell us to prefer correctness over flexibility, I think.  
We can, of course, change this back. if you think.  It is ieasier now, that the chunk consumer is in a single method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:16:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 20:16:41 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1379708201.54.0.475629183229.issue19050@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't get a crash under Linux. Perhaps this is a Windows-specific thing.

----------
components: +Interpreter Core, Windows -Library (Lib)
nosy: +brian.curtin, pitrou, tim.golden, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:19:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Sep 2013 20:19:29 +0000
Subject: [issue19049] itertools.tee uses int for indices
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <3chR9D25l5z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 900bf633b7f4 by Antoine Pitrou in branch 'default':
Add a comment making it explicit that itertools.tee() is already 64bit-safe (issue #19049)
http://hg.python.org/cpython/rev/900bf633b7f4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:19:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 20:19:45 +0000
Subject: [issue19049] itertools.tee uses int for indices
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379708385.84.0.631645449336.issue19049@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:21:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 20:21:01 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379707951.37.0.757784745316.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379708459.2501.4.camel@fsol>


Antoine Pitrou added the comment:

> Note for the different interpretation of the final chunk:
> Chunked encoding allows for adding headers after the final chunk.
> This is what _read_and_discard_trailer() does, but discarding the
> trailing headers.  So, if support is ever added for reading those
> trailing headers, then we need make sure that we consume the last
> chunk correctly.

I think what Serhiy is proposing is that we also succeed when the
server sends a truncated last chunk (and I agree with him).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:29:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Sep 2013 20:29:14 +0000
Subject: [issue3015] tkinter with wantobjects=False has been broken for some
 time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <3chRNT1fMmz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 08c45e18e7b2 by Serhiy Storchaka in branch '3.3':
Issue #3015: Fixed tkinter with wantobject=False.  Any Tcl command call
http://hg.python.org/cpython/rev/08c45e18e7b2

New changeset 65dd0de6b4a5 by Serhiy Storchaka in branch 'default':
Issue #3015: Fixed tkinter with wantobject=False.  Any Tcl command call
http://hg.python.org/cpython/rev/65dd0de6b4a5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:48:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 20:48:30 +0000
Subject: [issue3015] tkinter with wantobjects=False has been broken for some
 time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <1379710110.76.0.513980333208.issue3015@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which change the default value for the wantobjects parameter of _tkinter.create() and adds deprecation warnings.

----------
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:53:10 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 Sep 2013 20:53:10 +0000
Subject: [issue3015] tkinter with wantobjects=False has been broken for some
 time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <1379710390.1.0.641682606987.issue3015@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> Here is a patch

You again forgot to attach a patch :) .

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________

From report at bugs.python.org  Fri Sep 20 22:57:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Sep 2013 20:57:56 +0000
Subject: [issue3015] tkinter with wantobjects=False has been broken for some
 time
In-Reply-To: <1212187898.67.0.391803496997.issue3015@psf.upfronthosting.co.za>
Message-ID: <1379710676.51.0.789645353854.issue3015@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, thanks Arfrever.

----------
Added file: http://bugs.python.org/file31827/tkinter_deprecate_wantobjects.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3015>
_______________________________________

From report at bugs.python.org  Fri Sep 20 23:08:45 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 20 Sep 2013 21:08:45 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379711325.83.0.650786679604.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Ok, I can make it resilient.  I was just pointing out that resilience in the face of RFC violations can be a bad thing.  E.g. Internet explorer and how they allowed internet servers of the world to be lax in how they served their data.
No matter, I can allow truncated tails when reading chunks.  But I don't think we ought to make that a requirement or make special unit tests for that.  Either you read chunked encoding correctly or you don't.  There are so many different ways you can break protocol, that this particular one is really only a special case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 23:11:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 21:11:33 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379711325.83.0.650786679604.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379711490.2501.8.camel@fsol>


Antoine Pitrou added the comment:

> Ok, I can make it resilient.  I was just pointing out that resilience
> in the face of RFC violations can be a bad thing.  E.g. Internet
> explorer and how they allowed internet servers of the world to be lax
> in how they served their data.

I'm afraid the ship has sailed a long time ago on that. Poor HTTP
implementations are everywhere.

> No matter, I can allow truncated tails when reading chunks.  But I
> don't think we ought to make that a requirement or make special unit
> tests for that.

Well, the unit tests already exist, which is why I think we shouldn't
stop supporting that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 23:14:34 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Sep 2013 21:14:34 +0000
Subject: [issue19049] itertools.tee uses int for indices
In-Reply-To: <1379582468.56.0.0990535316271.issue19049@psf.upfronthosting.co.za>
Message-ID: <1379711674.32.0.530613263122.issue19049@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19049>
_______________________________________

From report at bugs.python.org  Fri Sep 20 23:17:18 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 20 Sep 2013 21:17:18 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379711838.43.0.849487692116.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Very well, let's support both then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 20 23:29:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Sep 2013 21:29:35 +0000
Subject: [issue19058] test_ioencoding_nonascii (test_sys) fails on Snow Leopard
Message-ID: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The test added in issue18818 fails on the new OS X buildbot:

======================================================================
FAIL: test_ioencoding_nonascii (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_sys.py", line 581, in test_ioencoding_nonascii
    self.assertEqual(out, os.fsencode(test.support.FS_NONASCII))
AssertionError: b'' != b'\xc3\xa6'

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4

----------
components: Tests
messages: 198174
nosy: haypo, pitrou, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_ioencoding_nonascii (test_sys) fails on Snow Leopard
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 21 00:16:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Sep 2013 22:16:09 +0000
Subject: [issue19058] test_ioencoding_nonascii (test_sys) fails on Snow Leopard
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1379715369.38.0.647710999268.issue19058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The test fails with ASCII locale encoding (ex: LANG= on Linux).

The test should not try to display a non-ASCII character, but should check the encoding (sys.stdout.encoding) instead. The test should ensure that sys.stdout.encoding is the same with the PYTHONIOENCODING unset (python started with -E option and the current environment) and with the variable set to an empty value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 21 00:29:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 22:29:58 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379716198.36.0.112173391801.issue19019@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've spun up a 10.6.8 OS X buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Sat Sep 21 00:32:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 22:32:24 +0000
Subject: [issue19059] test_posix failure on OS X snow leopord buildbot
Message-ID: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>


New submission from R. David Murray:

The new OS X buildbot is failing in test_posix:

======================================================================
FAIL: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_posix.py", line 734, in test_getgroups
    set(posix.getgroups() + [posix.getegid()]))
AssertionError: Items in the second set but not the first:
1

I can't reproduce this at the command line, so it probably has something to do with the fact that buildbot is running in daemon mode.

----------
components: Tests
keywords: buildbot
messages: 198177
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: test_posix failure on OS X snow leopord buildbot
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19059>
_______________________________________

From report at bugs.python.org  Sat Sep 21 00:35:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Sep 2013 22:35:26 +0000
Subject: [issue19059] test_posix failure on OS X snow leopord buildbot
In-Reply-To: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>
Message-ID: <1379716526.81.0.103530111116.issue19059@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19059>
_______________________________________

From report at bugs.python.org  Sat Sep 21 00:43:40 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Sep 2013 22:43:40 +0000
Subject: [issue19059] test_posix failure on OS X snow leopord buildbot
In-Reply-To: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>
Message-ID: <1379717020.05.0.727294016543.issue19059@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19059>
_______________________________________

From report at bugs.python.org  Sat Sep 21 01:04:33 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Sep 2013 23:04:33 +0000
Subject: [issue19019] Investigate using Apple clang for building OS X
 installers
In-Reply-To: <1379190673.82.0.353716409802.issue19019@psf.upfronthosting.co.za>
Message-ID: <1379718273.81.0.311486366124.issue19019@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19019>
_______________________________________

From report at bugs.python.org  Sat Sep 21 01:06:45 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Sep 2013 23:06:45 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379718405.37.0.994261190247.issue19048@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Sat Sep 21 01:56:12 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Sep 2013 23:56:12 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1379721372.01.0.67550785669.issue15475@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: serhiy.storchaka -> rhettinger
versions:  -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Sat Sep 21 02:12:26 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Sep 2013 00:12:26 +0000
Subject: [issue19048] itertools.tee doesn't have a __sizeof__ method
In-Reply-To: <1379582390.72.0.752302513682.issue19048@psf.upfronthosting.co.za>
Message-ID: <1379722346.42.0.89883008422.issue19048@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> getsizeof() is interesting only if it gives sensible results 
> when used correctly, especially if you want to sum these values
> and get a global memory usage.

If accounting for global memory usage is a goal, it needs to have a much more comprehensively thought out, implementation dependent approach.  There are many issues (memory fragmentation, key-sharing dictionaries, dummy objects, list over-allocation, the minsize dictionary that is part of the dict object in addition to its variable sized portion, non-python objects held by Python objects, the extra few bytes per object consumed by the freelisting scheme in Objects/obmalloc.c etc).

> The thing is, "Total size" is generally meaningless. 

I concur.  This is a pipe dream without a serious investment of time and without creating a new and unnecessary maintenance burden.

> (By the way, OrderedDict.__sizeof__ already breaks the
> rule you are trying to impose)

FWIW, the way OrderedDict computes sizeof is probably typical of how anyone is currently using sys.getsizeof().   If you change the premise of how it operates, you're probably going to break the code written by the very few people in the world who care about sys.getsizeof():

    def __sizeof__(self):
        sizeof = _sys.getsizeof
        n = len(self) + 1                       # number of links including root
        size = sizeof(self.__dict__)            # instance dictionary
        size += sizeof(self.__map) * 2          # internal dict and inherited dict
        size += sizeof(self.__hardroot) * n     # link objects
        size += sizeof(self.__root) * n         # proxy objects
        return size

I don't have any specific recommendation for itertools.tee other than that I think it doesn't really need a __sizeof__ method.  The typical uses of tee are a transient phenomena that temporarily use some memory and then disappear.  I'm not sure that any mid-stream sizeof checks reveal information of any worth.

Overall, this thread indicates that the entire concept of __sizeof__ has been poorly defined, unevenly implemented, and not really useful when aggregated.

For those who are interested in profiling and optimizing Python's memory usage, I think we would be much better off providing a memory allocator hook that can know about every memory allocation and how those allocations have been arranged (revealing the fragmentation of the unused memory in the spaces between).  Almost anything short of that will provide a grossly misleading picture of memory usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19048>
_______________________________________

From report at bugs.python.org  Sat Sep 21 02:14:36 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Sep 2013 00:14:36 +0000
Subject: [issue19059] test_posix failure on OS X snow leopord buildbot
In-Reply-To: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>
Message-ID: <1379722476.74.0.233113024973.issue19059@psf.upfronthosting.co.za>


Ned Deily added the comment:

>From irc, I believe RDM has changed the buildbot to run under a group that the user is a member of ("staff") and so I think this issue can be closed.  David?

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19059>
_______________________________________

From report at bugs.python.org  Sat Sep 21 03:41:53 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 01:41:53 +0000
Subject: [issue19059] test_posix failure on OS X snow leopord buildbot
In-Reply-To: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>
Message-ID: <1379727713.09.0.177451113708.issue19059@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, the problem turned out to be that the buildslave process was running under group 'daemon' (1), but the buildbot userid that it was running under was not part of that group.  So I changed the run group to 'staff', which buildbot is a member of, and the test passed.  So I consider this a bug in the buildbot setup rather than a bug in the test.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19059>
_______________________________________

From report at bugs.python.org  Sat Sep 21 03:42:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 01:42:11 +0000
Subject: [issue19059] test_posix failure on OS X snow leopord buildbot
In-Reply-To: <1379716344.12.0.400926462702.issue19059@psf.upfronthosting.co.za>
Message-ID: <1379727731.5.0.832508462094.issue19059@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: out of date -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19059>
_______________________________________

From report at bugs.python.org  Sat Sep 21 04:09:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 02:09:51 +0000
Subject: [issue19058] test_ioencoding_nonascii (test_sys) fails on Snow Leopard
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1379729391.61.0.759234019683.issue19058@psf.upfronthosting.co.za>


R. David Murray added the comment:

I set LC_CTYPE to en_US.utf-8 on the buildbot, which I think is the better setting for that buildbot, so the test doesn't fail there anymore.  However, the test should still be fixed (and maybe we should have a buildbot running with no language set at all).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 21 04:17:58 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 02:17:58 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379729878.76.0.176186587106.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31820/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 04:18:05 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 02:18:05 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379729885.39.0.881100657292.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31821/py2howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 04:24:31 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 02:24:31 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379730271.42.0.645343853618.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Maybe is better to underline the difference between classes and non-classes objects, instead of between objects and classes, because a class is an object, so it could be confusing). 
Raymond, what do you think about rewriting this sentence:

  `The details of invocation depend on whether obj is an object or a class.`

as:

  `The details of invocation depend on whether obj is a class or not.`

I upload two new patches (one for py2 and the other for py3)

----------
Added file: http://bugs.python.org/file31828/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 04:24:49 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 02:24:49 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379730289.79.0.765234227441.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Added file: http://bugs.python.org/file31829/py2howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 05:04:45 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 03:04:45 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379732685.44.0.465456596326.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31829/py2howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 05:04:59 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 03:04:59 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379732699.45.0.0584198147798.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Added file: http://bugs.python.org/file31830/py2howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 05:19:15 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 03:19:15 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379733555.36.0.367007138523.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31828/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 05:22:29 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 03:22:29 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379733749.13.0.462497142412.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I saw right now your decision about keeping object in the Python 3 doc:

http://bugs.python.org/issue17351#msg183870

So, now the py3 patch takes in account just the indentation of the `RevealAccess` example and the "class or not" suggestion.

----------
Added file: http://bugs.python.org/file31831/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 05:53:30 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 21 Sep 2013 03:53:30 +0000
Subject: [issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in
 descriptors
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1379735610.8.0.228571427737.issue1615@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Sat Sep 21 08:32:38 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Sep 2013 06:32:38 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379745158.24.0.0331324947157.issue19054@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 08:45:46 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Sep 2013 06:45:46 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379745946.1.0.514538629401.issue19054@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The indentation is not incorrect.  What you're seeing is normal for the interactive prompt.

Also, it is not incorrect to inherit from object in Python 3.
There is some value in keeping the document the same between versions.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 08:53:15 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 21 Sep 2013 06:53:15 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379746395.61.0.150613049246.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Just as an example: consider that in a lot of use cases the programmer will want to discard parts of the tree that's parsed iteratively (similarly to the main use case of iterparse()), because the XML itself is too huge. It's a convenient streaming API, in other words. Now, if the reader discards parts of the tree (by deleting subtrees), then returning the root from close() becomes even more meaningless, because it's no longer the root and we have no idea what it actually is.

Well, that's how the parser API works. It's the target's responsibility to make something (really, anything) of the parser's callbacks. Why change this for XMLPullParser if it already works that way for both XMLParser and iterparse() ? It's an inherent part of the design, and it really fits together just fine.

I don't like the idea of deliberately adding surprises to an otherwise simple API, especially if they clearly restrict future developments.


> Finally, I will add that we can always err on the side of under-specifying. We plan to change the implementation of the class in the future, so we can always add to the API. Specifying that close() returns the root is something we can't back out of, but we can always add in a future release without hurting backwards compatibility, if we do reach the conclusion that it's better.

Eli, if you had taken a look at my patch (and also a closer look at some of my earlier patches), you would have noticed that it not only makes close() behave as expected, but also removes the ".root" attribute from the parser. This removes a very unfortunate design decision in iterparse() that has bugged me several times in the past already, because it really gets in the way of both the implementation and the usage. Please keep that a misfeature only of iterparse() and do not repeat this mistake in this newly introduced API.

In fact, my decision to make XMLPullParser.close() consistent with XMLParser.close() was mostly motivated by this change, not the other way round.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:05:12 2013
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 21 Sep 2013 07:05:12 +0000
Subject: [issue1065986] Fix pydoc crashing on unicode strings
Message-ID: <1379747112.75.0.921190657952.issue1065986@psf.upfronthosting.co.za>


Akira Kitada added the comment:

Updated the previous patch to test unicode strings in __{version,date,author,credits}__ don't crash.

----------
Added file: http://bugs.python.org/file31832/issue1065986-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1065986>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:07:17 2013
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 21 Sep 2013 07:07:17 +0000
Subject: [issue13963] dev guide has no mention of mechanics of patch review
In-Reply-To: <1328631878.8.0.85188160352.issue13963@psf.upfronthosting.co.za>
Message-ID: <1379747237.23.0.911528452978.issue13963@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13963>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:09:43 2013
From: report at bugs.python.org (Tim Golden)
Date: Sat, 21 Sep 2013 07:09:43 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
In-Reply-To: <1379708201.54.0.475629183229.issue19050@psf.upfronthosting.co.za>
Message-ID: <523D4632.7080505@timgolden.me.uk>


Tim Golden added the comment:

I can confirm that 2.7.2 hard-crashes as described on Windows. I'm not 
sure if I have the wherewithal to build 2.7 on this laptop to see if 
it's fixed in tip.

3.3 simply raises an IOError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:10:41 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Sep 2013 07:10:41 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1379747441.48.0.0329150363208.issue19050@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:20:12 2013
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 21 Sep 2013 07:20:12 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1379748012.54.0.822228170471.issue1185124@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


----------
nosy: +akitada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:29:55 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 21 Sep 2013 07:29:55 +0000
Subject: [issue19060] docs: note that subprocess doesn't replace os.exec*
Message-ID: <1379748595.57.0.00736365306091.issue19060@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I always thought that subprocess is replacing all other methods of executing external programs from Python and it is a preferred way. Perhaps I was not attentive that people isolate:
  os.system
  os.spawn*
  os.popen*
and
  os.exec*

While subprocess replaces three first, it doesn't do this with the last one. The documentation should mention this in the header block. Proposed edit:

  ...
  replace several other, older modules and functions, such as:

     os.system
     os.spawn*
     os.popen*
     popen2.*
     commands.*

+ Note that it doesn't replace other ways of executing external
+ processes from Python, such as:
+
+    os.exec*

  Information about how the subprocess module can be used
  ...

----------
assignee: docs at python
components: Documentation
messages: 198188
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: docs: note that subprocess doesn't replace os.exec*
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19060>
_______________________________________

From report at bugs.python.org  Sat Sep 21 09:30:46 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 21 Sep 2013 07:30:46 +0000
Subject: [issue19060] docs: note that subprocess doesn't replace os.exec*
In-Reply-To: <1379748595.57.0.00736365306091.issue19060@psf.upfronthosting.co.za>
Message-ID: <1379748646.74.0.344971923938.issue19060@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

tag:easy (meaning, please mark it as easy for OpenHatch robots)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19060>
_______________________________________

From report at bugs.python.org  Sat Sep 21 11:38:21 2013
From: report at bugs.python.org (Thierry Seunevel)
Date: Sat, 21 Sep 2013 09:38:21 +0000
Subject: [issue19056] Windows 7,
 script exec not working without explicit cal of python.exe
In-Reply-To: <1379669328.14.0.507303810717.issue19056@psf.upfronthosting.co.za>
Message-ID: <1379756301.96.0.805384444889.issue19056@psf.upfronthosting.co.za>


Thierry Seunevel added the comment:

Many thanks for your answers.
printing the sys.path gave me this output (parsed with newlines)
'', 'D:\\soft\\python\\lib', 
'D:\\Thierry\\python\\d\\thierry\\python', <---- mispelled
'C:\\Windows\\system32\\python27.zip',
'd:\\soft\\python\\DLLs', 
'd:\\soft\\python\\lib\\plat-win', 
'd:\\soft\\python\\lib\\lib-tk', 
'd:\\soft\\python', 
'd:\\soft\\python\\lib\\site-packages'

I corrected the PATH and PYTHONPATH environment variables and now sys.path is 
'', 'd:\\thierry\\python', 
'C:\\Windows\\system32\\python27.zip', 
'd:\\soft\\python\\DLLs', 
'd:\\soft\\python\\lib', 
'd:\\soft\\python\\lib\\plat-win', 
'd:\\soft\\python\\lib\\lib-tk', 
'd:\\soft\\python', 
'd:\\soft\\python\\lib\\site-packages'

And it works !

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19056>
_______________________________________

From report at bugs.python.org  Sat Sep 21 12:44:26 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 10:44:26 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379760266.6.0.984248303253.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I think the indentation is a problem, for several reasons. In all the examples in the documentation, the form by using the interactive shell is the following:

    >>> class MyClass:
    ...     pass

otherwise:

    class MyClass:
        pass

This one is awful:

>>> class MyClass:
    pass

and in fact it is no used in the doc. So if you want to put the class clause in the interactive shell, you have to add the dots to indent the suite of the compound statement, in order to be consistent with the rest of all the documentation.
But it is not just a problem of beauty:

$ python -m doctest descriptor.rst 
**********************************************************************
File "descriptor.rst", line 165, in descriptor.rst
Failed example:
    class MyClass(object):
Exception raised:
    ...
        class MyClass(object):
                             ^
    SyntaxError: unexpected EOF while parsing
...

By applying the patch, the definitions of the classes RevealAccess and MyClass pass the documentation test. The whole example does not pass in any case, because you are not consistent using the shell notation.

----------
Added file: http://bugs.python.org/file31833/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 12:44:46 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 10:44:46 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379760286.61.0.363199759188.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31830/py2howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 12:44:53 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 10:44:53 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379760293.58.0.805408615047.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31831/py3howto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 12:47:31 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 10:47:31 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379760451.95.0.595012772935.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


----------
resolution: invalid -> works for me
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 12:56:47 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 21 Sep 2013 10:56:47 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379761007.32.0.578555927496.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Eli, seeing our discussion so far, ISTM that the parser-target interface is at the very heart of our disagreement.

For me, it's a good design that provides a clean separation of concerns between the parser that generates events, and the target (usually, but not necessarily a TreeBuilder) that processes them. The link back is then provided by the close() method (provided by both, BTW), which terminates the parsing process and passes the result through to the user. That result may be a tree, but that's completely up to the target, and whatever comes back is transparent to the parser (there's an example of that in the docs, BTW). That's a clean separation of concerns that I would like to copy in the design of the XMLPullParser (in fact, by inheriting from XMLParser). Extrapolating this exact design, whatever comes back from the callback methods should be transparent to the parser and should control the objects that the XMLPullParser collects for its events. I.e., it's the target's sole responsibility to convert the parser's calls into objects that make up both the collected events and the result returned by the parser's close() methods. Again, I consider this a very clean separation of concerns.

Essentially, I embrace the fact that the user is standing on both sides of the API and can control both the generation of the event objects (by providing a target object) and the processing of the events in front of the parser. To me, this is a very clean and extremely flexible design, and I hope it's clearer now why I consider it an excellent feature.

Now, several of your comments so far indicate an aversion towards the parser-target interface because it allows arbitrary objects to be returned by uncontrollable, user provided code, thus "tainting" the otherwise clean tree building interface of the new pull parser. On the other hand, you also stated that you would like to keep a separation between the parser and the TreeBuilder and do not want the parser to know about trees, so I guess that means that you also wouldn't want the parser to enforce any kind of tree building constraints on whatever the result of the parsing process is. As I said before, it's utterly unclear to me how both of these go together, but that's what I could extract from the discussion so far.

Would it be possible for you to clarify your own opinion on this topic, and, specifically, how you envision the role of the parser, the target and their separation of concerns during the event generation? I think this would help us get this discussion a little forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 13:24:54 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 Sep 2013 11:24:54 +0000
Subject: [issue19056] Windows 7,
 script exec not working without explicit cal of python.exe
In-Reply-To: <1379669328.14.0.507303810717.issue19056@psf.upfronthosting.co.za>
Message-ID: <1379762694.62.0.929031971454.issue19056@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Glad to see it's working.

----------
resolution: fixed -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19056>
_______________________________________

From report at bugs.python.org  Sat Sep 21 14:44:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 21 Sep 2013 12:44:28 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
Message-ID: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

This is a follow up to issue #8855. Currently the security warning is completely invisible from Python 2 docs http://docs.python.org/2/library/shelve.html and is located under screen border on Python 3 docs.

The proposal is to move warning out of the description of open() function to paragraph following module description, the same way is it is done for pickle http://docs.python.org/3.3/library/pickle.html

----------
assignee: docs at python
components: Documentation
messages: 198194
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Shelve documentation security warning is not visible
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sat Sep 21 14:44:55 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 21 Sep 2013 12:44:55 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <1379767495.46.0.253934850994.issue19061@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

tag:easy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sat Sep 21 14:52:58 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Sep 2013 12:52:58 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1379761007.32.0.578555927496.issue18990@psf.upfronthosting.co.za>
Message-ID: <CADiSq7ffCjVLc-qznTa=E3oCGeEBLTfBusTP1hthTpv_PmWAaA@mail.gmail.com>


Nick Coghlan added the comment:

Actually, I think it's reasonable to define the custom target nominally
abstracted by PullParser as always returning None from close(). As Eli
notes, it's designed to let you discard events as you go, so remembering
them internally to return from close() doesn't make sense.

That means the patch could be simplified to just removing the root
attribute without changing the result of calling close().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 14:55:53 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Sep 2013 12:55:53 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
 correctly
In-Reply-To: <1379599338.21.0.942329121924.issue10042@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e+M3NLkH9vQgjs7ETEmqtfRbm_=O++o3GQy9-hpopYxg@mail.gmail.com>


Nick Coghlan added the comment:

Raymond, do you still want to look at this one? Otherwise I'll finish it up
and commit it before the next alpha (I'll check the example in the enum
docs to see if it can be simplified, too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Sep 21 15:03:31 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 13:03:31 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379768611.51.0.733933061759.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

By looking at the other examples in the howto, I saw there is the same problem in all the definitions in the prompt, and furthermore, we are using a different number of spaces to indent MyClass respect the rest of the classes defined in the prompt. 
There is also a wrong indentation in the StaticMethod definition (no prompt definition):

class StaticMethod(object):
 "Emulate PyStaticMethod_Type() in Objects/funcobject.c"

 def __init__(self, f):
      self.f = f

 def __get__(self, obj, objtype=None):
      return self.f

Applying the py3full.patch, the howto passes all the documentation tests:

$ python -m doctest descriptor.rst | tail -n 1
***Test Failed*** 18 failures.
$ python -m doctest descriptor_modified.rst | tail -n 1
$


My 2 cents

----------
Added file: http://bugs.python.org/file31834/py3full.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 15:19:57 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 21 Sep 2013 13:19:57 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <CADiSq7ffCjVLc-qznTa=E3oCGeEBLTfBusTP1hthTpv_PmWAaA@mail.gmail.com>
Message-ID: <523D9CFC.5080509@behnel.de>


Stefan Behnel added the comment:

> That means the patch could be simplified to just removing the root
> attribute without changing the result of calling close().

Absolutely.

Returning the parse result from close() would still make it both more
consistent and easier to use (also from within iterparse()), but I agree
that that's more of a feature. If the goal is really just to get the bare
minimum API out that allows future extensions without introducing future
consistency issues, then I'm ok with that change, too.

However, note that the next lxml release will almost certainly have been
out for a while when Py3.4 finally lands (I'm currently planning the
release for next month, maybe early November), which means that the
complete, well integrated API, including target support for iterparse()
etc., will already have an established, publicly available implementation
when Py3.4 comes out. If ElementTree wants to have a word in the final
design of this feature, and wants to avoid introducing deliberate
incompatibilities in the future, then I'd prefer finishing up this
discussion before the next lxml release gets into beta state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 15:38:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 Sep 2013 13:38:39 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379770719.03.0.0956394080781.issue19054@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

In the latest patch there are 5-spaces indents in several places.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 15:44:35 2013
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 21 Sep 2013 13:44:35 +0000
Subject: [issue1065986] Fix pydoc crashing on unicode strings
Message-ID: <1379771075.68.0.0814128200078.issue1065986@psf.upfronthosting.co.za>


Akira Kitada added the comment:

Now we have a working fix for 2.7.
Could someone please review the attached patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1065986>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:05:28 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 Sep 2013 14:05:28 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <CADiSq7ffCjVLc-qznTa=E3oCGeEBLTfBusTP1hthTpv_PmWAaA@mail.gmail.com>
Message-ID: <CAF-Rda_08k0F7GuTiC=sZg7ubJ3MYbg_HR2KM7uKV6q90CZO7w@mail.gmail.com>


Eli Bendersky added the comment:

On Sat, Sep 21, 2013 at 5:52 AM, Nick Coghlan <report at bugs.python.org>wrote:

>
> Nick Coghlan added the comment:
>
> Actually, I think it's reasonable to define the custom target nominally
> abstracted by PullParser as always returning None from close(). As Eli
> notes, it's designed to let you discard events as you go, so remembering
> them internally to return from close() doesn't make sense.
>

IMHO the documentation is already sufficient w.r.t. this. By convention,
when a method does not return anything, we just don't mention its return
value. So:

  close()
      Signal the parser that the data stream is terminated.

Seems good.

> That means the patch could be simplified to just removing the root
> attribute without changing the result of calling close().
>

Unfortunately I don't have time to review refactoring patches now. In light
of a larger refactoring planned in this part of the module in the future, I
don't think it's very important to tweak things right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:14:18 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 21 Sep 2013 14:14:18 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1379772858.05.0.70467032104.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Unfortunately I don't have time to review refactoring patches now. In light of a larger refactoring planned in this part of the module in the future, I don't think it's very important to tweak things right now.

You misunderstood. The proposal was to remove the ".root" attribute, because it introduces a new API that hinders the future development and unnecessarily introduces an unprecedented inconsistency with existing APIs.

This is not a refactoring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:26:26 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Sep 2013 14:26:26 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1379772858.05.0.70467032104.issue18990@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f_vHNPyGWGaDw9u=baEvp_oCve0fHoFEn4SrMXKmC66g@mail.gmail.com>


Nick Coghlan added the comment:

Right, the minimum change needed is to prefix it with an underscore, but if
it isn't actually needed for anything, we may as well remove it entirely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:28:42 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 14:28:42 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379773722.38.0.0135284474745.issue19054@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


Removed file: http://bugs.python.org/file31834/py3full.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:29:10 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 14:29:10 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379773750.24.0.182121104004.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

You are right. Now it should be ok

----------
Added file: http://bugs.python.org/file31835/py3full.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:34:41 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Sep 2013 14:34:41 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379774081.21.0.401853149066.issue19001@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The regular build (with threads) on that machine has the same problem.

Closing the issue is fine, but there does not seem to be an easy way
to upgrade Fedora from 16 to 19. Perhaps we can skip the test so that
the buildbot continues to be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:39:14 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 14:39:14 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379774354.16.0.48841804711.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

By the way, it does not pass all the tests in Python 2.7:

$ python2.7 -m doctest descriptor_modified.rst | tail -n 1
***Test Failed*** 3 failures.

If we want to be very rigorous, in order to pass the tests in Py2.7 too (kipping the rst aligned between py2 and py3), we have to add 3 others doctest: +SKIP directives. 

PS. I think there is a small bug in sphinx, related to our examples:

https://bitbucket.org/birkenfeld/sphinx/issue/1271/doctest-directive-and-dots-not-hidden

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 16:47:30 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 21 Sep 2013 14:47:30 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <CADiSq7f_vHNPyGWGaDw9u=baEvp_oCve0fHoFEn4SrMXKmC66g@mail.gmail.com>
Message-ID: <CAF-Rda_zWj34wnbHMOGSq92hgUoSkP=z-suYf23t5OtQq9qkxQ@mail.gmail.com>


Eli Bendersky added the comment:

On Sat, Sep 21, 2013 at 7:26 AM, Nick Coghlan <report at bugs.python.org>wrote:

>
> Nick Coghlan added the comment:
>
> Right, the minimum change needed is to prefix it with an underscore, but if
> it isn't actually needed for anything, we may as well remove it entirely.
>

Just to be clear - do we consider all non-prefixed-with-underscore
attributes of classes in the stdlib part of the public API, even when
they're explicitly undocumented? And while we're at it, all
non-prefixed-with-underscore methods as well?

I still consider this refactoring gratuitious at this point. The API is
well defined by the documentation. All the rest is implementation details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 17:01:01 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 21 Sep 2013 15:01:01 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <CAF-Rda_zWj34wnbHMOGSq92hgUoSkP=z-suYf23t5OtQq9qkxQ@mail.gmail.com>
Message-ID: <523DB4AC.8000105@behnel.de>


Stefan Behnel added the comment:

> I still consider this refactoring gratuitious at this point. The API is
> well defined by the documentation. All the rest is implementation details.

Famous last words.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 21 17:39:03 2013
From: report at bugs.python.org (patrick wai)
Date: Sat, 21 Sep 2013 15:39:03 +0000
Subject: [issue19062] problems with pyshell to get userdir
Message-ID: <1379777943.19.0.474410652516.issue19062@psf.upfronthosting.co.za>


New submission from patrick wai:

#file
idlelib/configHandler.py

#code
userDir = os.path.expanduser('~') 

#os
windows 7 sp1

it doesnt get final userdir path. it doesnt work correctly for userdir . 
this cause python3.3 IDLE GUI can not be opened on my pc . 
as per the docment says as follows:

help(os.path.expanduser)
Help on function expanduser in module ntpath:

expanduser(path)
    Expand ~ and ~user constructs.
    
    If user or $HOME is unknown, do nothing.

help(os.path.expandvars)
Help on function expandvars in module ntpath:

expandvars(path)
    Expand shell variables of the forms $var, ${var} and %var%.
    
    Unknown variables are left unchanged.

the right code may be:

userDir = os.path.expandvars(os.path.expanduser('~'))

----------
components: IDLE
messages: 198210
nosy: weizhao
priority: normal
severity: normal
status: open
title: problems with pyshell to get userdir
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/issue19062>
_______________________________________

From report at bugs.python.org  Sat Sep 21 17:57:47 2013
From: report at bugs.python.org (patrick wai)
Date: Sat, 21 Sep 2013 15:57:47 +0000
Subject: [issue19062] problems with pyshell to get userdir
In-Reply-To: <1379777943.19.0.474410652516.issue19062@psf.upfronthosting.co.za>
Message-ID: <CAL6+1BmD=sqS0SsD89kJ8wfOyWL1=2iFKVGEcHkxxXpNx8ysGA@mail.gmail.com>


patrick wai added the comment:

i am working under non-administrator account .
in fact os.path.expanduser('~') works well when as admin run .
but just got a %userprofile% when as standard account .

On Sat, Sep 21, 2013 at 11:39 PM, patrick wai <report at bugs.python.org>wrote:

>
> New submission from patrick wai:
>
> #file
> idlelib/configHandler.py
>
> #code
> userDir = os.path.expanduser('~')
>
> #os
> windows 7 sp1
>
> it doesnt get final userdir path. it doesnt work correctly for userdir .
> this cause python3.3 IDLE GUI can not be opened on my pc .
> as per the docment says as follows:
>
> help(os.path.expanduser)
> Help on function expanduser in module ntpath:
>
> expanduser(path)
>     Expand ~ and ~user constructs.
>
>     If user or $HOME is unknown, do nothing.
>
> help(os.path.expandvars)
> Help on function expandvars in module ntpath:
>
> expandvars(path)
>     Expand shell variables of the forms $var, ${var} and %var%.
>
>     Unknown variables are left unchanged.
>
> the right code may be:
>
> userDir = os.path.expandvars(os.path.expanduser('~'))
>
> ----------
> components: IDLE
> messages: 198210
> nosy: weizhao
> priority: normal
> severity: normal
> status: open
> title: problems with pyshell to get userdir
> 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/issue19062>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19062>
_______________________________________

From report at bugs.python.org  Sat Sep 21 18:43:48 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 21 Sep 2013 16:43:48 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1379781828.51.0.00881865820996.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Ok, Here is a new patch.
We now inherit from BufferedIOBase.  We must implement read(amt) ourselves, since the base class does not do it.

I was wrong about the final chunk, it is in fact 0\r\n.  A final \r\n is then added to signal the end of the optional trailers.

Added a bunch of tests for chunked encoding, plus tests to verify http synchronization for keepalive connections.

----------
Added file: http://bugs.python.org/file31836/httpresponse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Sat Sep 21 19:36:50 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Sep 2013 17:36:50 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379785010.07.0.996887168465.issue19054@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 20:03:38 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sat, 21 Sep 2013 18:03:38 +0000
Subject: [issue14983] email.generator should always add newlines after closing
 boundaries
In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>
Message-ID: <1379786618.01.0.40532435822.issue14983@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

Seems this hasn't been resolved.  I have to disagree with David's interpretation of RFC 2046.  The definition of a boundary says that it is "terminated" with a CRLF.  It also clarifies that the introducing CRLF is "conceptually part" of the boundary.  Thus each boundary contains both the leading and the trailing CRLF.  There is no exception for the final boundary that I can see.

This implies that when two boundaries abut, they need to be separated by *two* CRLFs, the trailing CRLF on the ending boundary of the inner multipart and the leading CRLF on the next boundary (which might be a separator or the ending boundary) of the containing multipart.

----------
nosy: +sjt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14983>
_______________________________________

From report at bugs.python.org  Sat Sep 21 20:20:06 2013
From: report at bugs.python.org (Daniel Kahn Gillmor)
Date: Sat, 21 Sep 2013 18:20:06 +0000
Subject: [issue14983] email.generator should always add newlines after closing
 boundaries
In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>
Message-ID: <1379787606.06.0.603139756682.issue14983@psf.upfronthosting.co.za>


Daniel Kahn Gillmor added the comment:

I think the relevant specification for PGP/MIME-signed messages is RFC 3156:

 https://tools.ietf.org/html/rfc3156#page-5

in particular:

      Note: The accepted OpenPGP convention is for signed data to end
      with a <CR><LF> sequence.  Note that the <CR><LF> sequence
      immediately preceding a MIME boundary delimiter line is considered
      to be part of the delimiter in [3], 5.1.  Thus, it is not part of
      the signed data preceding the delimiter line.  An implementation
      which elects to adhere to the OpenPGP convention has to make sure
      it inserts a <CR><LF> pair on the last line of the data to be
      signed and transmitted (signed message and transmitted message
      MUST be identical).

----------
nosy: +dkg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14983>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:19:03 2013
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Sat, 21 Sep 2013 19:19:03 +0000
Subject: [issue14983] email.generator should always add newlines after closing
 boundaries
In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>
Message-ID: <1379791143.32.0.544090641253.issue14983@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

Following OpenPGP convention is clearly optional (or maybe a SHOULD, but the word "elect" makes it a pretty weak SHOULD).  RFC 2046 is a MUST, it's not a matter of "convention".

The problem is that a parser that works forward in the message will swallow the terminating CRLF of the boundary of the signed multipart, and then not find a CRLF to introduce the boundary that separates the content from the signature.  By MIME rules it will treat the signature (including the unrecognized boundary) as an epilogue, and ignore it.  This is not at all special to multipart/signed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14983>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:21:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 19:21:09 +0000
Subject: [issue14983] email.generator should always add newlines after closing
 boundaries
In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>
Message-ID: <1379791269.19.0.117274462011.issue14983@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, there are two problems here, I think (it's been a while since I looked at this): we should indeed be adding a crlf between mime boundary lines.  But also the clients should technically be handling it not being there, as well as the case of extra whitespace being added between the end of the delimiter and the following crlf (which I'm guessing they don't, since the logical way to handle that would be to ignore anything after the end of the delimiter string, in which case this problem wouldn't arise).

Specifically:

   The boundary may be followed by zero or more characters of linear
   whitespace. It is then terminated by either another CRLF...

and:

   NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
   boundary value with the beginning of each candidate line.  An exact
   match of the entire candidate line is not required; it is sufficient
   that the boundary appear in its entirety following the CRLF.

So it seems to me that the PGP spec is not RFC conformant...but if we were following the RFC it wouldn't be an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14983>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:22:28 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 21 Sep 2013 19:22:28 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
Message-ID: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>


New submission from Florian Apolloner:

Take the following example:

>>> from email.mime.nonmultipart import *
>>> from email.charset import *
>>> msg = MIMENonMultipart('text', 'plain')
>>> cs = Charset('utf-8')
>>> cs.body_encoding = None
>>> msg.set_payload('? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.', cs)
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Type: text/plain; charset="utf-8"\nContent-Transfer-Encoding: 7bit\n\n? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.'

Till python 3.3.2 this created the email as 8bit, which is in line with what Thunderbird creates on my box. And if I understand the RFC correctly (https://tools.ietf.org/html/rfc2045#section-2.7) 7bit should only be used for ASCII. This issue was introduced by http://hg.python.org/cpython/rev/64e004737837 -- I changed orig = msg.get_payload(decode=True) back to it's original value (decode=False) in encode_7or8bit and get the "correct" behavior again. Running the tests didn't cause any errors (I hope I ran the correct one).

----------
components: Library (Lib)
messages: 198217
nosy: apollo13
priority: normal
severity: normal
status: open
title: Python 3.3.3  encodes emails containing non-ascii data as 7bit
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:23:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 19:23:09 +0000
Subject: [issue14983] email.generator should always add newlines after closing
 boundaries
In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>
Message-ID: <1379791389.61.0.664455048292.issue14983@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh, rather than "not conformant" I should have said that the two RFCs are in conflict, in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14983>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:27:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 19:27:37 +0000
Subject: [issue14983] email.generator should always add newlines after closing
 boundaries
In-Reply-To: <1338619942.49.0.98561751956.issue14983@psf.upfronthosting.co.za>
Message-ID: <1379791657.3.0.499462327853.issue14983@psf.upfronthosting.co.za>


R. David Murray added the comment:

Stephen: my post crossed yours.  Yes, I agree with your logic, having re-read the spec (the trailing CR is clearly part of the boundary).  But I still think the logic of the signing/validation is an invitation for running into problems like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14983>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:31:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 19:31:37 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <1379791897.97.0.619273491874.issue19063@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is definitely a bug here, but 8bit would also be wrong, since you are calling as_string.  It *should* be producing a 7bit CTE with a base64 encoded part in that case.

----------
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:36:35 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 21 Sep 2013 19:36:35 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <1379792195.57.0.951708537335.issue19063@psf.upfronthosting.co.za>


Florian Apolloner added the comment:

Am I not explicitelly disabling base64 by setting body_encoding to None?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:39:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 19:39:31 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <1379792371.78.0.137324399959.issue19063@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are, but you are also calling as_string.  Unicode can not handle 8bit data, therefore the email package must down-transform all data to 7bit when converting it to a string, just like a mail server trying to send to another mail server that can only handle 7bit would do.

If you used BytesGenerator to serialize the message, *then* you would expect to see 8bit utf-8 data in the body.

There are supposed to be tests for these cases, so I have to investigate why the tests are broken, as well :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Sat Sep 21 21:58:31 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 21 Sep 2013 19:58:31 +0000
Subject: [issue19054] Descriptors howto
In-Reply-To: <1379611586.05.0.268234554629.issue19054@psf.upfronthosting.co.za>
Message-ID: <1379793511.54.0.920015786281.issue19054@psf.upfronthosting.co.za>


Marco Buttu added the comment:

$ python -c "import this" | grep "silently"
Errors should never pass silently

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19054>
_______________________________________

From report at bugs.python.org  Sat Sep 21 23:05:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Sep 2013 21:05:42 +0000
Subject: [issue19064] can't run py3 benchmarks
Message-ID: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

After the latest changes I don't understand how I'm supposed to run translated Python 3 benchmarks:

$ ./perf.py -fb mako_v2 ../opt/python ../x32opt/python 
Running mako_v2...
INFO:root:Running ../x32opt/python ./performance/bm_mako_v2.py -n 50
Traceback (most recent call last):
  File "./perf.py", line 2460, in <module>
    main(sys.argv[1:])
  File "./perf.py", line 2416, in main
    options)))
  File "./perf.py", line 1528, in BM_mako_v2
    return SimpleBenchmark(MeasureMakoV2, *args, **kwargs)
  File "./perf.py", line 714, in SimpleBenchmark
    *args, **kwargs)
  File "./perf.py", line 1524, in MeasureMakoV2
    iteration_scaling=10)
  File "./perf.py", line 1113, in MeasureGeneric
    inherit_env=options.inherit_env)
  File "./perf.py", line 1071, in CallAndCaptureOutput
    raise RuntimeError("Benchmark died: " + stderr.decode('latin1'))
RuntimeError: Benchmark died: Traceback (most recent call last):
  File "./performance/bm_mako_v2.py", line 26, in <module>
    from mako.template import Template
  File "/home/antoine/cpython/benchmarks/lib/Mako-0.7.3/mako/template.py", line 622
    exec code in module.__dict__, module.__dict__
            ^
SyntaxError: invalid syntax

----------
assignee: brett.cannon
components: Benchmarks
messages: 198224
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: can't run py3 benchmarks
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19064>
_______________________________________

From report at bugs.python.org  Sat Sep 21 23:19:32 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Sep 2013 21:19:32 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379798372.62.0.017302955484.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A class attribute is still a special case fix to a generic problem, if indeed the message is a problem.

If class attribute backup is to become a requirement of all delete methods, it needs to first be documented, after pydev discussion. To apply the class attribute fix generally is tricky. If one does not create a class attribute backup for every attribute referenced in __del__, one must analyze the __init__ method for all points of possible failure, to see which attributes referenced in __del__ might be missing. Changing __init__ might change the analysis. This looks like a bad path to me.

The whole point of the special case ignoring of AttributeError in __delete__ methods is that AttributeErrors are *expected* in certain circumstances.

I opened a thread on pydev to discuss this issue.
"Revert #12085 fix for __del__ attribute error message"

The OP can avoid this issue entirely by using a conditional
  if sys.version_info < (3, 2, 0)
I consider this better code than intentionally creating an uninitialized instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sat Sep 21 23:36:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Sep 2013 21:36:33 +0000
Subject: [issue1065986] Fix pydoc crashing on unicode strings
Message-ID: <1379799393.21.0.391730508525.issue1065986@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1065986>
_______________________________________

From report at bugs.python.org  Sun Sep 22 00:05:22 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 21 Sep 2013 22:05:22 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <1379801122.13.0.170217598802.issue19063@psf.upfronthosting.co.za>


Florian Apolloner added the comment:

Using BytesGenerator I get:
>>> fp = BytesIO()
>>> g = BytesGenerator(fp)
>>> msg = MIMENonMultipart('text', 'plain')
>>> msg.set_payload('? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.', cs)
>>> g.flatten(msg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.3/email/generator.py", line 112, in flatten
    self._write(msg)
  File "/usr/lib/python3.3/email/generator.py", line 177, in _write
    self._dispatch(msg)
  File "/usr/lib/python3.3/email/generator.py", line 203, in _dispatch
    meth(msg)
  File "/usr/lib/python3.3/email/generator.py", line 421, in _handle_text
    super(BytesGenerator,self)._handle_text(msg)
  File "/usr/lib/python3.3/email/generator.py", line 233, in _handle_text
    self._write_lines(payload)
  File "/usr/lib/python3.3/email/generator.py", line 158, in _write_lines
    self.write(laststripped)
  File "/usr/lib/python3.3/email/generator.py", line 395, in write
    self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u0410' in position 0: ordinal not in range(128)

But I might be using it wrong :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Sun Sep 22 00:27:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 22:27:17 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379802437.7.0.574325556181.issue12085@psf.upfronthosting.co.za>


R. David Murray added the comment:

__del__ methods are in general tricky because they are in the general case run asynchronously.  Therefore any proposal to "attach" the message to another message is a non-starter.

If a __del__ method depends on attributes set in the __init__, then the programmer needs to decide if they want to handle the possibility of __init__ failing, and therefore __del__ running without __init__ having completed.  For the stdlib, I think I'd lean toward handling such cases, in which case IMO the Pythonic thing to do is indeed to have a class attribute to provide the pre-__init__ default.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 00:29:39 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 21 Sep 2013 22:29:39 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <1379802579.37.0.211641975848.issue19063@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Sun Sep 22 00:30:48 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 21 Sep 2013 22:30:48 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379802648.14.0.642749363377.issue12085@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 00:44:25 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 21 Sep 2013 22:44:25 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379803465.23.0.824301901086.issue12085@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

FWIW, using class attributes to ensure __del__ does not hit AttributeError when __init__ failed is more idiomatic than using three-argument getattr().

The reason: in general it is possible that __del__ calls almost any other method on a class (e.g. for a buffered I.O stream open for writing, __del__ might call close() which might attempt to flush the buffer).  It is not reasonable (and ugly :-) to use three-argument in all code that might be called by __del__.  But it is reasonable to use class attributes to pre-initialize instance variables set by __init__ to "safe" defaults like None.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 00:49:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Sep 2013 22:49:31 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379803771.62.0.767712246681.issue12085@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> The whole point of the special case ignoring of AttributeError in 
> __delete__ methods is that AttributeErrors are *expected* in certain
> circumstances.

You are completely misunderstanding this. There is no special case for AttributeError inside __del__, every exception is treated the same.
And by the way, this behaviour is documented:
http://docs.python.org/3.3/reference/datamodel.html#object.__del__
("Due to the precarious circumstances under which __del__() methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to sys.stderr instead.")

+1 for using a class attribute here, much cleaner than a getattr() dance.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 01:02:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Sep 2013 23:02:08 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379804527.99.0.805331581279.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The message problem can arise during exit if __del__ depends an any attribute of any object. It is hard to imagine a __del__ method that does not. Any __del__ method, including that of Popen, could handle AttributeErrors by wrapping the whole body in

try:
  <body>
except AttributeError:
  pass

The is essentially what is done by the code that calls __del__, except that 'pass' is replaced by "print(message, file=sys.stderr)".

If we patch Popen at all, I think this try:except should be the fix, not a class attribute.

To explain what I meant by the class attribute hack being tricky, consider the original version of Popen.__del__, minus the comments. 

    def __del__(self, _maxsize=sys.maxsize, _active=_active):
        if not self._child_created:
            return
        self._internal_poll(_deadstate=_maxsize)
        if self.returncode is None and _active is not None:
            _active.append(self)

Since self._internal_poll is an instance method, it is not a problem. But what about the self.returncode data attribute? Should we also add a class 'returncode' attribute? If so, what should be its value? None? or object()? Or is it guaranteed that when _child_created is set true, returncode will be defined, so that a class attribute is not needed?

I don't know the answers to these questions. Popen.__init__ is about 130 lines and self._child_created is set to True in two other methods. I did not look where returncode is set, but it is not near the spots where _child_created is set True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 01:11:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Sep 2013 23:11:15 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379805075.51.0.800398063517.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Reading Antoine's message more carefully, and the cited doc line, the generic fix to prevent the warning would be

try:
 <__del__ body>
except Exception:
  pass

The question is, do we only want to block the warning when someone calls Popen with the wrong number of arguments, or always?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 01:31:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Sep 2013 23:31:00 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379806260.39.0.303221681406.issue12085@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, that is not a good fix.  It would mask other programming errors.  There is a *reason* the error/traceback is printed when an error occurs.

The fact that the Popen logic may be a bit complex is not an argument in favor of a fix that hides errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 01:54:41 2013
From: report at bugs.python.org (Oleg Oshmyan)
Date: Sat, 21 Sep 2013 23:54:41 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379807681.56.0.0168340356108.issue12085@psf.upfronthosting.co.za>


Oleg Oshmyan added the comment:

> But what about the self.returncode data attribute? Should we also add a
> class 'returncode' attribute? If so, what should be its value? None? or
> object()? Or is it guaranteed that when _child_created is set true,
> returncode will be defined, so that a class attribute is not needed?

For what it's worth, returncode is indeed guaranteed to be defined when _child_created is True: it is initialized in __init__ before _execute_child is run. Of course, this does not help the general case of __del__ methods in other classes.

Silencing all AttributeErrors in all __del__ calls may be an easy and generic solution, but it will also hide genuine logic errors. I think it is reasonable to expect classes with __del__ to be careful about using attributes that exist, just like they must be careful about performing high-level operations that are valid in whatever state the object might be: destroy/close only things that have been created/opened, undo only actions that have been done etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 02:03:21 2013
From: report at bugs.python.org (Chris Adams)
Date: Sun, 22 Sep 2013 00:03:21 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
Message-ID: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>


New submission from Chris Adams:

If you use detect_types=sqlite3.PARSE_DECLTYPES with sqlite3 and insert a timezone-aware datetime instance, you will get a ValueError if you attempt to read it back out: 

 File "/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/sqlite3/dbapi2.py", line 68, in convert_timestamp
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))
ValueError: invalid literal for int() with base 10: '03+00'

Although this immediately gets into the thorny stdlib timezone support situation, it's extremely annoying to have the out-of-the-box module break round-tripping data and it looks like support for simple UTC offsets isn't too horrible ? something like https://gist.github.com/acdha/6655391 works in very limited testing:

def tz_aware_timestamp_adapter(val):
    datepart, timepart = val.split(b" ")
    year, month, day = map(int, datepart.split(b"-"))

    if b"+" in timepart:
        timepart, tz_offset = timepart.rsplit(b"+", 1)
        if tz_offset == b'00:00':
            tzinfo = datetime.timezone.utc
        else:
            hours, minutes = map(int, tz_offset.split(b':', 1))
            tzinfo = datetime.timezone(datetime.timedelta(hours=hours, minutes=minutes))
    else:
        tzinfo = None

    timepart_full = timepart.split(b".")
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))

    if len(timepart_full) == 2:
        microseconds = int('{:0<6.6}'.format(timepart_full[1].decode()))
    else:
        microseconds = 0

    val = datetime.datetime(year, month, day, hours, minutes, seconds, microseconds, tzinfo)

    return val

sqlite3.register_converter('timestamp', tz_aware_timestamp_adapter)

----------
components: Library (Lib)
messages: 198234
nosy: acdha
priority: normal
severity: normal
status: open
title: sqlite3 timestamp adapter chokes on timezones
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Sun Sep 22 02:05:16 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Sep 2013 00:05:16 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379808316.42.0.374837323115.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Right. If _internal_poll raises, it should not be masked as that would be a true bug.

More research. 'self.returncode = None' comes before the only call to the appropriate posix/windows version of ._execute_child(), which is the only place where '_child_created = True'. So class level
    _child_created = False  # needed for __del__ if __init__ call fails
should be sufficient. With that added,
        self._child_created = False
in __init__ would not be really needed. 

As I said on pydev, making the warning a Warning would be a different issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Sun Sep 22 02:32:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Sep 2013 00:32:04 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>
Message-ID: <1379809924.9.0.338094909351.issue19065@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Sun Sep 22 02:33:39 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Sep 2013 00:33:39 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379810019.45.0.441975007429.issue19024@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Index entries for * and ** were added in #12531 so that both are indexed as operators, in function definitions, in function calls, and in the tutorial. If any of these places need improvement, there should be specific suggestions.

I do not think there should be separate documentation for the * symbol. It would only duplicate what is already present. There are many symbols with multiple uses.

Changing html search search for symbols, if possible, would be a different issue. But returning every use of '*' in the docs would not seem too useful. For anything in the index, the index in more useful.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 22 02:45:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Sep 2013 00:45:18 +0000
Subject: [issue19034] More useful repr for Tcl_Obj
In-Reply-To: <1379321252.25.0.835083719717.issue19034@psf.upfronthosting.co.za>
Message-ID: <1379810718.26.0.283854448507.issue19034@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This looks more useful to me; it might make tests easier. But I cannot be sure no one would object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19034>
_______________________________________

From report at bugs.python.org  Sun Sep 22 03:18:36 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Sep 2013 01:18:36 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379812716.73.0.552166881332.issue19024@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I concur with Terry.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 22 03:19:59 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Sep 2013 01:19:59 +0000
Subject: [issue19034] More useful repr for Tcl_Obj
In-Reply-To: <1379321252.25.0.835083719717.issue19034@psf.upfronthosting.co.za>
Message-ID: <1379812799.36.0.377924715488.issue19034@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19034>
_______________________________________

From report at bugs.python.org  Sun Sep 22 03:34:39 2013
From: report at bugs.python.org (Oleg Oshmyan)
Date: Sun, 22 Sep 2013 01:34:39 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1379813679.46.0.589057931418.issue19021@psf.upfronthosting.co.za>


Oleg Oshmyan added the comment:

> Anothe possible solution is get rid from getattr and catch
> AttributeError instead.

Surely this would suffer from the same issue?

Why are the builtins getting deleted anyway? In fact, why is getattr getting deleted from the builtins module? The __builtins__ global is specifically not deleted when deleting modules to let destructors use builtins, and indeed the error message says "is not callable", suggesting the builtins module is still there but getattr is not. Is this perhaps some sort of IDLE bug?

----------
nosy: +chortos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Sun Sep 22 04:01:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 02:01:13 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <CAF-Rda_zWj34wnbHMOGSq92hgUoSkP=z-suYf23t5OtQq9qkxQ@mail.gmail.com>
Message-ID: <CADiSq7e6td0z07fTg10kZVY9Ow-vvtZyC4mPTM5QyM8UEq6nbA@mail.gmail.com>


Nick Coghlan added the comment:

An undocumented name without a leading underscore is always a bug, as it
means introspection and the prose docs give conflicting definitions of the
public API.

Whether the fix is to remove the offending name entirely, add a leading
underscore to mark it as private or document it as officially public is a
judgement call that needs to be made on a case by case basis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sun Sep 22 04:21:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 02:21:28 +0000
Subject: [issue19066] os.execv fails with spaced names on  Windows
Message-ID: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

If file to be executed with os.execv on Windows is located in directory with spaces, Python fails. This doesn't fail on Linux. To test, run:

  testexecv.py spaced

testexecv.py is attached.

----------
components: Library (Lib), Windows
files: testexecv.py
messages: 198242
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.execv fails with spaced names on  Windows
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file31837/testexecv.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 22 04:43:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 22 Sep 2013 02:43:39 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1379817819.5.0.840568442086.issue19050@psf.upfronthosting.co.za>


Tim Peters added the comment:

Here with 2.7.5 on Windows (Vista):

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 io, sys
>>> fd = io.open(sys.stdout.fileno(), 'wb')
>>> fd.close()
>>> sys.stdout.write("now writing on stdout will cause a crash")

At this point Windows pops up a box saying "python.exe has stopped working".  I don't have a debug build available, and all I can find out is that it's a memory error in this line, somewhere in MS's C libraries:

and         dword ptr ds:[718DD7A0h],0 

So, ya, it's a crash ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Sun Sep 22 09:01:15 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:01:15 +0000
Subject: [issue19067] Built-in range docstrings are not PEP-8 compatible
Message-ID: <1379833275.25.0.770459256521.issue19067@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The range documentation is not PEP-8 compatible:

>>> range.__doc__.splitlines()[-1]
'Returns a virtual sequence of numbers from start to stop by step.'
>>> range.__reversed__.__doc__
'Returns a reverse iterator.'
>>> range.index.__doc__.splitlines()[-1]
'Raises ValueError if the value is not present.'

They should have been 'Return...' and 'Raise...'. Patch is attached

----------
assignee: docs at python
components: Documentation
files: rangeobject.patch
keywords: patch
messages: 198244
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Built-in range docstrings are not PEP-8 compatible
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31838/rangeobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19067>
_______________________________________

From report at bugs.python.org  Sun Sep 22 09:09:02 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:09:02 +0000
Subject: [issue19068] Some built-in complex docstrings are not PEP-8 compatible
Message-ID: <1379833742.32.0.289149108308.issue19068@psf.upfronthosting.co.za>


New submission from Marco Buttu:

As reported in the title: 

>>> complex.conjugate.__doc__.splitlines()[-1]
'Returns the complex conjugate of its argument. (3-4j).conjugate() == 3+4j.'
>>> complex.__format__.__doc__.splitlines()[-1]
'Converts to a string according to format_spec.'

They should have been 'Return...' and 'Convert...'. Patch is attached

----------
assignee: docs at python
components: Documentation
files: complexobject.patch
keywords: patch
messages: 198245
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Some built-in complex docstrings are not PEP-8 compatible
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31839/complexobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19068>
_______________________________________

From report at bugs.python.org  Sun Sep 22 09:09:57 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:09:57 +0000
Subject: [issue19068] Some built-in complex docstrings are not PEP-8 compatible
In-Reply-To: <1379833742.32.0.289149108308.issue19068@psf.upfronthosting.co.za>
Message-ID: <1379833797.21.0.303167657754.issue19068@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19068>
_______________________________________

From report at bugs.python.org  Sun Sep 22 09:18:11 2013
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 22 Sep 2013 07:18:11 +0000
Subject: [issue19069] Built-in float docstrings are not PEP-8 compatible
Message-ID: <1379834291.01.0.660875879281.issue19069@psf.upfronthosting.co.za>


New submission from Marco Buttu:

As reported in the title: 

>>> float.as_integer_ratio.__doc__.splitlines()[2]
'Returns a pair of integers, whose ratio is exactly equal to the original'
>>> float.as_integer_ratio.__doc__.splitlines()[4]
'Raises OverflowError on infinities and a ValueError on NaNs.'
>>> float.conjugate.__doc__
'Returns self, the complex conjugate of any float.'
>>> float.is_integer.__doc__
'Returns True if the float is an integer.'
>>> float.__setformat__.__doc__.splitlines()[-2]
'Overrides the automatic determination of C-level floating point type.'
...

They should have been 'Return...', 'Raise...' and 'Override...'
Patch is attached

----------
assignee: docs at python
components: Documentation
files: floatobject.patch
keywords: patch
messages: 198246
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Built-in float docstrings are not PEP-8 compatible
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31840/floatobject.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19069>
_______________________________________

From report at bugs.python.org  Sun Sep 22 09:43:41 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Sep 2013 07:43:41 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1379835821.29.0.379302029787.issue19021@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

When the patch to #12085 is changed, as has been agreed, I think, this issue should go away.

Moving the deletion of builtins to later in the shutdown process has be discussed and maybe implemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Sun Sep 22 09:56:12 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 07:56:12 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379836572.1.0.0817147078781.issue19001@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

My F19 system (which works) shows gdb-7.6-34, while the new debugging output Antoine added shows 7.3.50.20110722-16.fc16 on F16

Maybe the new gdb version check needs to be looking for 7.4+ rather than 7.3+?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sun Sep 22 10:11:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 08:11:37 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379837497.16.0.256509990816.issue19001@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Hmm, I also noticed some issues with 2.7/3.2 on the RHEL 6 buildbot (similar to those previously reported in issue 15043).

I'll keep tinkering with it.

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sun Sep 22 10:45:26 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 22 Sep 2013 08:45:26 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <1379839526.06.0.863421129198.issue19061@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Using the "warning" directive can be backported from the 3.x docs.

For 3.x, it's already prominent enough. Your "screen border" is not everyone's screen border.

----------
nosy: +georg.brandl
versions:  -Python 2.6, 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/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 11:21:51 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 09:21:51 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <1379841711.46.0.371986285189.issue19061@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

The scope of warning is wrong. It is not a warning for open() call, and that's why it is easy to miss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 11:42:36 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 22 Sep 2013 09:42:36 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <1379842956.62.0.187448398716.issue19061@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Oh, please. It's big and red and directly below the open() description, how could you miss it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 11:42:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 09:42:43 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <3cjNxZ2Q17z7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 1d850260a356 by Georg Brandl in branch '2.7':
Closes #19061: make shelve security warning consistent between 2.x and 3.x.
http://hg.python.org/cpython/rev/1d850260a356

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 11:43:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 09:43:46 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1378841773.14.0.068562621875.issue19001@psf.upfronthosting.co.za>
Message-ID: <1379843026.19.0.17979478464.issue19001@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Looks like the RHEL 6 failures may have just been a change on the OS side that reintroduced the need for this old workaround: http://docs.python.org/devguide/faq.html#how-do-i-update-my-auto-load-safe-path-to-allow-test-gdb-to-run

I restored that FAQ, applied the config change on the buildbot and fixed the 2.7 branch to skip rather than fail (as it was previously supposed to, but the line that actually did the skip was lost in a backport from 3.x somewhere along the line).

----------
nosy: +bkabrda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sun Sep 22 11:44:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 09:44:34 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
In-Reply-To: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>
Message-ID: <3cjNzk1ywBz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 7a8616f21f26 by Georg Brandl in branch '2.7':
Closes #19043: remove detailed listing of versions from license files
http://hg.python.org/cpython/rev/7a8616f21f26

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Sun Sep 22 11:46:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 09:46:23 +0000
Subject: [issue19043] Remove detailed listing of all versions from LICENSE,
 Doc/license.rst
In-Reply-To: <1379552397.42.0.802042689988.issue19043@psf.upfronthosting.co.za>
Message-ID: <3cjP1p3PrCz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 59b6c3280827 by Georg Brandl in branch '3.3':
Closes #19043: remove detailed listing of versions from license files
http://hg.python.org/cpython/rev/59b6c3280827

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19043>
_______________________________________

From report at bugs.python.org  Sun Sep 22 12:35:43 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 10:35:43 +0000
Subject: [issue19070] In place operators of weakref.proxy() not returning self.
Message-ID: <1379846143.45.0.326809671068.issue19070@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

When a weakref.proxy() is used to wrap a class instance which implements in place operators, when one applies the in place operator to the proxy, one could argue the variable holding the proxy should still be a reference to the proxy after the in place operator has been done. Instead the variable is replaced with the class instance the proxy was wrapping.

So for the code:

from __future__ import print_function

import weakref

class Class(object):
     def __init__(self, value):
         self.value = value
     def __iadd__(self, value):
         self.value += value
         return self

c = Class(1)

p = weakref.proxy(c)

print('p.value', p.value)
print('type(p)', type(p))

p += 1

print('p.value', p.value)
print('type(p)', type(p))

one gets:

$ python3.3 weakproxytest.py
p.value 1
type(p) <class 'weakproxy'>
p.value 2
type(p) <class '__main__.Class'>

One might expect type(p) at the end to still be <class 'weakproxy'>.

In the weakref.proxy() C code, all the operators are set up with preprocessor macros.

#define WRAP_BINARY(method, generic) \
    static PyObject * \
    method(PyObject *x, PyObject *y) { \
        UNWRAP(x); \
        UNWRAP(y); \
        return generic(x, y); \
    }

#define WRAP_TERNARY(method, generic) \
    static PyObject * \
    method(PyObject *proxy, PyObject *v, PyObject *w) { \
        UNWRAP(proxy); \
        UNWRAP(v); \
        if (w != NULL) \
            UNWRAP(w); \
        return generic(proxy, v, w); \
    }

These are fine for:

WRAP_BINARY(proxy_add, PyNumber_Add)
WRAP_BINARY(proxy_sub, PyNumber_Subtract)
WRAP_BINARY(proxy_mul, PyNumber_Multiply)
WRAP_BINARY(proxy_div, PyNumber_Divide)
WRAP_BINARY(proxy_floor_div, PyNumber_FloorDivide)
WRAP_BINARY(proxy_true_div, PyNumber_TrueDivide)
WRAP_BINARY(proxy_mod, PyNumber_Remainder)
WRAP_BINARY(proxy_divmod, PyNumber_Divmod)
WRAP_TERNARY(proxy_pow, PyNumber_Power)
WRAP_BINARY(proxy_lshift, PyNumber_Lshift)
WRAP_BINARY(proxy_rshift, PyNumber_Rshift)
WRAP_BINARY(proxy_and, PyNumber_And)
WRAP_BINARY(proxy_xor, PyNumber_Xor)
WRAP_BINARY(proxy_or, PyNumber_Or)

Because a result is being returned and the original is not modified.

Use of those macros gives the unexpected result for:

WRAP_BINARY(proxy_iadd, PyNumber_InPlaceAdd)
WRAP_BINARY(proxy_isub, PyNumber_InPlaceSubtract)
WRAP_BINARY(proxy_imul, PyNumber_InPlaceMultiply)
WRAP_BINARY(proxy_idiv, PyNumber_InPlaceDivide)
WRAP_BINARY(proxy_ifloor_div, PyNumber_InPlaceFloorDivide)
WRAP_BINARY(proxy_itrue_div, PyNumber_InPlaceTrueDivide)
WRAP_BINARY(proxy_imod, PyNumber_InPlaceRemainder)
WRAP_TERNARY(proxy_ipow, PyNumber_InPlacePower)
WRAP_BINARY(proxy_ilshift, PyNumber_InPlaceLshift)
WRAP_BINARY(proxy_irshift, PyNumber_InPlaceRshift)
WRAP_BINARY(proxy_iand, PyNumber_InPlaceAnd)
WRAP_BINARY(proxy_ixor, PyNumber_InPlaceXor)
WRAP_BINARY(proxy_ior, PyNumber_InPlaceOr)

This is because the macro returns the result from the API call, such as PyNumber_InPlaceAdd() where as it should notionally be returning 'proxy' so that the variable holding the weakref proxy instance is set to the proxy object again and not the result of the inner API call.

In changing this though there is a complication which one would have to deal with.

If the result of the inner API call such as PyNumber_InPlaceAdd() is the same as the original object wrapped by the weakref proxy, then all is fine.

What though should be done if it is different as notionally this means that the reference to the wrapped object would need to be changed to the new value.

The issue is that if one had to replace the reference to the wrapped object with a different one due to the in place operator, then notionally the whole existence of that weakref is invalidated as you would no longer be tracking the same object the weakref proxy was created for.

This odd situation is perhaps why the code was originally written the way it was, although that then sees the weakref proxy being replaced which could cause different problems with the callback not later being called since the weakref proxy can be destroyed before the object it wrapped. As there is nothing in the documentation of the code which calls out such a decision, not sure if it was deliberate or simply an oversight.

Overall I am not completely sure what the answer should be, so I am logging it as interesting behaviour. Maybe this odd case needs to be called out in the documentation in some way at least. That or in place operators simply shouldn't be allowed on a weakref proxy because of the issues it can cause either way.

----------
components: Library (Lib)
messages: 198257
nosy: grahamd
priority: normal
severity: normal
status: open
title: In place operators of weakref.proxy() not returning self.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19070>
_______________________________________

From report at bugs.python.org  Sun Sep 22 12:42:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Sep 2013 10:42:12 +0000
Subject: [issue19070] In place operators of weakref.proxy() not returning self.
In-Reply-To: <1379846143.45.0.326809671068.issue19070@psf.upfronthosting.co.za>
Message-ID: <1379846532.71.0.899007192693.issue19070@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19070>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:08:12 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 11:08:12 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379842956.62.0.187448398716.issue19061@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+xw4TY0uru7v_DrYK1ZqhT31MbjGBtmYJW0nz8z6okug@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 22, 2013 at 12:42 PM, Georg Brandl <report at bugs.python.org>wrote:

> Oh, please. It's big and red and directly below the open() description,
> how could you miss it?
>

I believe that it is pretty easy with mobile browser due to screen
constraints. Can you test this on your mobile devices?

As for your argument about my border not being everyone's border, I believe
that my border accounts for 18%+ of browser market share.
http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-201308-201308-bar I
would be even more interested to see docs.python.org stats, which may be
more, because reading docs from tablet is more convenient, or less, because
there tables are not good development platforms for Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:11:57 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 22 Sep 2013 11:11:57 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <1379848317.96.0.746079129614.issue19061@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> I believe that it is pretty easy with mobile browser due to screen
> constraints. Can you test this on your mobile devices?

Sorry, but we don't adapt the docs *content* to any specific device.  You should never only read just a screenful in any case.  This is technical documentation, not a news article!

If you believe that you can improve the docs *design* (the CSS, mainly) to work better on mobile devices, be my guest!  There are certainly optimization opportunities, but that never relieves you of making sure you read the whole content that's relevant to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:12:36 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 11:12:36 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379812716.73.0.552166881332.issue19024@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xLHBfowKoc0kmt0zUGzACsZcs9J0OAkpbKnqsa9tiguqw@mail.gmail.com>


anatoly techtonik added the comment:

223 people + me out of 1422 disagree with you both.
http://stackoverflow.com/questions/101268/hidden-features-of-python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:18:34 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 11:18:34 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <CAPkN8xLHBfowKoc0kmt0zUGzACsZcs9J0OAkpbKnqsa9tiguqw@mail.gmail.com>
Message-ID: <CAPkN8xL96WSd23aPHu1FU+C6i00dAuKt7WntxtFvDZSSfN8i7A@mail.gmail.com>


anatoly techtonik added the comment:

To narrow the point of conflict, I say that argument unpacking *operators*
should have a prominent place in Python documentation that people can link
to. Current page
http://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists is
about functionality, not about operators, and therefore usage of these
while studying Python code can not be tracked back to documentation. Which
is why it is hidden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:23:57 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 11:23:57 +0000
Subject: [issue19070] In place operators of weakref.proxy() not returning self.
In-Reply-To: <1379846143.45.0.326809671068.issue19070@psf.upfronthosting.co.za>
Message-ID: <1379849037.26.0.0523888964286.issue19070@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ouch :P

Perhaps the least-incompatible fix would be to switch to returning the proxy if the object returned is the proxied object (which would do the right thing for proxies to mutable objects), while preserving the current behaviour when the in-place operation returns a new object?

That behaviour is still somewhat broken, but there's no obviously non-broken behaviour in that case, and this broadly preserves compatibility with the status quo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19070>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:27:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 11:27:42 +0000
Subject: [issue19047] Assorted weakref docs improvements
In-Reply-To: <1379577834.67.0.113922099701.issue19047@psf.upfronthosting.co.za>
Message-ID: <3cjRGk1Kq6z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset caa16423b324 by Nick Coghlan in branch 'default':
Close #19047: weakref doc cleanups
http://hg.python.org/cpython/rev/caa16423b324

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19047>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:36:23 2013
From: report at bugs.python.org (Oleg Oshmyan)
Date: Sun, 22 Sep 2013 11:36:23 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1379849783.82.0.185926662317.issue19021@psf.upfronthosting.co.za>


Oleg Oshmyan added the comment:

But the thing is, builtins are already supposed to be the very last thing destroyed at shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:39:56 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 11:39:56 +0000
Subject: [issue19071] Documentation on what self is for module-level functions
 is misleading/wrong.
Message-ID: <1379849996.18.0.35390897499.issue19071@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

In the documentation for Python 2.X at:

http://docs.python.org/2/extending/extending.html#a-simple-example

it says:

"""
The self argument points to the module object for module-level functions; for a method it would point to the object instance.
"""

In respect of module-level functions this is misleading or arguably wrong.

If one uses Py_InitModule() or Py_InitModule3(), then self is actually passed through as NULL for module-level functions in Python 2.

There is a caveat on use of Py_InitModule4() which used to be mentioned in documentation for Python 2.6 at:

http://docs.python.org/release/2.6.7/c-api/structures.html#METH_VARARGS

where it says:

"""
This is the typical calling convention, where the methods have the type PyCFunction. The function expects two PyObject* values. The first one is the self object for methods; for module functions, it has the value given to Py_InitModule4() (or NULL if Py_InitModule() was used).
"""

Although one can supply a special argument to Py_InitModule4() which will be supplied as self, this still isn't the module object and in fact the module object for the module will not even exist at the point Py_InitModule4() is called so it is not possible to pass it in. Plus within the init function of an extension, the module object is not that which would end up being used in a specific interpreter due to how the init function is only called once and a copy then made of the module for each interpreter.

This actual page in the documentation was changed in Python 2.7 and now in:

http://docs.python.org/2/c-api/structures.html#METH_VARARGS

says:

"""
The function expects two PyObject* values. The first one is the self object for methods; for module functions, it is the module object.
"""

So the reference to Py_InitModule4() was removed and simply says that module object is supplied, which isn't actually the case.

Now, that NULL is always passed for Py_InitModule() and Py_InitModule3() is the case with Python 2. In Python 3 at some point, the code in Python internals was changed so the module object is actually passed as documented.

So, maybe the intent was that when in Python 3 the code was changed to pass the module object to module-level functions that it be back ported to Python 2.7 and the documentation so changed, but looks like that back porting was never done, or if it was, it has been broken somewhere along the way.

Code used to verify this is all attached.

If compiled and installed for Python 3 one gets:

>>> import mymodule._extension
>>> id(mymodule._extension)
4480540328
>>> mymodule._extension.function()
<module 'mymodule._extension' from '/Users/graham/Projects/python-c-extension-template/lib/python3.3/site-packages/mymodule/_extension.so'>
>>> id(mymodule._extension.function())
4480540328

If compiled and installed for Python 2.7 one gets:

>>> import mymodule._extension
>>> id(mymodule._extension)
4554745960
>>> mymodule._extension.function()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: no module supplied for self

The function in the extension module was doing:

static PyObject *extension_function(PyObject *self, PyObject *args)
{
    if (!self) {
        PyErr_SetString(PyExc_TypeError, "no module supplied for self");
        return NULL;
    }

    Py_INCREF(self);
    return self;
}

----------
assignee: docs at python
components: Documentation
files: example.tar
messages: 198265
nosy: docs at python, grahamd
priority: normal
severity: normal
status: open
title: Documentation on what self is for module-level functions is misleading/wrong.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file31841/example.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19071>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:42:04 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 11:42:04 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379848317.96.0.746079129614.issue19061@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xKDqPvaiwaq7Whm6ErkMBcbyu+MouyoA2UWoB=QhB=9Mw@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 22, 2013 at 2:11 PM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl added the comment:
>
> > I believe that it is pretty easy with mobile browser due to screen
> > constraints. Can you test this on your mobile devices?
>
> Sorry, but we don't adapt the docs *content* to any specific device.  You
> should never only read just a screenful in any case.  This is technical
> documentation, not a news article!
>

I am sorry, but you're misplacing arguments. It looks like this:

me[1]> open() function description is a wrong place for warning that is
related to a whole module
you[2]> common, it is visible, that's the point anyway
me[3]> it is not visible on mobile
you[4]> we do not support mobile

[3] makes your point [2] invalid. And your point [4] doesn't apply as an
answer to [1].

 Now my arguments are:
1. Warning is located in the wrong place (bug is trivial, not important)
2. Wrong place causes problems with mobiles (trivial, somewhat matters)

And you argument that users (or is it for me personally?) should never read
only screenful for a module description is rather strange for the most of
us.

   "Why are things always in the last place you look for them?
    Because you stop looking when you find them."

I highly recommend you to read this book -
http://www.sensible.com/chapter.html - it's awesome.
And just for amusement -
http://uxmyths.com/post/647473628/myth-people-read-on-the-web

> If you believe that you can improve the docs *design* (the CSS, mainly) to
> work better on mobile devices, be my guest!  There are certainly
> optimization opportunities, but that never relieves you of making sure you
> read the whole content that's relevant to you.
>

There is nothing wrong with CSS or mobile design. There is an issue with
the placement of this specific piece of information, which comes detached
from the place (module description) where it belongs. Although the effect
of this bug is partially with background workaround, the cause is still
there.

To make it more real scenario for you. In corporate environment somebody
who issues a recommendation, is not necessarily the person who implements
it. If you're implementing everything yourself, of course you won't miss
the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:48:06 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 11:48:06 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379850486.67.0.172276426578.issue19024@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Unfortunately, there's currently no good place for this kind of detailed syntax reference documentation to go. The library reference doesn't cover syntax, the tutorial doesn't go into detailed semantics, and the language reference is written more for language implementors than it is for users.

My Python User's Reference project (http://svn.python.org/view/sandbox/trunk/userref/README.txt?view=markup) was designed to fill that gap, but I never found the time to do the ReST conversion myself, and nobody ever expressed interest in helping out with it, so it's now five years out of date.

Creating a cut down version of that as the "Python Syntax Reference" might be a reasonable approach. However, it's a project that could easily start life outside the core CPython repository.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:51:57 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 11:51:57 +0000
Subject: [issue19071] Documentation on what self is for module-level functions
 is misleading/wrong.
In-Reply-To: <1379849996.18.0.35390897499.issue19071@psf.upfronthosting.co.za>
Message-ID: <1379850717.95.0.721087477011.issue19071@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +loewis, ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19071>
_______________________________________

From report at bugs.python.org  Sun Sep 22 13:57:49 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 22 Sep 2013 11:57:49 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379767468.36.0.787421761294.issue19061@psf.upfronthosting.co.za>
Message-ID: <1379851069.95.0.20520057885.issue19061@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> me[1]> open() function description is a wrong place for warning that is
related to a whole module
> you[2]> common, it is visible, that's the point anyway
> me[3]> it is not visible on mobile
> you[4]> we do not support mobile

Your complaint was that it is "located under screen border".  My reply is that what the "screen border" is is highly device specific and that  we don't cater to specific devices, therefore rejecting your complaint.  I never said "we don't support mobile".  That's it for me and this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 14:02:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Sep 2013 12:02:02 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>
Message-ID: <1379851322.77.0.634696540938.issue19065@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This would be an useful improvement. Do you want to post a patch? See guidelines at http://docs.python.org/devguide/

----------
nosy: +belopolsky, ghaering, lemburg, pitrou
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Sun Sep 22 14:08:53 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 12:08:53 +0000
Subject: [issue19061] Shelve documentation security warning is not visible
In-Reply-To: <1379851069.95.0.20520057885.issue19061@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+rcB+qo5FjnQGQvYH22Tj5qUtaS7gPyyiF0yf5JiBGWg@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 22, 2013 at 2:57 PM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl added the comment:
>
> > me[1]> open() function description is a wrong place for warning that is
> related to a whole module
> > you[2]> common, it is visible, that's the point anyway
> > me[3]> it is not visible on mobile
> > you[4]> we do not support mobile
>
> Your complaint was that it is "located under screen border".  My reply is
> that what the "screen border" is is highly device specific and that  we
> don't cater to specific devices, therefore rejecting your complaint.  I
> never said "we don't support mobile".  That's it for me and this issue.
>

Well, at least now you know how I read the replies. Glad we settled this
down. Now it would be nice if somebody with CLA for docs could just move
this block upper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19061>
_______________________________________

From report at bugs.python.org  Sun Sep 22 14:12:44 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 12:12:44 +0000
Subject: [issue18553] os.isatty() is not Unix only
In-Reply-To: <1379603804.26.0.457312085185.issue18553@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+cuqmh6ds8e=qjm7qzVhfP4722K1aFOegrd=Ype52fzA@mail.gmail.com>


anatoly techtonik added the comment:

>
> > I having a snippet to fix that, should I open a new issue for patch?
>
> Please open a new issue.
>

Reference is welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18553>
_______________________________________

From report at bugs.python.org  Sun Sep 22 14:47:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 12:47:02 +0000
Subject: [issue18626] Make "python -m inspect <name>" meaningful
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <3cjT2G0q9rz7Ljp@mail.python.org>


Roundup Robot added the comment:

New changeset 2e1335245f8f by Nick Coghlan in branch 'default':
Close #18626: add a basic CLI for the inspect module
http://hg.python.org/cpython/rev/2e1335245f8f

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18626>
_______________________________________

From report at bugs.python.org  Sun Sep 22 14:49:39 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Sep 2013 12:49:39 +0000
Subject: [issue18626] Make "python -m inspect <name>" meaningful
In-Reply-To: <1375413160.45.0.218073630788.issue18626@psf.upfronthosting.co.za>
Message-ID: <1379854179.55.0.980675439153.issue18626@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for the initial patch Claudiu - I tweaked it a bit before committing it.

* as you suggested, displaying the source is the default, with a --details option to display the formatted info instead
* changed the displayed details (e.g. only displaying the search path for packages, displaying the line number for classes and functions
* a few tweaks to the actual implementation (e.g. using partition over find, avoiding tracebacks for a couple of likely user errors)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18626>
_______________________________________

From report at bugs.python.org  Sun Sep 22 15:22:44 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 13:22:44 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
Message-ID: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

The classmethod decorator when applied to a function of a class, does not honour the descriptor binding protocol for whatever it wraps. This means it will fail when applied around a function which has a decorator already applied to it and where that decorator expects that the descriptor binding protocol is executed in order to properly bind the function to the class.

A decorator may want to do this where it is implemented so as to be able to determine automatically the context it is used in. That is, one magic decorator that can work around functions, instance methods, class methods and classes, thereby avoiding the need to have multiple distinct decorator implementations for the different use case.

So in the following example code:

class BoundWrapper(object):
    def __init__(self, wrapped):
        self.__wrapped__ = wrapped
    def __call__(self, *args, **kwargs):
        print('BoundWrapper.__call__()', args, kwargs)
        print('__wrapped__.__self__', self.__wrapped__.__self__)
        return self.__wrapped__(*args, **kwargs)

class Wrapper(object):
    def __init__(self, wrapped):
        self.__wrapped__ = wrapped
    def __get__(self, instance, owner):
        bound_function = self.__wrapped__.__get__(instance, owner)
        return BoundWrapper(bound_function)

def decorator(wrapped):
    return Wrapper(wrapped)

class Class(object):
    @decorator
    def function_im(self):
        print('Class.function_im()', self)

    @decorator
    @classmethod
    def function_cm_inner(cls):
        print('Class.function_cm_inner()', cls)

    @classmethod
    @decorator
    def function_cm_outer(cls):
        print('Class.function_cm_outer()', cls)

c = Class()

c.function_im()
print()
Class.function_cm_inner()
print()
Class.function_cm_outer()

A failure is encountered of:

$ python3.3 cmgettest.py
BoundWrapper.__call__() () {}
__wrapped__.__self__ <__main__.Class object at 0x1029fc150>
Class.function_im() <__main__.Class object at 0x1029fc150>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

Traceback (most recent call last):
  File "cmgettest.py", line 40, in <module>
    Class.function_cm_outer()
TypeError: 'Wrapper' object is not callable

IOW, everything is fine when the decorator is applied around the classmethod, but when it is placed inside of the classmethod, a failure occurs because the decorator object is not callable.

One could argue that the error is easily avoided by adding a __call__() method to the Wrapper class, but that defeats the purpose of what is trying to be achieved in using this pattern. That is that one can within the bound wrapper after binding occurs, determine from the __self__ of the bound function, the fact that it was a class method. This can be inferred from the fact that __self__ is a class type.

If the classmethod decorator tp_descr_get implementation is changed so as to properly apply the descriptor binding protocol to the wrapped object, then what is being described is possible.

Having it honour the descriptor binding protocol also seems to make application of the Python object model more consistent.

A patch is attached which does exactly this.

The result for the above test after the patch is applied is:

BoundWrapper.__call__() () {}
__wrapped__.__self__ <__main__.Class object at 0x10ad237d0>
Class.function_im() <__main__.Class object at 0x10ad237d0>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_outer() <class '__main__.Class'>

That is, the decorator whether it is inside or outside now sees things in the same way.

If one also tests for calling of the classmethod via the instance:

print()
c.function_cm_inner()
print()
c.function_cm_outer()

Everything again also works out how want it:

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_inner() <class '__main__.Class'>

BoundWrapper.__call__() () {}
__wrapped__.__self__ <class '__main__.Class'>
Class.function_cm_outer() <class '__main__.Class'>

FWIW, the shortcoming of classmethod not applying the descriptor binding protocol to the wrapped object, was found in writing a new object proxy and decorator library called 'wrapt'. This issue in the classmethod implementation is the one thing that has prevented wrapt having a system of writing decorators that can magically work out the context it is used in all the time. Would be nice to see it fixed. :-)

The wrapt library can be found at:

https://github.com/GrahamDumpleton/wrapt
http://wrapt.readthedocs.org

The limitation in the classmethod implementation is noted in the wrapt documentation at:

http://wrapt.readthedocs.org/en/v1.1.2/issues.html#classmethod-get

----------
components: Interpreter Core
files: funcobject.c.diff
keywords: patch
messages: 198274
nosy: grahamd
priority: normal
severity: normal
status: open
title: classmethod doesn't honour descriptor protocol of wrapped callable
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file31842/funcobject.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Sun Sep 22 15:37:01 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Sun, 22 Sep 2013 13:37:01 +0000
Subject: [issue19073] Inability to specific __qualname__ as a property on a
 class instance.
Message-ID: <1379857021.17.0.738971350638.issue19073@psf.upfronthosting.co.za>


New submission from Graham Dumpleton:

Python 3 introduced __qualname__. This attribute exists on class types and also instances of certain class types, such as functions. For example:

def f(): pass

print(f.__name__)
print(f.__qualname__)

class Class: pass

print(Class.__name__)
print(Class.__qualname__)

yields:

f
f
Class
Class

An instance of a class however does not have __name__ or __qualname__ attributes. With:

c = Class()

print(c.__name__)
print(c.__qualname__)

yielding:

Traceback (most recent call last):
  File "qualnametest.py", line 13, in <module>
    print(c.__name__)
AttributeError: 'Class' object has no attribute '__name__'

Traceback (most recent call last):
  File "qualnametest.py", line 14, in <module>
    print(c.__qualname__)
AttributeError: 'Class' object has no attribute '__qualname__'

For a class, it is possible to override the __name__ attribute using a property.

class Class:
    @property
    def __name__(self):
        return 'override'

c = Class()

print(c.__name__)

With the result being:

override

This is useful in writing object proxies or function wrappers for decorators as rather than having to copy the __name__ attribute into the wrapper, the lookup can be deferred until when it is required.

The same though cannot be done for __qualname__. With:

class Class:
    @property
    def __qualname__(self):
        return 'override'

yielding an error when the class definition is being processed:

Traceback (most recent call last):
  File "qualnametest.py", line 16, in <module>
    class Class:
TypeError: type __qualname__ must be a str, not property

This means the same trick cannot be used in object proxies and function wrappers and instead __qualname__ must be copied and assigned explicitly as a string attribute in the __init__() function of the object proxy or function wrapper.

I can sort of understand a prohibition on __qualname__ being a string attribute in certain cases, especially if overriding it on a type or instance where __qualname__ attribute already exists, but I don't understand why a limitation would be imposed to prevent using a property as a means of generating the value for a class instance which doesn't otherwise have a __qualname__ attribute. There is no similar restriction for __name__.

Unless there is a good specific reason for this behaviour, the ability to override it with a property in cases where the __qualname__ attribute didn't already exist, would be handy for proxies and wrappers.

----------
components: Interpreter Core
messages: 198275
nosy: grahamd
priority: normal
severity: normal
status: open
title: Inability to specific __qualname__ as a property on a class instance.
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19073>
_______________________________________

From report at bugs.python.org  Sun Sep 22 15:39:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Sep 2013 13:39:20 +0000
Subject: [issue19073] Inability to specific __qualname__ as a property on a
 class instance.
In-Reply-To: <1379857021.17.0.738971350638.issue19073@psf.upfronthosting.co.za>
Message-ID: <1379857160.43.0.110362281375.issue19073@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I guess this would be a harmless improvement in any case.

----------
nosy: +pitrou
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19073>
_______________________________________

From report at bugs.python.org  Sun Sep 22 15:49:12 2013
From: report at bugs.python.org (koobs)
Date: Sun, 22 Sep 2013 13:49:12 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1379857752.35.0.432820817191.issue4366@psf.upfronthosting.co.za>


koobs added the comment:

Attaching an initial patch with the following changes:

- Update comment
- Add original (#1600860) and current issue ID references
- Remove sys.platform conditional
- Remove NOOP sysconfig.get_config_var call (Reported by: birkenfeld)

This results in all platforms receiving the same treatment as the default, which is consistent with the comment

----------
Added file: http://bugs.python.org/file31843/python-issue4366.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:11:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 14:11:15 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <3cjVvQ5c77z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 6d6d68c068ad by Jason R. Coombs in branch 'default':
Issue #18978: Allow Request.method to be defined at the class level.
http://hg.python.org/cpython/rev/6d6d68c068ad

New changeset 2b2744cfb08f by Jason R. Coombs in branch 'default':
Issue #18978: A more elegant technique for resolving the method
http://hg.python.org/cpython/rev/2b2744cfb08f

New changeset 061eb75339e2 by Jason R. Coombs in branch 'default':
Issue #18978: Add tests to capture expected behavior for class-level method overrides.
http://hg.python.org/cpython/rev/061eb75339e2

New changeset 8620aea9bbca by Jason R. Coombs in branch 'default':
Close #18978: Merge changes.
http://hg.python.org/cpython/rev/8620aea9bbca

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:16:17 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 14:16:17 +0000
Subject: [issue19074] Add PySide to GUI FAQ
Message-ID: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/2/faq/gui.html - this page misses info about PySide.

----------
assignee: docs at python
components: Documentation
messages: 198279
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Add PySide to GUI FAQ
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:17:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 14:17:35 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <3cjW2k5B1Zz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 7f13d5ecf71f by Jason R. Coombs in branch 'default':
Issue #18978: Update docs to reflect explicitly the ability to set the attribute at the class level.
http://hg.python.org/cpython/rev/7f13d5ecf71f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:32:39 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 22 Sep 2013 14:32:39 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1379860359.15.0.413569027899.issue18986@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I just want to say thanks for working on this. I also have needed this functionality for various needs in the past. To fulfill my needs, I wrote this implementation:

https://bitbucket.org/jaraco/jaraco.util/src/1ab3e7061f96bc5e179b6b2c46b06d1c20f87129/jaraco/util/dictlib.py?at=default#cl-221

That implementation is used in the irc library for a case-insensitive dict, but using the IRC-specific standard for case insensitivity (https://bitbucket.org/jaraco/irc/src/1576b10dc2923d4d7234319d2d1e11a5080e1f7d/irc/dict.py?at=default#cl-49).

I share this just to add a +1 for the need and to provide additional use cases and implementations for reference.

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:37:44 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Sep 2013 14:37:44 +0000
Subject: [issue19064] can't run py3 benchmarks
In-Reply-To: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>
Message-ID: <1379860664.28.0.605243827647.issue19064@psf.upfronthosting.co.za>


Brett Cannon added the comment:

``python3 perf.py -fb mako_v2 ../opt/python ../x32opt/python`` obviously assuming you are specifying Python 3 interpreters. =)

Feel free to tweak any docs you think should be touched up to make that more obvious.

----------
assignee: brett.cannon -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19064>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:41:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Sep 2013 14:41:47 +0000
Subject: [issue19064] can't run py3 benchmarks
In-Reply-To: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>
Message-ID: <1379860907.92.0.393801088938.issue19064@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well... It wasn't really obvious to me :-)
Why shouldn't the child interpreter decide which lib to use, though? "perf.py" is just an executable script (and its shebang specifies python, not python3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19064>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:42:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Sep 2013 14:42:31 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379860951.31.0.480063353229.issue19074@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I say we just delete that page. Trying to keep up with GUI toolkits is a losing battle (as shown by this bug report) and not worth our time and effort to try to maintain. Search engines are your friend in this instance.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:42:48 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Sep 2013 14:42:48 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379860968.03.0.458461418874.issue19074@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> low
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:46:04 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Sep 2013 14:46:04 +0000
Subject: [issue19064] can't run py3 benchmarks
In-Reply-To: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>
Message-ID: <1379861164.3.0.888332892155.issue19064@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Originally that didn't work too well because the benchmark suite could run Python 2 and Python 3 benchmarks simultaneously, but I don't know if that still works after the 2/3 merge.

As for having interpreter under test make the choice of what version to use is fine by me, it's just the current solution was the easiest to implement. If you want to change than go for it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19064>
_______________________________________

From report at bugs.python.org  Sun Sep 22 16:51:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 22 Sep 2013 14:51:05 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379861465.03.0.58125647714.issue19074@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The wiki is probably a better place for such information.

----------
nosy: +christian.heimes
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 17:09:18 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 15:09:18 +0000
Subject: [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1379862558.1.0.294825697685.issue15329@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

So, is deque a faster replacement for Queue.Queue or not?

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15329>
_______________________________________

From report at bugs.python.org  Sun Sep 22 18:04:22 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 22 Sep 2013 16:04:22 +0000
Subject: [issue19065] sqlite3 timestamp adapter chokes on timezones
In-Reply-To: <1379808201.46.0.645672081963.issue19065@psf.upfronthosting.co.za>
Message-ID: <1379865862.23.0.972576005804.issue19065@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Sounds like a reasonable request, but the proposed code does not seem to work for the Eastern hemisphere (negative tz offsets.)

I am not very familiar with sqlite module.  What timestamp format does it use?  Isn't it some varian of ISO 3339?  See issue 15873.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19065>
_______________________________________

From report at bugs.python.org  Sun Sep 22 18:14:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Sep 2013 16:14:12 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1379866452.57.0.339750639541.issue19024@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The StackOverflow question and answer about function calls is 5 years old and therefore out of date with respect to #12531, which specifically added index entries for function calls.

Perhaps my Python 3 symbol glossary "Python3 Syntax Symbol Uses"

https://code.google.com/p/xploro/downloads/detail?name=PySymbols.html&can=1&q=

could be expanded a bit or combined with other text, as well as being a basis for adding index entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Sun Sep 22 18:14:15 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 22 Sep 2013 16:14:15 +0000
Subject: [issue19022] Improve handling of type.__abstractmethods__ descriptor
In-Reply-To: <1379230408.43.0.525404043988.issue19022@psf.upfronthosting.co.za>
Message-ID: <1379866455.02.0.954977303727.issue19022@psf.upfronthosting.co.za>


Daniel Urban added the comment:

I like the 3rd alternative the most. It seems to me, that __abstractmethods__ is currently an undocumented implementation detail of ABCs. The 1st alternative would cause every type to have an empty __abstractmethods__ (which is technically correct, but probably not very useful). It seems to me that the 2nd alternative would not help very much in the original problem mentioned in issue10006 (automatically looking up every name found in dir). So I think, that the best would be to fix type.__dir__ this way. (Although, if we really want to document and use __abstractmethods__ on every type, then of course we should do the 1st alternative.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19022>
_______________________________________

From report at bugs.python.org  Sun Sep 22 18:23:27 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 22 Sep 2013 16:23:27 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
 tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1379867007.18.0.749326298728.issue1820@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

See also #5907.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Sun Sep 22 19:29:45 2013
From: report at bugs.python.org (Sunny)
Date: Sun, 22 Sep 2013 17:29:45 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1379870985.77.0.789178580422.issue1185124@psf.upfronthosting.co.za>


Sunny added the comment:

I've rewritten the source_synopsis function to use the tokenize module. 

It should now work with triple single quotes and hopefully all the other cases where __doc__ returns a string.

Since tokenize.tokenize needs a file object that is opened in binary mode, in the case of a StringIO object, i am reading the whole  object and converting it to a BytesIO object. I don't know if that is the right way. Also, the only instance i could find where source_synopsis is called with a StringIO object is in the ModuleScanner.run method. Maybe we could tweak this call to pass a byte-stream object to avoid the overhead of re-conversion?

All the current tests pass.

----------
keywords: +patch
nosy: +sunfinite
Added file: http://bugs.python.org/file31844/myfirst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Sun Sep 22 19:30:34 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Sep 2013 17:30:34 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379871034.58.0.388915899025.issue19074@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

If only wiki had a theme like Sphinx docs.. But I agree that static FAQ look dead compared to wiki or stackoverflow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 19:35:20 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 22 Sep 2013 17:35:20 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379871320.51.0.91825187514.issue19074@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

+1 to delete

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 20:02:22 2013
From: report at bugs.python.org (Jason Yeo)
Date: Sun, 22 Sep 2013 18:02:22 +0000
Subject: [issue19075] Add sorting algorithm visualization to turtledemo
Message-ID: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>


New submission from Jason Yeo:

My university uses python to teach sorting algorithms. It will be great if the turtledemo comes with a visualization of some of the algorithms. I have attached a patch for it.

----------
components: Demos and Tools
files: animation.diff
keywords: patch
messages: 198295
nosy: Jason.Yeo
priority: normal
severity: normal
status: open
title: Add sorting algorithm visualization to turtledemo
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file31845/animation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19075>
_______________________________________

From report at bugs.python.org  Sun Sep 22 20:14:14 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 22 Sep 2013 18:14:14 +0000
Subject: [issue19075] Add sorting algorithm visualization to turtledemo
In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>
Message-ID: <1379873654.96.0.548891304358.issue19075@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19075>
_______________________________________

From report at bugs.python.org  Sun Sep 22 20:17:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Sep 2013 18:17:32 +0000
Subject: [issue19075] Add sorting algorithm visualization to turtledemo
In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>
Message-ID: <1379873852.71.0.629641832451.issue19075@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gregorlingl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19075>
_______________________________________

From report at bugs.python.org  Sun Sep 22 21:13:00 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 22 Sep 2013 19:13:00 +0000
Subject: [issue19047] Assorted weakref docs improvements
In-Reply-To: <1379577834.67.0.113922099701.issue19047@psf.upfronthosting.co.za>
Message-ID: <1379877180.81.0.720621920102.issue19047@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Thanks for the doc cleanup -- I am rather busy right now.

Note that stuff does still get replaced by None at shutdown, and this can still produce errors, even if they are much harder to trigger.  If I run the following program

    import _weakref
    import collections

    a = "hello"

    class Foo(object):
        def __del__(self):
            print(a)

    collections.foo = Foo()
    _weakref.foo = Foo()

then depending on the initial hashseed I get a reproducible error:

    $ PYTHONHASHSEED=7 python-release /tmp/bad.py
    Exception ignored in: <bound method Foo.__del__ of <__main__.Foo object at 0xb733db8c>>
    Traceback (most recent call last):
      File "/tmp/bad.py", line 8, in __del__
    TypeError: 'NoneType' object is not callable

(Personally I would like to see a flag set late during shutdown which blocks __del__ methods from running.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19047>
_______________________________________

From report at bugs.python.org  Sun Sep 22 21:30:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Sep 2013 19:30:08 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379878208.99.0.870367343328.issue18967@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

+lots on ending News Merge Hell. After too many bad experiences, I now avoid pushing non-Idle patches that require a News entry. Even for those who do not mind merge conflicts, there is still the waste of time.

The premise of non-checkout code management is that code expands with the number developers, so merge conflicts should stay rare. Making everyone edit the same few areas of one file subverts this premise.

The switch to hg introduced push races. A merge conflict lengthens the time required to fix things after losing a race. This increases the chance of loosing the race a second time. This has happened to me.

These problems would be worse if there were more active developers, which we need.


Some possible solutions.

1. Get hg to ignore lower context, which is the source of conflicts. The upper context of
==============
Section Title
-------------

==============
is never a problem.

2. Generate news entry from commit message on an *opt-in* basis using a section tag line **Section, where Section is one of Code, Lib, Text, Doc, Idle. Only pay attention to the first letter. Only text before the tag line would go in News. Example commit message:

Issue #12345: fix the bug. This is also the news entry.
Patch by New Contributor
**Lib
Comment for developers only.

This would work for at well over half of existing commits. I consider the elimination of duplication a bonus. A developer who preferred to write an independent News entry still could.

3. I though of separate News.3.3, News.3.4. While this would prevent forward merge conflicts (very helpful), it would not solve within version pull-merge conflicts, as when loosing a push race.

4. I thought of putting adding enough blank lines between header and first entries so that if more blanks were added with entries, the lower context could be 3 blank lines, and hence no conflict. However, when hg does diffs and must choose, it sees upper blank lines as context and lower blank lines as new, whereas the opposite would be needed for this to work. But this choice enables the following idea.

5. Add a new Log file with each entry consisting of a tag line, the entry, and 3 blank lines. If
==========
**Lib
Issue #12345. Fix bug. This is News entry.
Patch by New Contributor



===========
were augmented to
==========
**Lib
Issue #12345. Fix bug. This is News entry.
Patch by New Contributor



**Code
Issue #12348. Add feature. This is another News entry.



=================
the diff would start with three blank lines of context.
===================



**Code
Issue #12348. Add feature. This is another News entry.
+
+
+
==============

6. Have a directory of personal log files, one for each developer, that get periodically merged into news and emptied (or deleted when a release is tagged). The advantage, and only advantage, over a joint log file is not having to enforce the spacing of a joint log file.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Sun Sep 22 21:50:55 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 Sep 2013 19:50:55 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379879455.81.0.596338200849.issue16038@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Okay, this one is quite odd.  It's definitely a timing issue.

If I put a `import time; time.sleep(1)` at the beginning of test_retrlines_too_line() -- i.e. first line of the method -- then the test reliably passes.  If I put a `print(len(line))` just before the maxline test in FTP.retrlines(), then the test will pass just as reliably.

If I put that retrlines() print *after* the maxline test, then it passes sometimes and fails sometimes.  When if fails, it's only ready 12 bytes from the `fp.readline()` call.  When it passes, it's reading 8193 bytes (thus triggering the expected exception).

I really hate to put a sleep in the test to make it pass.  Obviously it would be better not to fudge this race condition, but I don't know the code well enough to know where the race is yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Sep 22 22:03:33 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 Sep 2013 20:03:33 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1379880213.22.0.165135888666.issue16039@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Looks good for 2.6.  The NEWS file hunk doesn't apply, but I'll fix that when I commit this to 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sun Sep 22 23:15:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 21:15:31 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <3cjhJy2vkVz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 4190568ceda0 by Barry Warsaw in branch '2.6':
- Issue #16039: CVE-2013-1752: Change use of readline in imaplib module to
http://hg.python.org/cpython/rev/4190568ceda0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sun Sep 22 23:17:04 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 Sep 2013 21:17:04 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1379884624.17.0.365784601125.issue16039@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Since the merge 2.6 -> 2.7 did not apply cleanly, and had other problems. I null merged the 2.6 changes.  I'll leave it to Benjamin to work out whatever patches 2.7 needs.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sun Sep 22 23:18:23 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Sep 2013 21:18:23 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379884703.07.0.958748357927.issue19074@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Sun Sep 22 23:18:36 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 Sep 2013 21:18:36 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1379884716.16.0.203457894543.issue16042@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Please don't add 2.6 back to the Versions, unless there's actually something to do for 2.6.  AFAIK, this issue is resolved for 2.6.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Sep 22 23:26:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Sep 2013 21:26:05 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1379885165.2.0.524587603628.issue18967@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Even for those who do not mind merge conflicts,
> there is still the waste of time.

If you know what you are doing the waste is minimal.  I sometimes import, check, commit, merge, and push a patch on 3 branches in less than a minute (it was a trivial patch that didn't require to run the test suite), and fixing conflicts in Misc/NEWS is something that can be done in a few seconds, even when the merge goes completely wrong (ctrl+2, ctrl+1, ctrl+s, ctrl+q when it goes right; ctrl+q, hg revert Misc/NEWS, copy/paste the entry when it goes wrong).

If you are trying to figure out how to use a merge tool or understanding why there is a merge conflict, what branches are involved, what should be merged and in what order, what should be committed/reverted/updated, then it will take more time (even more if you get it wrong and you have to start over), but the pattern is always the same once you learn it.

> The switch to hg introduced push races. A merge conflict lengthens
> the time required to fix things after losing a race. This increases
> the chance of loosing the race a second time. This has happened to me.

There are two kind of conflicts:
1) conflicts while merging files between branches on the same machine;
2) conflicts with changesets pushed by other developers;

The first kind is usually trivial to fix (see above).  The second kind (i.e. push race) might indeed be more complex [0], but it can still be solved in less than a minute.  Of course in that minute someone else might push again, but you must be very unlucky (or very slow).

> These problems would be worse if there were more active developers,
> which we need.

Even if we get twice as many active developers, I think push races would still be quite rare since there are usually hours between each push.  Once 2.7 is closed the chances of conflict will further decrease.


> Some possible solutions.

> 1. Get hg to ignore lower context, which is the source of conflicts. 

This could possibly be done with a merge hook (see one of my previous message).  I'm not sure it can be done by ignoring the lower context, but something should be doable.

> 2. Generate news entry from commit message on an *opt-in* basis using
> a section tag line **Section, where Section is one of Code, Lib,
> Text, Doc, Idle.

I'm -1 on adding tags and use them to generate Misc/NEWS.

> 3. I though of separate News.3.3, News.3.4. While this would prevent
> forward merge conflicts (very helpful), it would not solve within
> version pull-merge conflicts, as when loosing a push race.

Also if I fix a bug in 3.3 and 3.4, will I have to add the news manually in two different files?  Now HG does it for me automatically since there's only one file -- having to edit separate files seems like a step backward.
I don't know if creating News.3.4 by using "hg cp" on News.3.3 will automatically add the entry on both, but even if it does it won't probably solve the original problem.

> 4. I thought of putting adding enough blank lines between header and
> first entries so that if more blanks were added with entries, the 
> lower context could be 3 blank lines, and hence no conflict.

This sounds like an hack, and I'm not sure it will work (hg might try to include more context in the diff if there are only empty lines).

> 5. Add a new Log file with each entry consisting of a tag line, the
> entry, and 3 blank lines.

See previous point.

> 6. Have a directory of personal log files, one for each developer,
> that get periodically merged into news and emptied (or deleted when a
> release is tagged). The advantage, and only advantage, over a joint
> log file is not having to enforce the spacing of a joint log file.

IIRC the Twisted devs do something similar, but with a separate file for each NEWS entry.  Something similar was also discussed when this came up on python-dev a few months ago.

[0]: http://docs.python.org/devguide/faq.html#i-got-abort-push-creates-new-remote-heads-while-pushing-what-do-i-do

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________

From report at bugs.python.org  Mon Sep 23 00:08:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Sep 2013 22:08:51 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379887731.1.0.762458782034.issue19074@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Note that we have a somewhat similar HOWTO about using Python in the web: http://docs.python.org/dev/howto/webservers.html
The HOWTO mentions at the top that it can't keep track of all the several web framework and links to the wiki for a more updated page.
The same approach could be followed here too, if we want to keep that page.

----------
assignee: brett.cannon -> docs at python
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Mon Sep 23 00:12:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Sep 2013 22:12:56 +0000
Subject: [issue19074] Add PySide to GUI FAQ
In-Reply-To: <1379859377.69.0.892253164041.issue19074@psf.upfronthosting.co.za>
Message-ID: <1379887976.05.0.318672792927.issue19074@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Actually PySide is mentioned in the 3.x version of the docs.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19074>
_______________________________________

From report at bugs.python.org  Mon Sep 23 00:22:41 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 22 Sep 2013 22:22:41 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379888561.68.0.733157685198.issue19030@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Current patch has a little more code cleanup and a bunch more tests.

I copied and adapted test_property to test_VirtualAttribute, and VirtualAttribute passes every test except the __slots__ test where __doc__ is not supposed to copy.  I think the problem there is that VA is a python object and already has a __doc__ so having __slots__ not show __doc__ doesn't help.  I put a skipIf(hasattr, obj, '__doc__') around that test.

I'm still not crazy about the name VirtualAttribute... oh well.

If no negative feedback by mid-week I'll commit, as I would really like this code to be the next alpha.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 23 00:22:58 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 22 Sep 2013 22:22:58 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1379888578.46.0.124465624566.issue19030@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


Added file: http://bugs.python.org/file31846/issue19030.stoneleaf.04.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 23 01:15:07 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 22 Sep 2013 23:15:07 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <1379891707.33.0.842708660335.issue19025@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, I changed my mind about __delattr__.  Having it say "AttributeError: cannot delete Enum member" is certainly nicer than "AttributeError: MemberName"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Mon Sep 23 01:18:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Sep 2013 23:18:38 +0000
Subject: [issue19025] Deleting attribute of Enum gives misleading error message
In-Reply-To: <1379258110.64.0.0894426931246.issue19025@psf.upfronthosting.co.za>
Message-ID: <3cjl313ctwz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset ed011b0d7daf by Ethan Furman in branch 'default':
Close #19025: Better error message when trying to delete an Enum member.
http://hg.python.org/cpython/rev/ed011b0d7daf

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19025>
_______________________________________

From report at bugs.python.org  Mon Sep 23 02:29:21 2013
From: report at bugs.python.org (Michael Smith)
Date: Mon, 23 Sep 2013 00:29:21 +0000
Subject: [issue19076] Pdb.do_break calls error with obsolete file kwarg
Message-ID: <1379896161.02.0.342769344307.issue19076@psf.upfronthosting.co.za>


New submission from Michael Smith:

Pretty straightforward:

File "/usr/local/Cellar/python3/3.3.2/Frameworks/Python.framework/Versions/3.3/lib/python3.3/pdb.py", line 675, in do_break
    self.error(err, file=self.stdout)
TypeError: error() got an unexpected keyword argument 'file'

Sure enough, line 675 reads:
                self.error(err, file=self.stdout)

but line 448:
    def error(self, msg):

----------
components: Extension Modules
messages: 198309
nosy: Michael.Smith
priority: normal
severity: normal
status: open
title: Pdb.do_break calls error with obsolete file kwarg
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19076>
_______________________________________

From report at bugs.python.org  Mon Sep 23 03:03:06 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 Sep 2013 01:03:06 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <1379898186.47.0.0630671783048.issue19011@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Posted a message on PyDev, but unless I get feedback saying it's a bad idea, or I find some implementation issue, I'll go ahead and make the change.

So either a doc patch or an enum patch will be in alpha3.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Mon Sep 23 03:40:35 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 Sep 2013 01:40:35 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1379900435.27.0.0400873355063.issue19040@psf.upfronthosting.co.za>


Ethan Furman added the comment:

How about this note after the AutoNumber example?

.. note::

    The :meth:`__new__` method, if defined, is used during creation of the Enum
    members; it is then replaced by Enum's :meth:`__new__` which is used after
    class creation for lookup of existing members.  Due to the way Enums are
    supposed to behave, there is no way to customize Enum's :meth:`__new__`.

----------
nosy: +barry, eli.bendersky
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Mon Sep 23 04:26:49 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 23 Sep 2013 02:26:49 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1379903209.43.0.995025952468.issue19040@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

LGTM, Ethan. You know how I feel about customization in general ;-) We should give Enum a term or two in the stdlib to learn how it's being used and abused - we can always *add* customization in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Mon Sep 23 05:19:49 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Sep 2013 03:19:49 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379888579.05.0.310618062998.issue19030@psf.upfronthosting.co.za>
Message-ID: <CADiSq7emAEn9CmL59qRwMZ-2v=gufMVMLLVF7fq2AYGigpqUtg@mail.gmail.com>


Nick Coghlan added the comment:

I suggest DynamicClassAttribute for the descriptor name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Mon Sep 23 06:04:06 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 Sep 2013 04:04:06 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1379909046.99.0.844905213611.issue19040@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Yup, just trying to add some explanation on how it currently works.

Drekin, I'm sure you've already figured this out, but for those who may read this in the future:  what you need is a helper function:

def OptionalEnum(value):
    "could also be OptionalEnum(enum, value)"
    try:
        return SomeEnum(value) # or return enum(value)
    except ValueError:
        return value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Mon Sep 23 06:39:19 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Sep 2013 04:39:19 +0000
Subject: [issue19076] Pdb.do_break calls error with obsolete file kwarg
In-Reply-To: <1379896161.02.0.342769344307.issue19076@psf.upfronthosting.co.za>
Message-ID: <1379911159.85.0.0134887737274.issue19076@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib)
nosy: +berker.peksag, georg.brandl
stage:  -> needs patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19076>
_______________________________________

From report at bugs.python.org  Mon Sep 23 09:37:05 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 23 Sep 2013 07:37:05 +0000
Subject: [issue13404] Add support for system.methodSignature() to XMLRPC Server
In-Reply-To: <1321292022.85.0.26720578121.issue13404@psf.upfronthosting.co.za>
Message-ID: <1379921825.09.0.204637855254.issue13404@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

> How do you infer the data types for the parameters?

I don't think we can, unless we force them to use function annotation. If they don't use that feature, then we say the signature is not supported.

The problem is getting deeper if we are talking about return value type.

if a == 1:
  return 'spam'
else:
  return 3.14

I therefore embrace the dynamic nature of Python with this patch.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31847/add_method_signature_to_xmlrpc_server.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13404>
_______________________________________

From report at bugs.python.org  Mon Sep 23 09:53:49 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Sep 2013 07:53:49 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1379922829.87.0.540539375466.issue11380@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It seems this can be triggered easily with echo, since that appears to reliably close stdin on startup (Discovered via http://stackoverflow.com/questions/16314321).

Compare (using a recent trunk build, although I see the same behaviour with the system 3.3 installation):

$ ../py3k/python -c 'print("Hello world!")' | echo

Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

$ ../py3k/python -c 'print("Hello world!")' | xargs echo
Hello world!

$ ../py3k/python -c 'print("Hello world!")' | cat
Hello world!

Given that flush/close related exceptions are automatically ignored in destructors, something else must be going on here.

It turns out that the *explicit* flush calls during interpreter finalization use PyErr_WriteUnraisable on failure to flush stdout instead of silently ignoring the exceptions (http://hg.python.org/cpython/file/ed011b0d7daf/Python/pythonrun.c#l457).

This is reasonable, since a broken pipeline *is* an error that the user may need to do something about (e.g. as with echo, they next pipeline stage may not being invoked correctly, thus breaking the pipe)

However, in the specific case of a broken pipe, I believe it is desirable for us to write out a cleaner message than the generic PyErr_WriteUnraisable output.

----------
nosy: +ncoghlan, pitrou
title: "close failed in file object destructor" when "Broken pipe" happens on stdout -> Improve reporting of broken stdout pipe during interpreter shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Mon Sep 23 10:04:07 2013
From: report at bugs.python.org (Drekin)
Date: Mon, 23 Sep 2013 08:04:07 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1379923447.24.0.5239522334.issue19040@psf.upfronthosting.co.za>


Drekin added the comment:

Yes, I've done it similarily using a class method. Thank you for help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Mon Sep 23 10:06:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Sep 2013 08:06:50 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1379923610.25.0.176354587394.issue1185124@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+        except:
+            pass
...
+    except TypeError:
+        return None

I don't understand these try/except. First, "except: pass" must never be used, only catch specific exceptions (ex: AttributeError). Can you explain why you expect a TypeError?

If your patch fixes a bug, you must add a new unit test to test_pydoc to check for non-regression.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Mon Sep 23 12:28:02 2013
From: report at bugs.python.org (Mark Egan-Fuller)
Date: Mon, 23 Sep 2013 10:28:02 +0000
Subject: [issue17777] Unrecognized string literal escape sequences give
 SyntaxErrors
In-Reply-To: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>
Message-ID: <1379932082.55.0.506081911596.issue17777@psf.upfronthosting.co.za>


Mark Egan-Fuller added the comment:

Python correctly throws a unicode error here, directing the user towards the fact that this is an issue specifically with the unicode escaping.

>>> "\u"
  File "<stdin>", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 0-1: truncated \uXXXX escape


The documentation also states that "Any Unicode character can be encoded this way. Exactly eight hex digits are required."[0].

Propose closing this as Won't Fix.

[0]: http://docs.python.org/3/reference/lexical_analysis.html#literals

----------
nosy: +markeganfuller, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17777>
_______________________________________

From report at bugs.python.org  Mon Sep 23 15:57:27 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 23 Sep 2013 13:57:27 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379909046.99.0.844905213611.issue19040@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9m2B5rQsJVp=m2cdjqUY44POks3OAq2NTuB1X8=eXQAg@mail.gmail.com>


Eli Bendersky added the comment:

On Sun, Sep 22, 2013 at 9:04 PM, Ethan Furman <report at bugs.python.org>wrote:

>
> Ethan Furman added the comment:
>
> Yup, just trying to add some explanation on how it currently works.
>
> Drekin, I'm sure you've already figured this out, but for those who may
> read this in the future:  what you need is a helper function:
>
> def OptionalEnum(value):
>     "could also be OptionalEnum(enum, value)"
>     try:
>         return SomeEnum(value) # or return enum(value)
>     except ValueError:
>         return value
>

Hmm, looks suspiciously similar to _inienum_converter from socket.py ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Mon Sep 23 16:58:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 14:58:46 +0000
Subject: [issue19077] More robust TemporaryDirectory cleanup
Message-ID: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch solves the problem with TemporaryDirectory cleanup. If shutil.rmtree() failed because module globals are set to None, TemporaryDirectory now uses own rmtree implementation which does not depends from globals. The patch also fixes other minor problems related to __del__ and fixes do_create() in tests (it deleted subdirectories just after creation).

See also issue10188.

----------
components: Library (Lib)
files: tempfile_tempdir_cleanup.patch
keywords: patch
messages: 198321
nosy: georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: More robust TemporaryDirectory cleanup
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31848/tempfile_tempdir_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19077>
_______________________________________

From report at bugs.python.org  Mon Sep 23 17:03:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 15:03:07 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379948587.58.0.377686752871.issue12085@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. It fixes also other issues with globals nullification (similar to issue19021).

----------
Added file: http://bugs.python.org/file31849/subprocess_del.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Mon Sep 23 17:36:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 15:36:00 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379950560.11.0.218810433422.issue16038@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about time.sleep(0.1)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Sep 23 17:37:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 15:37:44 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379950664.43.0.939330591389.issue16038@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +josiahcarlson, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Sep 23 18:27:16 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 23 Sep 2013 16:27:16 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview[::-1]
Message-ID: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello. The following seems a little weird:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32
>>> m = memoryview(b'123')
>>> list(m[::-1])
[51, 50, 49]
>>> list(reversed(m))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object of type 'memoryview' has no len()
>>>

The attached patch allows `reversed` to be called with memoryviews and it could potentially fix issue18690.

----------
components: Interpreter Core
files: memoryview.patch
keywords: patch
messages: 198324
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Allow reversed(memoryview), like memoryview[::-1]
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31850/memoryview.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Mon Sep 23 18:32:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 16:32:33 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview[::-1]
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1379953953.16.0.862746349868.issue19078@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Mon Sep 23 18:49:30 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 23 Sep 2013 16:49:30 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1379950560.11.0.218810433422.issue16038@psf.upfronthosting.co.za>
Message-ID: <20130923124929.65cf74d2@anarchist>


Barry A. Warsaw added the comment:

On Sep 23, 2013, at 03:36 PM, Serhiy Storchaka wrote:

>What about time.sleep(0.1)?

I usually don't like introducing sleeps to fix race conditions, but if that's
the only option for landing this patch, maybe we'll have to hold our noses and
do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Sep 23 19:44:30 2013
From: report at bugs.python.org (pmoody)
Date: Mon, 23 Sep 2013 17:44:30 +0000
Subject: [issue17400] ipaddress should make it easy to identify rfc6598
 addresses
In-Reply-To: <1363052217.02.0.113831391012.issue17400@psf.upfronthosting.co.za>
Message-ID: <1379958270.23.0.149647365497.issue17400@psf.upfronthosting.co.za>


pmoody added the comment:

ok, here's an is_global/is_private patch using the iana special registry for ipv4 and ipv6.

----------
keywords: +patch
Added file: http://bugs.python.org/file31851/issue.17400.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17400>
_______________________________________

From report at bugs.python.org  Mon Sep 23 20:33:27 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 23 Sep 2013 18:33:27 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1379961207.47.0.54024434017.issue16038@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Barry can you paste the traceback caused by the race condition? What's not clear to me is when (what line) it occurs.
One solution might be to send a "NOOP" command (self.client.sendcmd('noop')) in order to synchronize client and server.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Mon Sep 23 21:37:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Sep 2013 19:37:18 +0000
Subject: [issue19064] can't run py3 benchmarks
In-Reply-To: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>
Message-ID: <3ckG593KjLz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 88b6ef9aa9e9 by Antoine Pitrou in branch 'default':
Issue #19064: let perf.py decide which library path is required for which interpreter
http://hg.python.org/benchmarks/rev/88b6ef9aa9e9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19064>
_______________________________________

From report at bugs.python.org  Mon Sep 23 21:37:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 19:37:56 +0000
Subject: [issue19064] can't run py3 benchmarks
In-Reply-To: <1379797542.04.0.297069856882.issue19064@psf.upfronthosting.co.za>
Message-ID: <1379965076.92.0.00509724943155.issue19064@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Now done.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19064>
_______________________________________

From report at bugs.python.org  Mon Sep 23 21:42:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 19:42:22 +0000
Subject: [issue19079] chameleon benchmark fails on 3.4
Message-ID: <1379965342.66.0.0193650788884.issue19079@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Not sure what to do about this, but it seems the bundled Chameleon lib doesn't work on 3.4:

RuntimeError: Benchmark died: Traceback (most recent call last):
  File "./performance/bm_chameleon.py", line 38, in <module>
    util.run_benchmark(options, options.num_runs, main)
  File "/home/antoine/cpython/benchmarks/performance/util.py", line 30, in run_benchmark
    data = bench_func(num_runs, *args)
  File "./performance/bm_chameleon.py", line 19, in main
    tmpl = PageTemplate(BIGTABLE_ZPT)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/zpt/template.py", line 163, in __init__
    super(PageTemplate, self).__init__(body, **config)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 117, in __init__
    self.write(body)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 208, in write
    self.cook(body)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 147, in cook
    program = self._cook(body, digest, names)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 218, in _cook
    source = self._make(body, builtins)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 251, in _make
    return self._compile(module, builtins)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/template.py", line 245, in _compile
    compiler = Compiler(self.engine, program, builtins, strict=self.strict)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/compiler.py", line 886, in __init__
    generator = TemplateCodeGenerator(module)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 107, in __init__
    super(TemplateCodeGenerator, self).__init__(tree)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 172, in __init__
    self.visit(tree)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 110, in visit_Module
    super(TemplateCodeGenerator, self).visit_Module(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 239, in visit_Module
    self.visit(n)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 290, in visit_FunctionDef
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 290, in visit_FunctionDef
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 371, in visit_For
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 371, in visit_For
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 458, in visit_Try
    self.visit(statement)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 403, in visit_If
    self.visit(node.test)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 232, in visit
    ret = visitor(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 621, in _f
    f(self, node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 763, in visit_Compare
    self.visit(comparator)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/codegen.py", line 192, in visit
    super(TemplateCodeGenerator, self).visit(node)
  File "/home/antoine/cpython/benchmarks/lib3/Chameleon-2.9.2/src/chameleon/astutil.py", line 231, in visit
    node.__class__.__name__, repr(node)))
Exception: No handler for ``NameConstant`` (<_ast.NameConstant object at 0x7f4a6a733dd8>).

----------
components: Benchmarks
messages: 198330
nosy: brett.cannon, pitrou
priority: normal
severity: normal
status: open
title: chameleon benchmark fails on 3.4
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19079>
_______________________________________

From report at bugs.python.org  Mon Sep 23 21:49:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Sep 2013 19:49:23 +0000
Subject: [issue19034] More useful repr for Tcl_Obj
In-Reply-To: <1379321252.25.0.835083719717.issue19034@psf.upfronthosting.co.za>
Message-ID: <3ckGM665Glz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset ece634a69ba8 by Serhiy Storchaka in branch 'default':
Issue #19034: repr() for tkinter.Tcl_Obj now exposes string reperesentation.
http://hg.python.org/cpython/rev/ece634a69ba8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19034>
_______________________________________

From report at bugs.python.org  Mon Sep 23 21:58:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 19:58:24 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1379966304.03.0.500286721025.issue11380@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm not sure I understand Nick's suggestion. As far as I can tell, the issue is to detect that write() (really fwrite() in 2.x) failed and output the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:05:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 23 Sep 2013 20:05:26 +0000
Subject: [issue12085] subprocess.Popen.__del__ raises AttributeError if
 __init__ was called with an invalid argument list
In-Reply-To: <1305515335.66.0.95766532071.issue12085@psf.upfronthosting.co.za>
Message-ID: <1379966726.42.0.724213755761.issue12085@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

def _handle_exitstatus(self, sts, _WIFSIGNALED=os.WIFSIGNALED,
                 _WTERMSIG=os.WTERMSIG, _WIFEXITED=os.WIFEXITED,
-                _WEXITSTATUS=os.WEXITSTATUS):
+                _WEXITSTATUS=os.WEXITSTATUS, _SubprocessError=SubprocessError):
             # This method is called (indirectly) by __del__, so it cannot
             # refer to anything outside of its local scope."""

The non-effective """ should be removed. Otherwise LFTM.
Good catch on the non-local dependencies that violated the comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12085>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:07:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Sep 2013 20:07:16 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <3ckGll5tT0zNwF@mail.python.org>


Roundup Robot added the comment:

New changeset 5bb83faa8818 by Serhiy Storchaka in branch 'default':
Issue #18996: TestCase.assertEqual() now more cleverly shorten differing
http://hg.python.org/cpython/rev/5bb83faa8818

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:08:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 20:08:13 +0000
Subject: [issue19034] More useful repr for Tcl_Obj
In-Reply-To: <1379321252.25.0.835083719717.issue19034@psf.upfronthosting.co.za>
Message-ID: <1379966893.03.0.0610104576185.issue19034@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19034>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:08:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 20:08:37 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1379966917.96.0.369792265458.issue18996@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:11:36 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Sep 2013 20:11:36 +0000
Subject: [issue19079] chameleon benchmark fails on 3.4
In-Reply-To: <1379965342.66.0.0193650788884.issue19079@psf.upfronthosting.co.za>
Message-ID: <1379967096.83.0.878816860635.issue19079@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I guess either we introduce compatible version ranges or drop Chameleon from 3.x compatibility and then add a new version of Chameleon if/when they update for Python 3.4 support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19079>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:26:05 2013
From: report at bugs.python.org (paul j3)
Date: Mon, 23 Sep 2013 20:26:05 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
Message-ID: <1379967965.01.0.793803450656.issue13824@psf.upfronthosting.co.za>


paul j3 added the comment:

In this patch I implement a FileContext class.  It differs from FileType
in 2 key areas:

- it returns a 'partial(open, filename, ...)'
- it wraps '-' (stdin/out) in a dummy context protecting the file from closure.

The resulting argument is meant to be used as:

    with args.input() as f:
        f.read()
        etc

The file is not opened until value is called, and it will be closed after the block.  stdin/out can also be used in this context, but without closing.

The signature for this class is the same as for FileType, with one added parameter, 'style'. (alternative name suggestions welcomed).

class argparse.FileContext(mode='r', bufsize=-1, encoding=None, errors=None, style='delayed')

The default behavior, "style='delayed'", is as described above.

"style='evaluate'" immediately calls the partial, returning an opened file.  This is essentially the same as FileType, except for the stdin/out context wrapping.

"style='osaccess'", adds os.acccess testing to determine whether the 'delayed' file can be read or written.  It attempts to catch the same sort of OS errors that  FileType would, but without actually opening or creating the file.

Most of the added tests in test_argparse.py copy the FileType tests.  I had to make some modifications to the testing framework to handle the
added levels of indirection.

I have not written the documentation changes yet.

A sample use case is:

    import argparse, sys
    p = argparse.ArgumentParser()
    p.add_argument('-d','--delayed', type=argparse.FileContext('r'))
    p.add_argument('-e','--evaluated', type=argparse.FileContext('r', style='evaluate'))
    p.add_argument('-t','--test', dest='delayed', type=argparse.FileContext('r', style='osaccess'))
    p.add_argument('-o','--output', type=argparse.FileContext('w', style='osaccess'), default='-')
    p.add_argument('--unused', type=argparse.FileContext('w', style='osaccess'),help='unused write file')
    args = p.parse_args()

    with args.output() as o:
        if args.delayed:
            with args.delayed() as f:
                print(f.read(), file=o)
        if args.evaluated:
            with args.evaluated as f:
                print(f.read(), file=o)
    # f and o will be closed if regular files
    # but not if stdin/out
    # the file referenced by args.unused will not be created

----------
keywords: +patch
Added file: http://bugs.python.org/file31852/patch_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13824>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:26:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Sep 2013 20:26:11 +0000
Subject: [issue19028] tkinter.tkapp.merge() fails on non-strings
In-Reply-To: <1379278268.95.0.270517014711.issue19028@psf.upfronthosting.co.za>
Message-ID: <3ckH9Z4mmKz7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 5c1c67d980bb by Serhiy Storchaka in branch '3.3':
Issue #19028: Fixed tkinter.Tkapp.merge() for non-string arguments.
http://hg.python.org/cpython/rev/5c1c67d980bb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19028>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:26:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 20:26:11 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1379967971.75.0.046534003865.issue11380@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, actually, the real issue is that sys.stderr is gone by the time we try to print the exception (which explains the "lost sys.stderr" message).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:28:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 20:28:21 +0000
Subject: [issue19028] tkinter.tkapp.merge() fails on non-strings
In-Reply-To: <1379278268.95.0.270517014711.issue19028@psf.upfronthosting.co.za>
Message-ID: <1379968101.06.0.431084902735.issue19028@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19028>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:31:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 20:31:07 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1299115966.12.0.337666295395.issue11380@psf.upfronthosting.co.za>
Message-ID: <1379968267.78.0.612738621232.issue11380@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch, lacking tests.
How important it is to fix this in 2.7 I'm not sure. People are certainly used to the quirk now, and it's generally harmless.

----------
keywords: +patch
Added file: http://bugs.python.org/file31853/flush_stdout_at_shutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:37:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 20:37:56 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1379968676.35.0.12890378419.issue4366@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Koobs, have you signed a contributor's agreement?
See http://www.python.org/psf/contrib/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:42:05 2013
From: report at bugs.python.org (alon horev)
Date: Mon, 23 Sep 2013 20:42:05 +0000
Subject: [issue19080] Enrich SyntaxError with additional information
Message-ID: <1379968925.72.0.669299760684.issue19080@psf.upfronthosting.co.za>


New submission from alon horev:

Some context for this feature request:
I'm using the wonderful ast module for a library that translates python code to MongoDB queries (https://github.com/alonho/pql). I also did the same for SQL queries using sqlalchemy as a part of another project (https://github.com/alonho/pytrace).

One of the things I find lacking in python's parser is additional information about SyntaxErrors. This could help users of the 'ast' module, IDE and developers.

Here are some examples of what I'd like to see
1. ast.parse('* 2') -> SyntaxError('Unexpected operator at start of an expression')
2. ast.parse('2 *') -> SyntaxError('Missing right hand side operand')
3. ast.parse('if a = 1: pass') -> SyntaxError('Cannot assign inside an expression')

There are several challenges here:
1. Does the parser have this information and doesn't surface it?
2. Can such messages be automatically generated without filling the code with error handling code? 3. Which part of the code could be responsible for this kind of a task? I've looked at the BNF and it contains more than just syntax legality but operator precedence and such. Perhaps there's another (simpler) grammar definition somewhere?

I was curious to see what Ruby does, and it uses a simple solution of providing raw information along with the exception:
>> a == * 1
SyntaxError: compile error
(irb):17: syntax error, unexpected tSTAR
a == * 1
      ^
	from (irb):17

----------
components: Interpreter Core
messages: 198341
nosy: alonho
priority: normal
severity: normal
status: open
title: Enrich SyntaxError with additional information
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19080>
_______________________________________

From report at bugs.python.org  Mon Sep 23 22:52:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 20:52:18 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview[::-1]
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1379969538.26.0.343286781974.issue19078@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

So the dilemma with len() was: does it return the number of bytes, or the number of items?
Given the new memoryview semantics, I'd say it should return the number of items.

----------
nosy: +ncoghlan, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Mon Sep 23 23:31:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Sep 2013 21:31:34 +0000
Subject: [issue18682] [PATCH] remove bogus codepath from pprint._safe_repr
In-Reply-To: <1375950566.41.0.226660086473.issue18682@psf.upfronthosting.co.za>
Message-ID: <1379971894.06.0.659881794431.issue18682@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

To made some sense in Python 3 context we should remove the check for the locale module and replace repr() by ascii().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18682>
_______________________________________

From report at bugs.python.org  Tue Sep 24 00:03:15 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 23 Sep 2013 22:03:15 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1379961207.47.0.54024434017.issue16038@psf.upfronthosting.co.za>
Message-ID: <20130923175708.4b84ad85@anarchist>


Barry A. Warsaw added the comment:

On Sep 23, 2013, at 06:33 PM, Giampaolo Rodola' wrote:

>Barry can you paste the traceback caused by the race condition? What's not
>clear to me is when (what line) it occurs.  One solution might be to send a
>"NOOP" command (self.client.sendcmd('noop')) in order to synchronize client
>and server.

There's no traceback other than the test failure that I posted.  It's a race
condition because with a little sleep, the test passes.  Without it, it fails.

This is on various flavors of Ubuntu (only up to 10.04 which is the last
version I can build a full 2.6 against) and Debian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Tue Sep 24 01:03:21 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Sep 2013 23:03:21 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1379966304.03.0.500286721025.issue11380@psf.upfronthosting.co.za>
Message-ID: <CADiSq7efGYQgeetgrfuzcCg-L9vDsGocVObJtbLcStj6qFBg9g@mail.gmail.com>


Nick Coghlan added the comment:

My specific suggestion was aimed at 3.4 - I think reporting the failure to
flush stdout on stderr is the right thing to do (since data may have been
lost and people can suppress it by closing stdout early, including in an
atexit handler), but I also think it's worth improving the error message in
the specific case of a broken pipe error.

However, I also agree the error output is more wrong in 2.7, so improving
that would be good, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Tue Sep 24 01:05:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 23:05:10 +0000
Subject: [issue19079] chameleon benchmark fails on 3.4
In-Reply-To: <1379965342.66.0.0193650788884.issue19079@psf.upfronthosting.co.za>
Message-ID: <1379977510.2.0.911063969226.issue19079@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I guess version ranges could be feasible. Perhaps with benchmark-skipping decorators?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19079>
_______________________________________

From report at bugs.python.org  Tue Sep 24 01:05:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Sep 2013 23:05:56 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <CADiSq7efGYQgeetgrfuzcCg-L9vDsGocVObJtbLcStj6qFBg9g@mail.gmail.com>
Message-ID: <1379977553.2494.8.camel@fsol>


Antoine Pitrou added the comment:

> My specific suggestion was aimed at 3.4 - I think reporting the failure to
> flush stdout on stderr is the right thing to do (since data may have been
> lost and people can suppress it by closing stdout early, including in an
> atexit handler), but I also think it's worth improving the error message in
> the specific case of a broken pipe error.

How would you improve it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Tue Sep 24 01:08:42 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Sep 2013 23:08:42 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379969538.26.0.343286781974.issue19078@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fn-iovqmo=WReDpXi3E0T9B=uDvGVeypbj=rFX25GZAA@mail.gmail.com>


Nick Coghlan added the comment:

Aye, with the 3.3 changes, I think we should continue down the
multi-dimensional array path. I suggest we run with whatever NumPy uses for
ndarray, which I believe is "number of items in the first dimension".

----------
title: Allow reversed(memoryview), like memoryview[::-1] -> Allow reversed(memoryview), like memoryview

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Tue Sep 24 01:12:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Sep 2013 23:12:32 +0000
Subject: [issue11380] Improve reporting of broken stdout pipe during
 interpreter shutdown
In-Reply-To: <1379977553.2494.8.camel@fsol>
Message-ID: <CADiSq7e1=usutKyobwyTJM9CdLf6FKyO8i00YRmDwrSwy34u2Q@mail.gmail.com>


Nick Coghlan added the comment:

Suppress the traceback, avoid printing the exception repr and instead
display something more like "Broken pipe: receiving end of stdout closed
prior to interpreter shutdown"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11380>
_______________________________________

From report at bugs.python.org  Tue Sep 24 04:55:35 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Tue, 24 Sep 2013 02:55:35 +0000
Subject: [issue11176] give more meaningful argument names in argparse
 documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1379991335.35.0.980357411345.issue11176@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

I've skimmed through the patches.  Good job kids.  This is much better than it was before.  No more of that silly command-line calculator or the foobar nonsense that sounds drier than the POSIX standard.

Is there anything else that needs to be done?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11176>
_______________________________________

From report at bugs.python.org  Tue Sep 24 06:00:03 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 24 Sep 2013 04:00:03 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
Message-ID: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

If you are

1) using zipimport
2) zipimport.c has cached the zip file's central index during an import.
3) the .zip file is modified or replaced while the process is running
4) you try to import something new from that .zip file.

you're gonna have a bad time... Typically a ZipImportError or some other form of ImportError.

What happen's is that Modules/zipimport.c is caching the end-of-zipfile central index for the .zip file and reusing that data on subsequent imports from that .zip without either (a) keeping the file handle open or (b) confirming that the .zip file has not changed.

I doubt many users are running into this.  But one situation where you do is when you zip up the Python standard library for your installed python and a long running process encounters data using a different encoding which triggers an import of an encodings.foo module after another process has come along and upgraded the standard library .zip file as part of updating your python installation...

I've got a fix in the works.  Test attached.

For the fix I am going with option (b) to reconfirm the validity of the .zip file any time something is imported from it rather than option (a) as leaving a new file handle open for the duration of the process, while the _correct ideal design_ seems intrusive for stable bug fix release.

I have only confirmed the bug on Python 2.7 & 3.3; i'll test default (3.4) after working on those two.

----------
assignee: gregory.p.smith
files: zipimport_modify_zip_test.patch
keywords: patch
messages: 198351
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: zipimport behaves badly when the zip file changes while the process is running
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31854/zipimport_modify_zip_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Tue Sep 24 08:49:56 2013
From: report at bugs.python.org (Connor Osborn)
Date: Tue, 24 Sep 2013 06:49:56 +0000
Subject: [issue18764] The pdb print command prints repr instead of str in
 python3
In-Reply-To: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>
Message-ID: <1380005396.93.0.322839502786.issue18764@psf.upfronthosting.co.za>


Connor Osborn added the comment:

In 2.7 there is no documented command *print, the docs are explicit on this (it's just the built in statement). However, 3.4 treats print like a feature of 2.7. Is this to maintain backwards compatibility? I would suggest preserving the original direction of the pdb, where a user has access to a p command but a user can always use the built in python print function.

in short:
-remove print from documented commands
-remove print alias

*This is my first patch :P Let me know if this is the correct direction, and what needs to be changed for acceptance, thanks.

----------
keywords: +patch
Added file: http://bugs.python.org/file31855/18764.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18764>
_______________________________________

From report at bugs.python.org  Tue Sep 24 12:01:14 2013
From: report at bugs.python.org (Tim Golden)
Date: Tue, 24 Sep 2013 10:01:14 +0000
Subject: [issue17777] Unrecognized string literal escape sequences give
 SyntaxErrors
In-Reply-To: <1366213055.37.0.161368185198.issue17777@psf.upfronthosting.co.za>
Message-ID: <1380016874.7.0.58090376897.issue17777@psf.upfronthosting.co.za>


Tim Golden added the comment:

Closing as "Works for me" in the absence of any clear proposal for docs improvement.

----------
resolution:  -> works for me
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17777>
_______________________________________

From report at bugs.python.org  Tue Sep 24 14:07:07 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 Sep 2013 12:07:07 +0000
Subject: [issue19079] chameleon benchmark fails on 3.4
In-Reply-To: <1379965342.66.0.0193650788884.issue19079@psf.upfronthosting.co.za>
Message-ID: <1380024427.54.0.482020845927.issue19079@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Decorator sounds reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19079>
_______________________________________

From report at bugs.python.org  Tue Sep 24 14:07:32 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 Sep 2013 12:07:32 +0000
Subject: [issue19079] chameleon benchmark fails on 3.4
In-Reply-To: <1379965342.66.0.0193650788884.issue19079@psf.upfronthosting.co.za>
Message-ID: <1380024452.76.0.277309749308.issue19079@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Actually, one perk of the ranges is 2n3 can be auto-calculated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19079>
_______________________________________

From report at bugs.python.org  Tue Sep 24 15:12:08 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 24 Sep 2013 13:12:08 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1380028328.22.0.956499669473.issue16038@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I believe the problem is the set of next_retr_data attribute here:

    def test_retrlines_too_long(self):
        self.server.handler.next_retr_data = 'x' * self.client.maxline * 2

...because self.server.handler runs in a different thread (different than the main one, which is where the setattr() occurs).
We should introduce a new command in the dummy FTP server which sets next_retr_data from within the server thread itself. Will try to work on a patch later this week (I'm sorry but I can't make it earlier).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Tue Sep 24 15:30:55 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 24 Sep 2013 13:30:55 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1380028328.22.0.956499669473.issue16038@psf.upfronthosting.co.za>
Message-ID: <20130924093056.4fb5d265@anarchist>


Barry A. Warsaw added the comment:

On Sep 24, 2013, at 01:12 PM, Giampaolo Rodola' wrote:

>Giampaolo Rodola' added the comment:
>
>I believe the problem is the set of next_retr_data attribute here:
>
>    def test_retrlines_too_long(self):
>        self.server.handler.next_retr_data = 'x' * self.client.maxline * 2
>
>...because self.server.handler runs in a different thread (different than the
>main one, which is where the setattr() occurs).  We should introduce a new
>command in the dummy FTP server which sets next_retr_data from within the
>server thread itself. Will try to work on a patch later this week (I'm sorry
>but I can't make it earlier).

+1 - that explanation makes a lot of sense, thanks!

Currently 2.6.9rc1 is planned for Monday 30-September.  It would be nice to
get this one in before then, but if not that's okay.  I think it's fairly low
risk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Tue Sep 24 16:07:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Sep 2013 14:07:22 +0000
Subject: [issue18764] The pdb print command prints repr instead of str in
 python3
In-Reply-To: <1376694990.04.0.946395407142.issue18764@psf.upfronthosting.co.za>
Message-ID: <1380031642.75.0.250218320935.issue18764@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

This seems like a mistake in the python3 port to me.  I'm in favor of fixing it as a bug.  As release manager and pdb expert, what do you think, Georg?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18764>
_______________________________________

From report at bugs.python.org  Tue Sep 24 16:48:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 24 Sep 2013 14:48:46 +0000
Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server
Message-ID: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Lib/xmlrpc/client.py tries to connect to http://time.xmlrpc.com/RPC2 which has been dead for a "while". I see there is no light in the end of tunnel. Since this code is meant to be a demo not a general purpose tool, I say why don't we direct it to localhost (which can be provided by Lib/xmlrpc/server.py).

After applying this patch, you can start the server:
$ python Lib/xmlrpc/server.py
Serving XML-RPC on localhost port 8000

Then in another place, you can start the client and get result straight away:
$ python Lib/xmlrpc/client.py
2013-09-24T22:35:27
2013-09-24T22:35:27
512
3

Isn't that beautiful?

----------
components: Library (Lib)
files: xmlrpc_server_client_demo.patch
keywords: patch
messages: 198359
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Lib/xmlrpc/client.py demo code points to the dead server
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31856/xmlrpc_server_client_demo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19082>
_______________________________________

From report at bugs.python.org  Tue Sep 24 16:50:35 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 24 Sep 2013 14:50:35 +0000
Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server
In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>
Message-ID: <1380034235.3.0.837642417387.issue19082@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file31856/xmlrpc_server_client_demo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19082>
_______________________________________

From report at bugs.python.org  Tue Sep 24 16:51:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 24 Sep 2013 14:51:08 +0000
Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server
In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>
Message-ID: <1380034268.07.0.918507203572.issue19082@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file31857/xmlrpc_server_client_demo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19082>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:20:51 2013
From: report at bugs.python.org (Pepijn de Vos)
Date: Tue, 24 Sep 2013 15:20:51 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
Message-ID: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>


New submission from Pepijn de Vos:

RFC 3490 states that "The ACE prefix for IDNA is "xn--" or any capitalization thereof."

But the following does not work

>>> str(b"XN--pythn-mua.org.", "idna")

----------
components: Library (Lib)
files: upper-idna.patch
keywords: patch
messages: 198360
nosy: Pepijn.de.Vos
priority: normal
severity: normal
status: open
title: IDNA prefix should be case insensitive
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file31858/upper-idna.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:24:54 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Sep 2013 15:24:54 +0000
Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server
In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>
Message-ID: <1380036294.09.0.409588888232.issue19082@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure :)

If you want some bonus points, can you figure out whether or not the test in test_xmlrpc_net is worth moving to test_xmlrpc using a similar local-server approach, or if it is redundant and should just be deleted?

(time.xmlrcp.com has come and gone multiple times over the years...)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19082>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:32:28 2013
From: report at bugs.python.org (Karl Palsson)
Date: Tue, 24 Sep 2013 15:32:28 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
Message-ID: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>


New submission from Karl Palsson:

OpenSSL supports TLS-PSK which some people (myself obviously) find to be substantially easier to use than setting up certs.

However, there's no way to use PSK via the current SSL api in python.  It would be very nice to be able to use PSK from python.

For OpenSSL, even the C API is particularly easy.  Attached is the implementation used in Mosquitto, a MQTT message broker that supports both cert based and PSK based TLS.

----------
components: Library (Lib)
files: 5bcfpEKD.txt
messages: 198362
nosy: karlp
priority: normal
severity: normal
status: open
title: No way to use TLS-PSK from python ssl
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file31859/5bcfpEKD.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:34:29 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 24 Sep 2013 15:34:29 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1380036869.21.0.480524002993.issue19081@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Here's a fix (the test is now in the patch).

----------
keywords: +needs review
stage:  -> patch review
Added file: http://bugs.python.org/file31860/issue19081-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:36:39 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 24 Sep 2013 15:36:39 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>
Message-ID: <1380036999.85.0.555021121316.issue19084@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:42:50 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 24 Sep 2013 15:42:50 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>
Message-ID: <1380037370.03.0.612507129824.issue19084@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Python 2.7 is open only for bugfixes. No new features.

Do you dare to write a patch for Python 3.4? :-). If you do, remember to sign a Contributor Agreement.

Give it a try! :)

----------
nosy: +jcea
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Tue Sep 24 17:47:23 2013
From: report at bugs.python.org (Roger Light)
Date: Tue, 24 Sep 2013 15:47:23 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>
Message-ID: <1380037643.88.0.425092654375.issue19084@psf.upfronthosting.co.za>


Changes by Roger Light <roger at atchoo.org>:


----------
nosy: +ralight

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Tue Sep 24 19:21:29 2013
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 24 Sep 2013 17:21:29 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1380043289.66.0.262692890046.issue19081@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Tue Sep 24 19:57:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Sep 2013 17:57:53 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>
Message-ID: <1380045473.79.0.35683307626.issue19084@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is it different from TLS SRP, which already has a feature request in issue11943?
As Jesus said, feel free to propose a patch, even a proof of concept so that we start discussing the API.

----------
nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou
stage:  -> needs patch
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Tue Sep 24 22:30:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Sep 2013 20:30:33 +0000
Subject: [issue19085] Add tkinter basic options tests
Message-ID: <1380054632.03.0.105033569087.issue19085@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds tests for all options of all widgets. They test that widgets support all documented options, accepts valid values in different formats, reject invalid values, and return values in expected format. This would be helpful for regression testing.

The patch tested with Tcl/Tk 8.5 and 8.6 on Linux. All new tests are compatible with wantobjects=1 and wantobjects=0.

It will be good to test it with Tcl/Tk 8.4 (or even 8.3) and on Windows.

----------
components: Tests, Tkinter
files: tkinter_options_tests.patch
keywords: patch
messages: 198366
nosy: gpolo, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Add tkinter basic options tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31861/tkinter_options_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19085>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:26:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Sep 2013 21:26:04 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1380057964.59.0.427175348891.issue18844@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Most existing implementation produce just index. That is why weighted_choice() accepts singular weights list and returns index. On the other hand, I think working with mapping will be wished feature too (especially because Counter is in stdlib). Indexable sequences and mappings are similar. In both cases weighted_choice() returns value which can be used as index/key of input argument.

If you need choice an element from some sequence, just use seq[weighted_choice(weights)]. Actually weighted_choice() has no common code with choice() and has too different use cases. They should be dissimilar as far as possible. Perhaps we even should avoid the "choice" part in function names (are there any ideas?) to accent this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:29:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Sep 2013 21:29:25 +0000
Subject: [issue17618] base85 encoding
In-Reply-To: <1364909015.82.0.0760723886219.issue17618@psf.upfronthosting.co.za>
Message-ID: <1380058165.02.0.0159422653647.issue17618@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17618>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:51:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Sep 2013 21:51:37 +0000
Subject: [issue19077] More robust TemporaryDirectory cleanup
In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za>
Message-ID: <1380059497.97.0.288173185546.issue19077@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19077>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:54:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Sep 2013 21:54:42 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
 tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1380059682.07.0.724437433472.issue1820@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:56:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Sep 2013 21:56:52 +0000
Subject: [issue19050] crash while writing to a closed file descriptor
In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za>
Message-ID: <1380059812.45.0.0526313963913.issue19050@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19050>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:58:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Sep 2013 21:58:02 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380059882.1.0.12336149169.issue19058@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: test_ioencoding_nonascii (test_sys) fails on Snow Leopard -> test_sys.test_ioencoding_nonascii() fails with ASCII locale encoding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Tue Sep 24 23:59:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Sep 2013 21:59:04 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1380059944.1.0.0884115187601.issue16038@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
Added file: http://bugs.python.org/file31862/ftplib_maxline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Wed Sep 25 00:02:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Sep 2013 22:02:31 +0000
Subject: [issue19046] SystemError: ..\Objects\weakrefobject.c:903: bad
 argument to internal function
In-Reply-To: <1379574898.14.0.174335958635.issue19046@psf.upfronthosting.co.za>
Message-ID: <1380060151.16.0.412876212761.issue19046@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19046>
_______________________________________

From report at bugs.python.org  Wed Sep 25 00:04:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Sep 2013 22:04:01 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380060241.52.0.424540550148.issue19058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Shouldn't FS_NONASCII be None with ASCII locale encoding?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Wed Sep 25 00:08:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Sep 2013 22:08:30 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380060510.78.0.921088135127.issue19058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Shouldn't FS_NONASCII be None with ASCII locale encoding?

See the description of the variable in test.support:

# FS_NONASCII: non-ASCII character encodable by os.fsencode(),
# or None if there is no such character.

The file system encoding an the locale encoding can be different... especially when PYTHONIOENCODING is used.

The test should not use FS_NONASCII.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Wed Sep 25 00:18:06 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 24 Sep 2013 22:18:06 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1380059944.1.0.0884115187601.issue16038@psf.upfronthosting.co.za>
Message-ID: <20130924181802.42d2320b@anarchist>


Barry A. Warsaw added the comment:

On Sep 24, 2013, at 09:59 PM, Serhiy Storchaka wrote:

>Added file: http://bugs.python.org/file31862/ftplib_maxline.patch

This looks great and fixes the test failure problem.  Thanks!  Serhiy, please
feel free to apply this to the 2.6 branch, or let me know if you'd rather I
apply it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Wed Sep 25 00:36:07 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 24 Sep 2013 22:36:07 +0000
Subject: [issue18844] allow weights in random.choice
In-Reply-To: <1377537825.13.0.508607501106.issue18844@psf.upfronthosting.co.za>
Message-ID: <1380062167.4.0.793742937812.issue18844@psf.upfronthosting.co.za>


Madison May added the comment:

You have me convinced, Serhiy.  I see the value in making the two functions distinct.

For naming purposes, perhaps weighted_index() would be more descriptive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18844>
_______________________________________

From report at bugs.python.org  Wed Sep 25 01:50:43 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Sep 2013 23:50:43 +0000
Subject: [issue19085] Add tkinter basic options tests
In-Reply-To: <1380054632.03.0.105033569087.issue19085@psf.upfronthosting.co.za>
Message-ID: <1380066643.13.0.89996711029.issue19085@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19085>
_______________________________________

From report at bugs.python.org  Wed Sep 25 01:53:38 2013
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Tue, 24 Sep 2013 23:53:38 +0000
Subject: [issue19071] Documentation on what self is for module-level functions
 is misleading/wrong.
In-Reply-To: <1379849996.18.0.35390897499.issue19071@psf.upfronthosting.co.za>
Message-ID: <1380066818.71.0.162099351024.issue19071@psf.upfronthosting.co.za>


Changes by A. Jesse Jiryu Davis <jesse at emptysquare.net>:


----------
nosy: +emptysquare

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19071>
_______________________________________

From report at bugs.python.org  Wed Sep 25 03:05:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Sep 2013 01:05:28 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380071128.47.0.982364845208.issue19058@psf.upfronthosting.co.za>


R. David Murray added the comment:

Also note that on OS X I believe the fsencoding is always utf-8, but the locale can of course be something else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Wed Sep 25 05:08:01 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 25 Sep 2013 03:08:01 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <1380078481.89.0.106114917776.issue19011@psf.upfronthosting.co.za>


Ethan Furman added the comment:

As discussed on PyDev[1], Enum members are bonafide class attributes, as in they show on the class, not on the instances.

Documentation patch attached.

[1] https://mail.python.org/pipermail/python-dev/2013-September/128874.html

----------
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file31863/issue19011.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Wed Sep 25 05:09:39 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 25 Sep 2013 03:09:39 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1380078579.39.0.0427888382128.issue19040@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Doc patch is in #19011.  I'll close this one when that one is closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Wed Sep 25 07:47:56 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Sep 2013 05:47:56 +0000
Subject: [issue18596] enable usage of AddressSanitizer in CPython [PATCH]
In-Reply-To: <1375174359.28.0.546907495292.issue18596@psf.upfronthosting.co.za>
Message-ID: <1380088076.18.0.314148922051.issue18596@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18596>
_______________________________________

From report at bugs.python.org  Wed Sep 25 09:15:01 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Sep 2013 07:15:01 +0000
Subject: [issue13824] argparse.FileType opens a file and never closes it
In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za>
Message-ID: <1380093301.06.0.604701830066.issue13824@psf.upfronthosting.co.za>


paul j3 added the comment:

An alternative way to delay the file opening, is to return an instance that has a `filename` attribute, and has an `open` method.  This can be compactly added to the `FileContext` that I defined in the previous patch.  The `FileContext` provides the `_ostest` function (testing using os.access), and wrapper for stdin/out.


    class FileOpener(argparse.FileContext):
        # delayed FileType; alt to use of partial()
        # sample use:
        # with args.input.open() as f: f.read()
        def __call__(self, string):
            string = self._ostest(string)
            self.filename = string
            return self
        def open(self):
            return self.__delay_call__(self.filename)()
        file =  property(open, None, None, 'open file property')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13824>
_______________________________________

From report at bugs.python.org  Wed Sep 25 09:30:08 2013
From: report at bugs.python.org (Sunny)
Date: Wed, 25 Sep 2013 07:30:08 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1380094208.13.0.596429666664.issue1185124@psf.upfronthosting.co.za>


Sunny added the comment:

I've updated my patch with the review changes and tests.

tokenize.detect_encoding throws a TypeError if the file object passed to it is in text mode. However, i've realized catching this is not necessary as i now check for TextIOBase instead of just StringIO before.

----------
Added file: http://bugs.python.org/file31864/myfirst_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Wed Sep 25 10:42:36 2013
From: report at bugs.python.org (=?utf-8?q?Manuel_P=C3=A9gouri=C3=A9-Gonnard?=)
Date: Wed, 25 Sep 2013 08:42:36 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1380098556.27.0.296258920807.issue1185124@psf.upfronthosting.co.za>


Changes by Manuel P?gouri?-Gonnard <mpg at elzevir.fr>:


----------
nosy:  -mpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Wed Sep 25 11:28:45 2013
From: report at bugs.python.org (Roger Light)
Date: Wed, 25 Sep 2013 09:28:45 +0000
Subject: [issue19084] No way to use TLS-PSK from python ssl
In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za>
Message-ID: <1380101325.17.0.620708935513.issue19084@psf.upfronthosting.co.za>


Roger Light added the comment:

This is not TLS-SRP, but TLS-PSK as described by RFC 4279[1]

There is a very small amount of overlap - the "unknown_psk_identity" error defined by PSK is also used in SRP.

[1] http://tools.ietf.org/html/rfc4279

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19084>
_______________________________________

From report at bugs.python.org  Wed Sep 25 11:40:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 09:40:28 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380102028.01.0.714880850078.issue19058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed.

Here is a patch. It uses same algorithm to obtain encodable non-ASCII string as for FS_NONASCII, but with locale encoding. It also adds new tests and simplifies existing tests.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31865/sys_test_ioencoding_locale.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Wed Sep 25 11:54:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 09:54:00 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1380102840.92.0.691286895606.issue16038@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please apply it yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Wed Sep 25 12:46:10 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Wed, 25 Sep 2013 10:46:10 +0000
Subject: [issue19086] Make fsum usable incrementally.
Message-ID: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>


New submission from Oscar Benjamin:

I would like to be able use fsum incrementally however it is not currently possible.

With sum() you can do:

subtotal = sum(nums)
subtotal = sum(othernums, subtotal)

This wouldn't work for fsum() because the returned float is not the same as the state maintained internally which is a list of floats. I propose instead that a fsum() could take an optional second argument which is a list of floats and in this case return the updated list of floats.

I have modified Raymond Hettinger's msum() recipe to do what I want:

def fsum(iterable, carry=None):
    "Full precision summation using multiple floats for intermediate values"
    partials = list(carry) if carry else []
    for x in iterable:
        i = 0
        for y in partials:
            if abs(x) < abs(y):
                x, y = y, x
            hi = x + y
            lo = y - (hi - x)
            if lo:
                partials[i] = lo
                i += 1
            x = hi
        partials[i:] = [x]
    if carry is None:
        return sum(partials, 0.0)
    else:
        return partials


Here's an interactive session showing how you might use it:

>>> from fsum import fsum
>>> fsum([1e20, 1, -1e20])
1.0
>>> fsum([1e20, 1, -1e20], [])
[1.0, 0.0]
>>> fsum([1e20, 1, -1e20], [])
[1.0, 0.0]
>>> fsum([1e20, 1, -1e20], [])
[1.0, 0.0]
>>> fsum([1e20, 1], [])
[1.0, 1e+20]
>>> carry = fsum([1e20, 1], [])
>>> fsum([-1e20], carry)
[1.0, 0.0]
>>> nums = [7, 1e100, -7, -1e100, -9e-20, 8e-20] * 10
>>> subtotal = []
>>> for n in nums:
...     subtotal = fsum([n], subtotal)
...
>>> subtotal
[-1.0000000000000007e-19]
>>> fsum(subtotal)
-1.0000000000000007e-19


My motivation for this is that I want to be able to write an efficient sum function that is accurate for a mix of ints and floats while being as fast as possible in the case that I have a list of only floats (or only ints). What I have so far looks a bit like:

def sum(numbers):
    exact_total = 0
    float_total = 0.0
    for T, nums in groupby(numbers):
        if T is int:
            exact_total = sum(nums, exact_total)
        elif T is float:
            # This doesn't really work:
            float_total += fsum(float_total)
        # ...


However fsum is only exact if it adds all the numbers in a single pass. The above would have order-dependent results given a mixed list of ints and floats e.g.:

[1e20, -1e20, 1, -1, 1.0, -1.0]
  vs
[1e20, 1.0, -1e20, 1, -1, -1.0]

Although fsum is internally very accurate it always discards information on output. Even if I build a list of all floats and fsum those at the end it can still be inaccurate if the exact_total cannot be exactly coerced to float and passed to fsum.

If I could get fsum to return the exact float expansion then I could use that in a number of different ways. Given the partials list I can combine all of the different subtotals with Fraction arithmetic and coerce to float only at the very end. If I can also get fsum to accept a float expansion on input then I can use it incrementally and there is no need to build a list of all floats.

I am prepared to write a patch for this if the idea is deemed acceptable.

----------
components: Library (Lib)
messages: 198381
nosy: mark.dickinson, oscarbenjamin, rhettinger
priority: normal
severity: normal
status: open
title: Make fsum usable incrementally.
type: enhancement
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Wed Sep 25 13:51:14 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Sep 2013 11:51:14 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1380109874.15.0.339580355459.issue19083@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
versions: +Python 3.4 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Wed Sep 25 14:51:44 2013
From: report at bugs.python.org (halfie)
Date: Wed, 25 Sep 2013 12:51:44 +0000
Subject: [issue18596] enable usage of AddressSanitizer in CPython [PATCH]
In-Reply-To: <1375174359.28.0.546907495292.issue18596@psf.upfronthosting.co.za>
Message-ID: <1380113504.91.0.245155107568.issue18596@psf.upfronthosting.co.za>


halfie added the comment:

I am attaching the latest tested patch against tip.

----------
Added file: http://bugs.python.org/file31866/ASAN-compat-35da5d848ffd-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18596>
_______________________________________

From report at bugs.python.org  Wed Sep 25 15:06:26 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 25 Sep 2013 13:06:26 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380114386.96.0.778060230663.issue19078@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

So, in the following case, len shouldn't return 4, but the number of items? Also, is it ok to assume that the number of items is
((*shape)[0] * ... * (*shape)[ndims-1])?

>>> x = np.array([[1, 2, 3], [4, 5, 6], [4,5,6], [4,4,4]], np.int32)
>>> x.shape
(4, 3)
>>> x.shape[0] * x.shape[1]
12
>>> len(x)
4
>>> memoryview(x)
<memory at 0x0217C378>
>>> len(memoryview(x))
4
>>> memoryview(x).shape
(4, 3)
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Wed Sep 25 15:46:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 13:46:43 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1380114386.96.0.778060230663.issue19078@psf.upfronthosting.co.za>
Message-ID: <1770729997.22039800.1380116797336.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

No, you're right, it should probably return 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:03:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 14:03:50 +0000
Subject: [issue19087] bytearray front-slicing not optimized
Message-ID: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you delete a slice at the end of a bytearray, it is naturally optimized (thanks to the resizing strategy). However, if you delete a slice at the front of a bytearray, it is not: a memmove() gets done every time.

$ ./python -m timeit "b=bytearray(10000)" "while b: b[-1:] = b''"
100 loops, best of 3: 5.67 msec per loop
$ ./python -m timeit "b=bytearray(10000)" "while b: b[:1] = b''"
100 loops, best of 3: 6.67 msec per loop

$ ./python -m timeit "b=bytearray(50000)" "while b: b[-1:] = b''"
10 loops, best of 3: 28.3 msec per loop
$ ./python -m timeit "b=bytearray(50000)" "while b: b[:1] = b''"
10 loops, best of 3: 61.1 msec per loop

$ ./python -m timeit "b=bytearray(100000)" "while b: b[-1:] = b''"
10 loops, best of 3: 59.4 msec per loop
$ ./python -m timeit "b=bytearray(100000)" "while b: b[:1] = b''"
10 loops, best of 3: 198 msec per loop

This makes implementing a fifo using bytearray a bit suboptimal. It shouldn't be very hard to improve.

----------
components: Interpreter Core
messages: 198385
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bytearray front-slicing not optimized
type: performance
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:11:14 2013
From: report at bugs.python.org (Larry Pete)
Date: Wed, 25 Sep 2013 14:11:14 +0000
Subject: [issue19088] TypeError with pickle in embedded python3.3 when
 starting multiple Interpreters.
Message-ID: <1380118274.37.0.850286724138.issue19088@psf.upfronthosting.co.za>


New submission from Larry Pete:

Hexchat (fork of XChat IRC Client) switched with version 2.9.6 to Python 3.3 for their Python plugins.
Hexchat loads plugins in a similar fashion like the attached C file (not entirely sure I used the C-API right though). For every plugin a new interpreter is started and Py_EndInterpreter is used to unload the plugin.
When using pickle in such a python plugin, it raises the Exception (in the attached example):

Traceback (most recent call last):
  File "<string>", line 7, in <module>
TypeError: attribute of type 'NoneType' is not callable

when trying to pickle an object (using pickle.dump or pickle.dumps).
The Exception happens on the line where pickle.dumps is called, though pickle.dumps is not None.

It happens:
- with python3.3.2 (I also tested it with python3.4.0a2 since I happened to have it installed, same issue). No issue with python2.7. I did not test it with 3.x versions prior to 3.3.2
- when trying to pickle a user defined class. Python objects like dictionaries and lists work fine.
- only with the second (and any additional) interpreter.
- when destroying the interpreter and starting a new one, in that order. When two interpreters are started and execute the code before any of them is destroyed, it works fine.

The full output of the attached file when executed is btw:

First output:
Pickle dumps:
b'\x80\x03c__main__\nSomeClass\nq\x00)\x81q\x01}q\x02X\x08\x00\x00\x00some_varq\x03K{sb.'

Second output:
Pickle dumps:
Traceback (most recent call last):
  File "<string>", line 7, in <module>
TypeError: attribute of type 'NoneType' is not callable

----------
components: Extension Modules
files: fail.c
messages: 198386
nosy: Larry.Pete, alexandre.vassalotti, pitrou
priority: normal
severity: normal
status: open
title: TypeError with pickle in embedded python3.3 when starting multiple Interpreters.
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31867/fail.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19088>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:15:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Sep 2013 14:15:01 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <3clLrN4CG2z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 436b606ecfe8 by Ethan Furman in branch 'default':
Close #19030: improvements to inspect and Enum.
http://hg.python.org/cpython/rev/436b606ecfe8

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:21:15 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 25 Sep 2013 14:21:15 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and
 tuple	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1380118875.22.0.320361893578.issue1820@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:21:32 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 25 Sep 2013 14:21:32 +0000
Subject: [issue5907] repr of time.struct_time type does not eval
In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za>
Message-ID: <1380118892.83.0.82360062113.issue5907@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5907>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:43:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Sep 2013 14:43:17 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <3clMT12CKdz7Ljs@mail.python.org>


Roundup Robot added the comment:

New changeset 8b19e7d0be45 by Barry Warsaw in branch '2.6':
- Issue #16038: CVE-2013-1752: ftplib: Limit amount of data read by
http://hg.python.org/cpython/rev/8b19e7d0be45

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Wed Sep 25 16:49:34 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 25 Sep 2013 14:49:34 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1380120574.39.0.653570818813.issue16038@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Wed Sep 25 17:35:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 15:35:36 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1380123336.85.0.0289676753838.issue19021@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm wondering too. While the code in Popen.__del__() is almost same, I can't reproduce the issue in 3.3. Perhaps it relates to some 3.4 changes? Import machinery, weak references, the shutdown process?

Before applying the patch which fixes Popen.__del__() I want understand what happens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Wed Sep 25 17:47:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 15:47:10 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380124030.91.0.789474008697.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And the same is for a list. List and bytearray are wrong types for front deleting. I don't think we should increase the size of bytearray, and complicate and slowdown it for such special purpose.

If you want to implement a fifo using bytearray more optimal, defer the deleting until used size less than a half of allocated size. See for example XMLPullParser.read_events() in Lib/xml/etree/ElementTree.py.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Wed Sep 25 17:50:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 15:50:19 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380124030.91.0.789474008697.issue19087@psf.upfronthosting.co.za>
Message-ID: <443330024.22346548.1380124213098.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> And the same is for a list. List and bytearray are wrong types for
> front deleting.

There is no bytedeque().

> I don't think we should increase the size of
> bytearray, and complicate and slowdown it for such special purpose.

I don't think it would really slow it down. It should be a simple
optimization. And FIFO buffers are quite common when writing parsers
for network applications.

> If you want to implement a fifo using bytearray more optimal, defer
> the deleting until used size less than a half of allocated size. See
> for example XMLPullParser.read_events() in
> Lib/xml/etree/ElementTree.py.

Of course, I wrote that code. Still, doing it manually is suboptimal
and cumbersome when it could be done transparently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:06:38 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 25 Sep 2013 16:06:38 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1380125198.77.0.555613148128.issue19021@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

The clearing of modules at shutdown has been substantially changed in 3.4.  Now a best effort is made to let the module go away purely by gc.  Those modules which survive get purged in random order.

In 3.3 all modules were purged, but builtins was special cased to be purged last.  (See Python/import.c:PyImport_Cleanup().)

I would favour setting a flag before the purging stage which prevents __del__ methods (and weakrefs?) from running.

----------
nosy: +pitrou, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:32:35 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Sep 2013 16:32:35 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
Message-ID: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Ctrl-D shortcut works to terminate session in Python 2 on Windows, and doesn't work with Python 3.

----------
components: Windows
messages: 198393
nosy: techtonik
priority: normal
severity: normal
status: open
title: Windows: Broken Ctrl-D shortcut on Python 3
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/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:45:18 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 25 Sep 2013 16:45:18 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380127518.31.0.693751595811.issue19089@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

It never worked for me.
Are you using a custom shell or cygwin or something?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:45:56 2013
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 25 Sep 2013 16:45:56 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380127556.46.0.74961502311.issue19089@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Ctrl-D has never work for me on Windows either.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:48:59 2013
From: report at bugs.python.org (Tim Golden)
Date: Wed, 25 Sep 2013 16:48:59 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <524313F2.4080106@timgolden.me.uk>


Tim Golden added the comment:

It doesn't work on Python 2.x either as delivered. Usually means you 
have an external readline module installed.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:52:15 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Sep 2013 16:52:15 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380127935.2.0.641848720242.issue19089@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Well, it appears that installed IPython brought pyreadline, but I execute it in standard Python shell.

I'd vote for this feature by default. Is that possible without readline?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 18:52:56 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Sep 2013 16:52:56 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380127976.3.0.103935700037.issue19089@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Here is the output of "py -v".

----------
Added file: http://bugs.python.org/file31868/py_-v.stderr.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 19:08:19 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 25 Sep 2013 17:08:19 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380128899.16.0.0949032949254.issue19089@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The Windows (and before it MS-DOS) EOF character is Ctrl-Z. Try that.

Depending on the toolset you use, it might use Ctrl-D as EOF. Cygwin's python uses Ctrl-D.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 19:17:07 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Sep 2013 17:17:07 +0000
Subject: [issue19089] Windows: Broken Ctrl-D shortcut on Python 3
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380129427.28.0.823320127191.issue19089@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

It would be nice if Python supported some cross-platform standard for user interfaces. It is rather annoying to use Ctrl-Z for Python in local window and Ctrl-D for Python in remote console session (which is *nix of course).

It becomes even more annoying, because Ctrl-Z in *nix session sends Python process to background.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 19:18:25 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 25 Sep 2013 17:18:25 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380129505.66.0.17122166859.issue19089@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
title: Windows: Broken Ctrl-D shortcut on Python 3 -> Windows: Make Ctrl-D exit key combination cross-platform
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 19:22:11 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 25 Sep 2013 17:22:11 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380129731.2.0.739934738634.issue19089@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It's trying to be consistent on whatever platform it's on. I'd rather python.exe match all other text-based .exe's on Windows. We can't have it both ways.

But I agree it's a hassle. Cross-platform is a problem that Cygwin is trying to solve, so I suggest you use it. I usually use the Cygwin python for this reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 19:25:49 2013
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 25 Sep 2013 17:25:49 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380129949.41.0.236026303277.issue19089@psf.upfronthosting.co.za>


Brian Curtin added the comment:

I'm unable to find the previous issue, but you asked for this in the past. Ctrl-Z and Ctrl-D simply have different meanings on the different platforms, outside of what Python does. We already can't make Ctrl-Z on Windows do what it does on Linux, and Ctrl-D is not natural to Windows users.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 19:32:34 2013
From: report at bugs.python.org (Tim Golden)
Date: Wed, 25 Sep 2013 17:32:34 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380129949.41.0.236026303277.issue19089@psf.upfronthosting.co.za>
Message-ID: <52431DA5.4020701@timgolden.me.uk>


Tim Golden added the comment:

I'm at best +0.25, but I don't have a problem with Ctrl-D exiting on 
Windows, as it doesn't do anything else!

The thing is, though, that this is all handled within 
myreadline.c:my_fgets which is a call into the system fgets which errors 
out with Ctrl-Z but returns Ctrl-D. Which means that the two would 
behave differently even if we special-cased Ctrl-D.

(Sorry: was that explanation a bit involved?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:02:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 18:02:32 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1380132152.82.0.0658532024137.issue19021@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could we instead restore the builtins module to it's initial state before the purging stage? I believe all builtins are immutable and can't create reference loops.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:24:31 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 25 Sep 2013 18:24:31 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1380133471.73.0.110994483963.issue19081@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file31869/issue19081-gps02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:28:29 2013
From: report at bugs.python.org (Aivar Annamaa)
Date: Wed, 25 Sep 2013 18:28:29 +0000
Subject: [issue19091] ast.parse gives wrong position for some Names when
 non-ascii characters occur before
Message-ID: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>


New submission from Aivar Annamaa:

ast.parse gives col_offset=4 for Name x when given program "a + x" vs. col_offset=5 for x when Name a is replaced with a-umlaut (I can't write that character here, because it seems that the issue system doesn't handle non-ascii characters either).

See the attached Python shell transcript for explanation (it's in UTF-8).

----------
components: Interpreter Core
files: bug.txt
messages: 198406
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: ast.parse gives wrong position for some Names when non-ascii characters occur before
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31870/bug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19091>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:39:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 18:39:03 +0000
Subject: [issue19091] ast.parse gives wrong position for some Names when
 non-ascii characters occur before
In-Reply-To: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>
Message-ID: <1380134343.03.0.417910590726.issue19091@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks similar to issue2382 and issue10382.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19091>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:39:31 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 25 Sep 2013 18:39:31 +0000
Subject: [issue19081] zipimport behaves badly when the zip file changes while
 the process is running
In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za>
Message-ID: <1380134371.39.0.743635488494.issue19081@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


Added file: http://bugs.python.org/file31871/issue19081-gps03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19081>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:43:59 2013
From: report at bugs.python.org (Aivar Annamaa)
Date: Wed, 25 Sep 2013 18:43:59 +0000
Subject: [issue19091] ast.parse gives wrong position for some Names when
 non-ascii characters occur before
In-Reply-To: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>
Message-ID: <1380134639.52.0.743029812933.issue19091@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

Serhiy, it's similar in that it has to do with encodings, but I think it's caused by different bug.

I suspect it has something to do with the fact that tokenizer gives positions as offsets of characters and ast as offsets of UTF-8 bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19091>
_______________________________________

From report at bugs.python.org  Wed Sep 25 20:47:03 2013
From: report at bugs.python.org (Aivar Annamaa)
Date: Wed, 25 Sep 2013 18:47:03 +0000
Subject: [issue19091] ast.parse gives wrong position for some Names when
 non-ascii characters occur before
In-Reply-To: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>
Message-ID: <1380134823.14.0.511155711294.issue19091@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

I should explain more -- the string containing the program is read in correctly, the trouble occurs during parse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19091>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:02:32 2013
From: report at bugs.python.org (Aivar Annamaa)
Date: Wed, 25 Sep 2013 19:02:32 +0000
Subject: [issue19091] ast.parse gives wrong position for some Names when
 non-ascii characters occur before
In-Reply-To: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>
Message-ID: <1380135752.06.0.925976963585.issue19091@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

> ast [gives positions as] offsets of UTF-8 bytes

Oops, I'm sorry, I realized only now that this is the explanation of this behaviour. So, after all it seems to be a feature (albeit very weird), not a bug.

----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19091>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:09:47 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Wed, 25 Sep 2013 19:09:47 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
Message-ID: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i?:

While using contextlib.ExitStack in our project, we noticed that its __exit__ method of contextlib.ExitStack suppresses the exception raised in any contextmanager's __exit__ except the outermost one. Here is a test case to reproduce the problem:

class Err:
  def __enter__(self): pass
  def __exit__(self, *exc): 1/0

class Ok:
  def __enter__(self): pass
  def __exit__(self, *exc): pass


import contextlib
s = contextlib.ExitStack()
s.push(Ok())
s.push(Err())
with s:
  pass

Since the inner context manager raises in __exit__ and neither context manager requests suppression, I would expect to see a ZeroDivisionError raised. What actually happens is that the exception is suppressed. This behavior caused us quite a few headaches before we figured out why we the exceptions raised in during __exit__ went silently undetected in production.

The problem is in ExitStack.__exit__, which explicitly propagates the exception only if it occurs in the outermost exit callback. The idea behind it appears to be to simply record the raised exception in order to allow exit callbacks of the outer context managers to see the it -- and get a chance to suppress it. The only exception that is directly re-raised is the one occurring in the outermost exit callback, because it certainly cannot be seen nor suppressed by anyone else.

But this reasoning is flawed because if an exception happens in an inner cm and none of the outer cm's chooses to suppress it, then there will be no one left to raise it. Simply returning True from ExitStack.__exit__ is of no help, as that only has an effect when an exception was passed into the function in the first place, and even then, the caller can only re-raise the earlier exception, not the exception that occurred in the exit callback. And if no exception was sent to ExitStack.__exit__, as is the case in the above code, then no exception will be re-raised at all, effectively suppressing it.

I believe the correct way to handle this is by keeping track of whether an exception actually occurred in one of the _exit_callbacks. As before, the exception is forwarded to next cm's exit callbacks, but if none of them suppresses it, then the exception is re-raised instead of returning from the function. I am attaching a patch to contextlib.py that implements this change.

The patch also makes sure that True is returned from ExitStack.__exit__ only if an exception was actually passed into it.

----------
components: Library (Lib)
files: exitstack.diff
keywords: patch
messages: 198411
nosy: hniksic
priority: normal
severity: normal
status: open
title: ExitStack.__exit__ incorrectly suppresses exceptions in __exit__ callbacks of inner context managers
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31872/exitstack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:23:34 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 25 Sep 2013 19:23:34 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>
Message-ID: <1380137014.27.0.506617718328.issue19092@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:29:18 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 25 Sep 2013 19:29:18 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>
Message-ID: <1380137358.55.0.325159496093.issue19092@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:30:01 2013
From: report at bugs.python.org (Roman)
Date: Wed, 25 Sep 2013 19:30:01 +0000
Subject: [issue19093] RE
Message-ID: <2DE46778-8EC6-48FD-A490-6BA930F75E6C@aol.com>


New submission from Roman:

complete my registration

----------
messages: 198412
nosy: bjimnen
priority: normal
severity: normal
status: open
title: RE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19093>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:37:14 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Sep 2013 19:37:14 +0000
Subject: [issue19093] Spam
In-Reply-To: <2DE46778-8EC6-48FD-A490-6BA930F75E6C@aol.com>
Message-ID: <1380137834.99.0.534378330125.issue19093@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy:  -bjimnen
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: RE -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19093>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:37:28 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Sep 2013 19:37:28 +0000
Subject: [issue19093] Spam
Message-ID: <1380137848.33.0.141240692587.issue19093@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
Removed message: http://bugs.python.org/msg198412

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19093>
_______________________________________

From report at bugs.python.org  Wed Sep 25 21:38:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Sep 2013 19:38:37 +0000
Subject: [issue19021] AttributeError in Popen.__del__
In-Reply-To: <1379202406.71.0.0429173757884.issue19021@psf.upfronthosting.co.za>
Message-ID: <1380137917.18.0.426112465134.issue19021@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> Before applying the patch which fixes Popen.__del__()

I think your #12085 patch should be applied and that issue closed. It is not specifically about shutdown. Tweaking shutdown further would be a new issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19021>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:07:19 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 25 Sep 2013 20:07:19 +0000
Subject: [issue19077] More robust TemporaryDirectory cleanup
In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za>
Message-ID: <1380139639.55.0.91707584668.issue19077@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

An alternative would be to use weakref.finalize() which would guarantee that cleanup happens before any purging occurs.  That would allow the use of shutil:

class TemporaryDirectory(object):
    def __init__(self, suffix="", prefix=template, dir=None):
        self.name = mkdtemp(suffix, prefix, dir)
        self._cleanup = weakref.finalize(self, shutil.rmtree, self.name)

    def __enter__(self):
        return self.name

    def __exit__(self, exc, value, tb):
        self._cleanup()

    def cleanup(self):
        self._cleanup()

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19077>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:10:00 2013
From: report at bugs.python.org (Doug Hellmann)
Date: Wed, 25 Sep 2013 20:10:00 +0000
Subject: [issue11638] python setup.py sdist --formats tar* crashes if
 version	is unicode
In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za>
Message-ID: <1380139800.17.0.0903785868159.issue11638@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11638>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:20:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Sep 2013 20:20:30 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1380140430.33.0.502163821375.issue18314@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:26:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 20:26:02 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380140762.59.0.0778893115079.issue19087@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch. Benchmarks (under Linux where realloc is fast; the gap may be wider under Windows):

$ ./python -m timeit "b=bytearray(100000)" "while b: b[:1] = b''"
-> before: 225 msec per loop
-> after: 60.4 msec per loop

$ ./python -m timeit "b=bytearray(100000)" "while b: b[:200] = b''"
-> before: 1.17 msec per loop
-> after: 350 usec per loop

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file31873/bytea_slice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:34:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 20:34:33 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380141273.91.0.133498748853.issue19087@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:52:38 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Sep 2013 20:52:38 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1380142358.13.0.720030421771.issue18314@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am not sure if this is a bug or enhancement. It is a moot point until there is a patch to apply.

A patch would need a test that fails now and passes with the patch. From the Wikipedia article, it appears that a test using mklink /J would not run on XP and would have to be skipped. I would not expect an XP buildbot to necessarily have the Server 2003 Resource Kit needed for an XP test.

Does _delete_junction_point(link_path) work on XP or should the feature be restricted to Vista+?

----------
nosy: +terry.reedy
stage:  -> test needed
type: behavior -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:53:57 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 25 Sep 2013 20:53:57 +0000
Subject: [issue19088] TypeError with pickle in embedded python3.3 when
 starting multiple Interpreters.
In-Reply-To: <1380118274.37.0.850286724138.issue19088@psf.upfronthosting.co.za>
Message-ID: <1380142437.6.0.912034327649.issue19088@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

The NoneType that fails is in typeobject.c:
   _PyObject_CallMethodId(copyreg, &PyId__slotnames, "O", cls);

The error here is that copyreg comes from a cached reference to the module, stored in a static variable (cached_copyreg_module).  When the interpreter shuts down the first time, all the module members are set to None... but the reference is kept forever.

This variable should be reset, and reloaded (with a fresh module from the new interpreter) the next time it's used.
I added a call to _PyType_Fini() in Py_EndInterpreter, this fixes the given example.

Two sets of questions though:

- There are many of these _Fini functions, called in Py_Finalize. Which ones should we call in Py_EndInterpreter? and why? Maybe this PyType_Fini() is not a _Fini, but should be renamed PyType_EndInterpreter?

- one copyreg for multiple interpreters... this looks wrong: each interpreter has its own list of modules, but copyreg.__globals__ belongs to only one...
  A good solution would be to cache the copyreg module in the PyInterpreterState (it already has codec_search_cache). Or use PyImport_GetModuleDict()

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19088>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:55:41 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 25 Sep 2013 20:55:41 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
Message-ID: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

>>> import urllib.parse
>>> urllib.parse.urljoin('foo', [])
'foo'

That should raise a TypeError, not succeed quietly as if an empty string were passed.

----------
components: Library (Lib)
messages: 198418
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: urljoin should raise a TypeError if URL is not a string
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Wed Sep 25 22:59:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 20:59:44 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
 is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1380142784.72.0.37098944552.issue2382@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added tests. I think it will be worth apply this patch which fixes the issue for most Europeans and than continue working on the issue of wide characters.

----------
Added file: http://bugs.python.org/file31874/adjust_offset_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Wed Sep 25 23:00:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 21:00:44 +0000
Subject: [issue19088] TypeError with pickle in embedded python3.3 when
 starting multiple Interpreters.
In-Reply-To: <1380118274.37.0.850286724138.issue19088@psf.upfronthosting.co.za>
Message-ID: <1380142844.83.0.512497574708.issue19088@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> one copyreg for multiple interpreters... this looks wrong: each interpreter has its own list of modules, but copyreg.__globals__ belongs to only one...
> A good solution would be to cache the copyreg module in the PyInterpreterState (it already has codec_search_cache).

Yes, this is a reasonable solution.

----------
stage:  -> needs patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19088>
_______________________________________

From report at bugs.python.org  Wed Sep 25 23:02:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 21:02:28 +0000
Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character
 is in line.
In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za>
Message-ID: <1380142948.45.0.832213063629.issue2382@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file27506/adjust_offset-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2382>
_______________________________________

From report at bugs.python.org  Wed Sep 25 23:04:27 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Sep 2013 21:04:27 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>
Message-ID: <1380143067.63.0.118182501031.issue19092@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yep, as indicated by the patch, looks like just a bug with the location of the raise in the stack emulation.

The contextlib tests will also need a new test case to cover this, as well as one to cover such an exception being suppressed by an outer manager.

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Wed Sep 25 23:06:15 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Sep 2013 21:06:15 +0000
Subject: [issue19077] More robust TemporaryDirectory cleanup
In-Reply-To: <1380139639.55.0.91707584668.issue19077@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f_eoYtr+cyiA4DmHeZwEQoHrxU4-M6uTGkfZnZTsxhPg@mail.gmail.com>


Nick Coghlan added the comment:

Sounds good to me!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19077>
_______________________________________

From report at bugs.python.org  Wed Sep 25 23:12:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Sep 2013 21:12:35 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380143555.63.0.0268013159588.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide an example which uses this feature?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Wed Sep 25 23:28:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Sep 2013 21:28:22 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380143555.63.0.0268013159588.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380144499.2527.3.camel@fsol>


Antoine Pitrou added the comment:

> Could you please provide an example which uses this feature?

A generic example is to parse messages out of a TCP stream. Basically
any protocol transported on TCP needs such a facility, or has to find
workarounds (which are either suboptimal or complicated).

Mercurial has another implementation strategy for a similar thing:
http://selenic.com/repo/hg/file/50d721553198/mercurial/util.py#l935

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Thu Sep 26 01:33:02 2013
From: report at bugs.python.org (Dariusz Suchojad)
Date: Wed, 25 Sep 2013 23:33:02 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
Message-ID: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>


New submission from Dariusz Suchojad:

Hello,

I'd like to suggest adding a simple note to SSLSocket.getpeercert stating that it will always return None if do_handshake has never been called.

This is not the default behaviour, by default SSLSocket.__init__'s do_handshake_on_connect is True so .getpeercert nicely returns a cert (assuming the usual caveats - the other side offers a certificate and cert_reqs is not CERT_NONE).

However, I've just been debugging a someone else's server and I spent some time figuring out why client certificates weren't available - turned out this was because do_handshake was never called (PySSL_SSLdo_handshake in _ssl.c).

Adding a single-sentence line will certainly be very helpful.

Many thanks!

----------
assignee: docs at python
components: Documentation
messages: 198425
nosy: docs at python, dsuch
priority: normal
severity: normal
status: open
title: Document SSLSocket.getpeercert always returns None without do_handshake
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Thu Sep 26 02:01:03 2013
From: report at bugs.python.org (Akira Kitada)
Date: Thu, 26 Sep 2013 00:01:03 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1380153663.45.0.911776608899.issue1185124@psf.upfronthosting.co.za>


Akira Kitada added the comment:

Do you have any plan to work on patch for 2.7?
Apparently your patch is only for 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Thu Sep 26 08:22:18 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Thu, 26 Sep 2013 06:22:18 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>
Message-ID: <1380176538.1.0.57345815544.issue19092@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

Nick, thanks for the review. Do you need me to write the patch for the test suite along with the original patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Thu Sep 26 08:40:45 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Sep 2013 06:40:45 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380176538.1.0.57345815544.issue19092@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dk-50LqeAMe1tAxSXHqXbq+qSXom5HV4LS3mff0ZftGQ@mail.gmail.com>


Nick Coghlan added the comment:

That would be very helpful!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Thu Sep 26 09:32:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Sep 2013 07:32:15 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380180735.7.0.740735572714.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Mercurial has another implementation strategy for a similar thing:
> http://selenic.com/repo/hg/file/50d721553198/mercurial/util.py#l935

I found an interesting comment in the following issue:

"I think the trouble we get into is chunkbuffer() creates new large strings by concatenation and causes memory fragmentation. Keeping a list of chunks might be more efficient."

http://bz.selenic.com/show_bug.cgi?id=1842#c17

@Antoine: Do you know if your patch may reduce the memory fragmentation on "bytearray front-slicing"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Thu Sep 26 10:33:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 08:33:56 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380180735.7.0.740735572714.issue19087@psf.upfronthosting.co.za>
Message-ID: <682283912.24191441.1380184430498.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> @Antoine: Do you know if your patch may reduce the memory
> fragmentation on "bytearray front-slicing"?

It reduces the number of allocations so, yes, it can reduce memory
fragmentation.
We cannot really use a list of chunks for bytearray since it is
supposed to be usable as a contiguous buffer (using the buffer API).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Thu Sep 26 10:36:24 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Sep 2013 08:36:24 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380184584.99.0.147477983951.issue19094@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Thu Sep 26 10:45:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 08:45:59 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>
Message-ID: <1380185159.55.0.613207667716.issue19095@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To be honest I'd rather have it raise an exception in that case. None isn't helpful as it could mean other things.

----------
nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Thu Sep 26 10:47:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 08:47:24 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1380185244.02.0.409594414492.issue19083@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Thu Sep 26 10:53:28 2013
From: report at bugs.python.org (Edward Catmur)
Date: Thu, 26 Sep 2013 08:53:28 +0000
Subject: [issue19096] multiprocessing.Pool._terminate_pool restarts workers
 during shutdown
Message-ID: <1380185608.1.0.822768887665.issue19096@psf.upfronthosting.co.za>


New submission from Edward Catmur:

There is a race condition in multiprocessing.Pool._terminate_pool that can result in workers being restarted during shutdown (process shutdown or pool.terminate()).

        worker_handler._state = TERMINATE    # <~~~~ race from here
        task_handler._state = TERMINATE

        debug('helping task handler/workers to finish')
        cls._help_stuff_finish(inqueue, task_handler, len(pool))

        assert result_handler.is_alive() or len(cache) == 0

        result_handler._state = TERMINATE
        outqueue.put(None)                  # sentinel

        # We must wait for the worker handler to exit before terminating
        # workers because we don't want workers to be restarted behind our back.
        debug('joining worker handler')
        worker_handler.join()                # <~~~~~ race to here

At any point between setting worker_handler._state = TERMINATE and joining the worker handler, if the intervening code causes a worker to exit then it is possible for the worker handler to fail to notice that it has been shutdown and so attempt to restart the worker:

    @staticmethod
    def _handle_workers(pool):
        thread = threading.current_thread()

        # Keep maintaining workers until the cache gets drained, unless the pool
        # is terminated.
        while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
            # <~~~~~~ race here
            pool._maintain_pool()
            time.sleep(0.1)
        # send sentinel to stop workers
        pool._taskqueue.put(None)
        util.debug('worker handler exiting')

We noticed this initially because in the absence of the fix to #14881 a ThreadPool trying to restart a worker fails and hangs the process.  In the presence of the fix to #14881 there is no immediate issue, but trying to restart a worker process/thread on pool shutdown is clearly unwanted and could result in bad things happening e.g. at process shutdown.

To trigger the race with ThreadPool, it is enough just to pause the _handle_workers thread after checking its state and before calling _maintain_pool:

import multiprocessing.pool
import time
class ThreadPool(multiprocessing.pool.ThreadPool):
    def _maintain_pool(self):
        time.sleep(1)
        super(ThreadPool, self)._maintain_pool()
    def _repopulate_pool(self):
        assert self._state == multiprocessing.pool.RUN
        super(ThreadPool, self)._repopulate_pool()
pool = ThreadPool(4)
pool.map(lambda x: x, range(5))
pool.terminate()
pool.join()

Exception in thread Thread-5:
Traceback (most recent call last):
  File ".../cpython/Lib/threading.py", line 657, in _bootstrap_inner
    self.run()
  File ".../cpython/Lib/threading.py", line 605, in run
    self._target(*self._args, **self._kwargs)
  File ".../cpython/Lib/multiprocessing/pool.py", line 358, in _handle_workers
    pool._maintain_pool()
  File ".../bug.py", line 6, in _maintain_pool
    super(ThreadPool, self)._maintain_pool()
  File ".../cpython/Lib/multiprocessing/pool.py", line 232, in _maintain_pool
    self._repopulate_pool()
  File ".../bug.py", line 8, in _repopulate_pool
    assert self._state == multiprocessing.pool.RUN
AssertionError

In this case, the race occurs when ThreadPool._help_stuff_finish puts sentinels on inqueue to make the workers finish.

It is also possible to trigger the bug with multiprocessing.pool.Pool:

import multiprocessing.pool
import time
class Pool(multiprocessing.pool.Pool):
    def _maintain_pool(self):
        time.sleep(2)
        super(Pool, self)._maintain_pool()
    def _repopulate_pool(self):
        assert self._state == multiprocessing.pool.RUN
        super(Pool, self)._repopulate_pool()
    @staticmethod
    def _handle_tasks(taskqueue, put, outqueue, pool):
        time.sleep(1)
        _real_handle_tasks(taskqueue, put, outqueue, pool)
_real_handle_tasks = multiprocessing.pool.Pool._handle_tasks
multiprocessing.pool.Pool._handle_tasks = Pool._handle_tasks
pool = Pool(4)
pool.map(str, range(10))
pool.map_async(str, range(10))
pool.terminate()
pool.join()

In this case, the race occurs when _handle_tasks checks thread._state, breaks out of its first loop, and sends sentinels to the workers.

The terminate/join can be omitted, in which case the bug will occur at gc or process shutdown when the pool's atexit handler runs.  The bug is avoided if terminate is replaced with close, and we are using this workaround.

----------
components: Library (Lib)
messages: 198432
nosy: ecatmur
priority: normal
severity: normal
status: open
title: multiprocessing.Pool._terminate_pool restarts workers during shutdown
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19096>
_______________________________________

From report at bugs.python.org  Thu Sep 26 11:03:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 09:03:26 +0000
Subject: [issue19096] multiprocessing.Pool._terminate_pool restarts workers
 during shutdown
In-Reply-To: <1380185608.1.0.822768887665.issue19096@psf.upfronthosting.co.za>
Message-ID: <1380186206.63.0.780617298206.issue19096@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19096>
_______________________________________

From report at bugs.python.org  Thu Sep 26 11:33:42 2013
From: report at bugs.python.org (Shawn Krisman)
Date: Thu, 26 Sep 2013 09:33:42 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <1380188022.52.0.546301269144.issue19016@psf.upfronthosting.co.za>


Shawn Krisman added the comment:

This fix is actually backwards compatible. This is a more powerful patch too because not only does it provide a better default for truthiness, but it also provides a better default for length. I also fixed a spelling mistake involving the word "calculate".

----------
Added file: http://bugs.python.org/file31875/namedtuple_truthiness_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Thu Sep 26 11:45:37 2013
From: report at bugs.python.org (Edward Catmur)
Date: Thu, 26 Sep 2013 09:45:37 +0000
Subject: [issue19096] multiprocessing.Pool._terminate_pool restarts workers
 during shutdown
In-Reply-To: <1380185608.1.0.822768887665.issue19096@psf.upfronthosting.co.za>
Message-ID: <1380188737.01.0.479330452192.issue19096@psf.upfronthosting.co.za>


Edward Catmur added the comment:

Suggested patch: https://bitbucket.org/ecatmur/cpython/compare/19096-multiprocessing-race..#diff

Move the worker_handler.join() to immediately after setting the worker handler thread state to TERMINATE.  This is a safe change as nothing in the moved-over code affects the worker handler thread, except by terminating workers which is precisely what we don't want to happen.  In addition, this is near-equivalent behaviour to current close() + join(), which is well-tested.

Also: write tests; and modify Pool.__init__ to refer to its static methods using self rather than class name, to make them overridable for testing purposes.

----------
hgrepos: +211

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19096>
_______________________________________

From report at bugs.python.org  Thu Sep 26 12:12:03 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 26 Sep 2013 10:12:03 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380190323.7.0.709902160485.issue19094@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

This is the preliminary patch to raise TypeError in that situation.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31876/urljoin_throws_type_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Thu Sep 26 12:45:12 2013
From: report at bugs.python.org (Dariusz Suchojad)
Date: Thu, 26 Sep 2013 10:45:12 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>
Message-ID: <1380192312.26.0.370034789618.issue19095@psf.upfronthosting.co.za>


Dariusz Suchojad added the comment:

> None isn't helpful as it could mean other things.

This is another story but yes, it's true. API-wise, None should be returned in one situation only - we're on server side, ca_certs is non-CERT_NONE, do_handshake has been called yet there is no client certificate. And no other checks should be applied.

But the current behavior of returning None is documented and people depend on it so straightening it out would break backward compatibility - it's up to you to decide. I wouldn't mind it personally. 

But as far as this ticket goes - I'm on 2.7 and it's set in stone so for 2.7 - can you please change copy only? If you decide that for 3.x an exception will be raised then such a caveat would be included in 2.7 docs as well.

Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Thu Sep 26 13:21:31 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 26 Sep 2013 11:21:31 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1380194491.13.0.480894509222.issue19083@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Pepijn: Can you please submit the contributor form?

http://www.python.org/psf/contrib/contrib-form/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Thu Sep 26 14:08:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Sep 2013 12:08:12 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1380197291.99.0.166233420384.issue19083@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Could you also add a test using a IDNA domain not starting with XN--, but with XN-- in the middle? Example:

self.assertEqual(str(b"bugs.XN--pythn-mua.org.", "idna"), "bugs.pyth\xf6n.org.")

And maybe also with mixed cases: Xn-- and xN-- prefixes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Thu Sep 26 14:12:55 2013
From: report at bugs.python.org (Sunny)
Date: Thu, 26 Sep 2013 12:12:55 +0000
Subject: [issue1185124] pydoc doesn't find all module doc strings
Message-ID: <1380197575.24.0.758613712117.issue1185124@psf.upfronthosting.co.za>


Sunny added the comment:

Added patch for 2.7. Please review.

----------
Added file: http://bugs.python.org/file31877/pydoc_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1185124>
_______________________________________

From report at bugs.python.org  Thu Sep 26 14:33:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Sep 2013 12:33:57 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380198837.04.0.697765650691.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Could you please add unit tests for check that ob_start is used instead of memmove()?

I didn't find a function for that in _testcapi. I tried to test it using sys.getsizeof(), but the size is not reliable (the bytearray buffer is not always shrinked, it depends on the new size).

The best is probably to add a new function in _testcapi to get private attributes: ob_exports, ob_alloc, ob_start, ob_bytes. Using these attributes, it becomes easy to check that fast-path are correctly optimized (eg. increases ob_start instead of getting a new ob_bytes buffer).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Thu Sep 26 14:40:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 12:40:23 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380192312.26.0.370034789618.issue19095@psf.upfronthosting.co.za>
Message-ID: <1946526867.24902757.1380199216762.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> But the current behavior of returning None is documented and people
> depend on it so straightening it out would break backward
> compatibility - it's up to you to decide. I wouldn't mind it
> personally.

I'm not sure people depend on getpeercert() returning None before the
handshake is done, or perhaps by accident?

> But as far as this ticket goes - I'm on 2.7 and it's set in stone so
> for 2.7 - can you please change copy only? If you decide that for
> 3.x an exception will be raised then such a caveat would be included
> in 2.7 docs as well.

Yes, if we change behaviour it will only be in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Thu Sep 26 14:42:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 12:42:24 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380198837.04.0.697765650691.issue19087@psf.upfronthosting.co.za>
Message-ID: <1078396074.24908576.1380199338174.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Could you please add unit tests for check that ob_start is used
> instead of memmove()?

How would I do that? Most of the time we don't unit-test performance
improvements (i.e. there are no tests that list.append() is O(1), for
example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Thu Sep 26 15:20:50 2013
From: report at bugs.python.org (Dariusz Suchojad)
Date: Thu, 26 Sep 2013 13:20:50 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>
Message-ID: <1380201650.8.0.07900278874.issue19095@psf.upfronthosting.co.za>


Dariusz Suchojad added the comment:

> I'm not sure people depend on getpeercert() returning None before the
> handshake is done, or perhaps by accident?

Ah, no, I meant that people may depend on the documented behaviour of .getpeercert's returning an empty dict (which I mixed up with returning None) if the certificate was not validated.

That this dictionary's contents depends on the validation is a bit quirky but it's documented so changing that one would surely break existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Thu Sep 26 16:01:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 26 Sep 2013 14:01:59 +0000
Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server
In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>
Message-ID: <1380204119.75.0.826779394702.issue19082@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

What test_xmlrpc_net tests (especially the one with time.xmlrpc.com) have been tested in test_xmlrpc except for connecting to server with dotted_attribute feature and receiving datetime instance over the network.

That test is not that hard to be migrated to test_xmlrpc. But should we chuck it in this ticket or create a new ticket?

There is also a reference to time.xmlrpc.com in Doc/library/xmlrpc.client.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19082>
_______________________________________

From report at bugs.python.org  Thu Sep 26 17:53:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Sep 2013 15:53:59 +0000
Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server
In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za>
Message-ID: <1380210839.85.0.733874193173.issue19082@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, a new issue is probably a good idea.  If the dotted attribute feature is not tested by test_xmlrpc, then the test is probably worth migrating.

I'm not sure what to do about the docs, and that should be a separate issue as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19082>
_______________________________________

From report at bugs.python.org  Thu Sep 26 18:53:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Sep 2013 16:53:58 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1380214438.58.0.863488125841.issue19009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Kristj?n, did you notice my comments on Rietveld?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Thu Sep 26 19:53:19 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 26 Sep 2013 17:53:19 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1380217999.35.0.695984375282.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Ah no actually.  Thanks . I'll respond soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Thu Sep 26 20:24:13 2013
From: report at bugs.python.org (Pepijn de Vos)
Date: Thu, 26 Sep 2013 18:24:13 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1380219853.0.0.0258259935754.issue19083@psf.upfronthosting.co.za>


Pepijn de Vos added the comment:

Ok, I signed the agreement and included a few more tests.

----------
Added file: http://bugs.python.org/file31878/upper-idna.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Thu Sep 26 20:38:55 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 26 Sep 2013 18:38:55 +0000
Subject: [issue15964] SyntaxError in asdl when building 2.7 with system Python
 3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1380220735.2.0.75906899023.issue15964@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Did anyone ended up updating the devguide about this? I can't find anything related in there.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15964>
_______________________________________

From report at bugs.python.org  Thu Sep 26 20:41:52 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Sep 2013 18:41:52 +0000
Subject: [issue13477] tarfile module should have a command line
In-Reply-To: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>
Message-ID: <1380220912.16.0.00429863710216.issue13477@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the rebase, Antoine.

Here is an updated patch:

- Adressed Serhiy's comments. I didn't add a directory parameter to the
  create command to keep the CLI simple.
- Added a test for dotless files
- Returned proper exit codes

----------
components: +Library (Lib)
Added file: http://bugs.python.org/file31879/issue13477_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13477>
_______________________________________

From report at bugs.python.org  Thu Sep 26 20:48:54 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Sep 2013 18:48:54 +0000
Subject: [issue17473] -m is not universally applicable
In-Reply-To: <1363652047.27.0.660639170602.issue17473@psf.upfronthosting.co.za>
Message-ID: <1380221334.69.0.500298412324.issue17473@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17473>
_______________________________________

From report at bugs.python.org  Thu Sep 26 21:25:44 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 26 Sep 2013 19:25:44 +0000
Subject: [issue17473] -m is not universally applicable
In-Reply-To: <1363652047.27.0.660639170602.issue17473@psf.upfronthosting.co.za>
Message-ID: <1380223544.53.0.649880808051.issue17473@psf.upfronthosting.co.za>


Changes by Claudiu.Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17473>
_______________________________________

From report at bugs.python.org  Thu Sep 26 23:01:59 2013
From: report at bugs.python.org (Hendrik Knackstedt)
Date: Thu, 26 Sep 2013 21:01:59 +0000
Subject: [issue15869] IDLE: Include .desktop file and icon
In-Reply-To: <1346929874.07.0.220677915984.issue15869@psf.upfronthosting.co.za>
Message-ID: <1380229319.31.0.0131335640549.issue15869@psf.upfronthosting.co.za>


Hendrik Knackstedt added the comment:

For the correct icon to appear you have to copy the provided .xpm file to the given location: /usr/share/pixmaps/python.xpm

This is still an issue for the current version of python 3.3.

This is really easy to fix. Simply include the files already provided. I can confirm they work on Archlinux in XFCE.

----------
nosy: +hennekn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15869>
_______________________________________

From report at bugs.python.org  Thu Sep 26 23:25:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Sep 2013 21:25:28 +0000
Subject: [issue17473] -m is not universally applicable
In-Reply-To: <1363652047.27.0.660639170602.issue17473@psf.upfronthosting.co.za>
Message-ID: <1380230728.85.0.606829285958.issue17473@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17473>
_______________________________________

From report at bugs.python.org  Fri Sep 27 00:33:17 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Sep 2013 22:33:17 +0000
Subject: [issue17473] -m is not universally applicable
In-Reply-To: <1363652047.27.0.660639170602.issue17473@psf.upfronthosting.co.za>
Message-ID: <1380234797.24.0.55107388955.issue17473@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

runpy needs to be refactored at least a bit before this will be practical. Issue 9325 is an existing issue for the same idea that discusses some of the problems to be resolved (it's a good idea, just a fair bit of work).

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Add an option to pdb/trace/profile to run library module as a script

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17473>
_______________________________________

From report at bugs.python.org  Fri Sep 27 00:34:55 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Sep 2013 22:34:55 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
 as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1380234895.4.0.456291004077.issue9325@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 17473 had a longer list of relevant modules:

pdb profile doctest trace modulefinder tabnanny pyclbr dis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Sep 27 00:38:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Sep 2013 22:38:35 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
 as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1380235115.64.0.474928760113.issue9325@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Also, the ModuleSpec PEP (PEP 451)should make the proposed refactoring much simpler, since the code runner could just expose data from the module spec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Sep 27 00:59:51 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 26 Sep 2013 22:59:51 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380236391.59.0.302020038673.issue19094@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Thanks Vajraski for the patch (especially the tests).

A colleague reminded me of an aphorism by Raymond Hettinger from the recent PyCon paraphrased: duck typing is superior to isinstance.

Maybe instead consider something like this:

diff -r 7f13d5ecf71f Lib/urllib/parse.py
--- a/Lib/urllib/parse.py	Sun Sep 22 09:33:45 2013 -0400
+++ b/Lib/urllib/parse.py	Thu Sep 26 18:52:18 2013 -0400
@@ -405,10 +405,9 @@
 def urljoin(base, url, allow_fragments=True):
     """Join a base URL and a possibly relative URL to form an absolute
     interpretation of the latter."""
-    if not base:
-        return url
-    if not url:
-        return base
+    if not base or not url:
+        # one of the inputs is empty, so simply concatenate
+        return base + url
     base, url, _coerce_result = _coerce_args(base, url)
     bscheme, bnetloc, bpath, bparams, bquery, bfragment = \
             urlparse(base, '', allow_fragments)

This implementation is not only shorter and raises TypeErrors if the types aren't compatible, but those errors are triggered by the underlying implementation. Furthermore, if either the url or base were to be a duck-type that met the necessary interface, it need not be a string subclass.

I don't feel strongly either way, but I'm slightly more inclined to accept the simpler implementation. I'm interested in the everyone's thoughts on either approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Fri Sep 27 01:04:19 2013
From: report at bugs.python.org (paul j3)
Date: Thu, 26 Sep 2013 23:04:19 +0000
Subject: [issue14365] argparse: subparsers,
 argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1380236659.69.0.466095626084.issue14365@psf.upfronthosting.co.za>


paul j3 added the comment:

Steven's patch (subparse_optionals.diff) run with jakub's test case (argparse_subparses_ambiguous_bug.py) works.  But if the input string is 

    print(parser.parse_args('--foo baz'.split()))

produces

    Namespace(cmd=None, foo='baz', foo1=None, foo2=None)

(I added the 'cmd' subparse 'dest').  

Two things seem to be going on now: 

1) '--foo' is being parsed even though its subparser is not invoked, 

2) and the subparser is not required.

The issue of whether subparsers are required or not is another issue.  They used to be required, but the testing for 'required' was changed, and subparsers fell through the crack.

I suspect that if the missing subparser error were raised, the first issue wouldn't be apparent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Fri Sep 27 01:54:42 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 26 Sep 2013 23:54:42 +0000
Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly
Message-ID: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Check out http://stackoverflow.com/questions/9327597/python-get-does-not-evaluate-to-true-even-though-there-is-an-object 

It turns out a cgi.FieldStorage object may consider itself False even when it has data.  This happens when the initialization decided to use read_single() instead of one of the other ways of reading the field value (read_urlencoded() or read_multi()).  Then self.list remains None, and __nonzero__ returns False no matter what the contents of self.file is.

To make things worse -- or better? -- the Python 3 version still defines __nonzero__() instead of __bool__().

----------
messages: 198457
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: bool(cgi.FieldStorage(...)) may be False unexpectedly
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19097>
_______________________________________

From report at bugs.python.org  Fri Sep 27 02:08:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 Sep 2013 00:08:23 +0000
Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly
In-Reply-To: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za>
Message-ID: <1380240503.86.0.0860423699494.issue19097@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

PS. Simple repro:

import cgi; bool(cgi.FieldStorage('logo', u'tux.png'))

This reveals it's been fixed in Python 3 -- it raises TypeError there as it should.  (But __nonzero__ should be deleted, and if someone adds __bool__ they should make sure it raises the same TypeError if self.list is None.)

----------
versions:  -Python 2.6, 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/issue19097>
_______________________________________

From report at bugs.python.org  Fri Sep 27 02:38:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 Sep 2013 00:38:39 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
 as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1380242319.12.0.529790615166.issue9325@psf.upfronthosting.co.za>


Eric Snow added the comment:

Soon, my precious, soon...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Sep 27 03:13:46 2013
From: report at bugs.python.org (nlevitt@gmail.com)
Date: Fri, 27 Sep 2013 01:13:46 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1380244426.74.0.654673060614.issue3982@psf.upfronthosting.co.za>


Changes by nlevitt at gmail.com <nlevitt at gmail.com>:


----------
nosy: +nlevitt at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Fri Sep 27 03:32:06 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 Sep 2013 01:32:06 +0000
Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly
In-Reply-To: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za>
Message-ID: <1380245526.33.0.833663336634.issue19097@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19097>
_______________________________________

From report at bugs.python.org  Fri Sep 27 03:44:24 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 27 Sep 2013 01:44:24 +0000
Subject: [issue19098] sys.setrecursionlimit(2**30) breaks interactive shell
Message-ID: <1380246264.16.0.783990166061.issue19098@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

sys.setrecursionlimit(2**30) breaks interactive shell in Python >=3.3.
This bug does not occur during non-interactive execution of scripts / modules.
This bug does not occur in versions of Python older than 3.3.

This bug occurs only for some range of values of recursion limit. There are higher values, which do not cause this bug.
sys.setrecursionlimit(2**31), as expected, raises OverflowError.
Values like 2**31-1 (i.e. 2147483647) cause no problem:

$ python3.4 -q
>>> import sys
>>> sys.setrecursionlimit(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum
>>> sys.setrecursionlimit(2**31-1)
>>> sys.getrecursionlimit()
2147483647
>>> 0
0
>>> 

Lower limit of values of recursion limit, which cause this bug: 715827883 == 2**29 + 2**27 + 2**25 + 2**23 + 2**21 + 2**19 + 2**17 + 2**15 + 2**13 + 2**11 + 2**9 + 2**7 + 2**5 + 2**3 + 2**1 + 1
Upper limit of values of recursion limit, which cause this bug: 1431655765 == 2**30 + 2**28 + 2**26 + 2**24 + 2**22 + 2**20 + 2**18 + 2**16 + 2**14 + 2**12 + 2**10 + 2**8 + 2**6 + 2**4 + 2**2 + 1

Example of this bug:

$ python3.4 -q
>>> import sys
>>> sys.setrecursionlimit(2**30)
>>> 0
RuntimeError: maximum recursion depth exceeded during compilation
>>> "a"
RuntimeError: maximum recursion depth exceeded during compilation
>>> 
RuntimeError: maximum recursion depth exceeded during compilation
>>>

RuntimeError occurs for each line (even empty). Ctrl+D still works.

I use 64-bit GNU/Linux.

----------
components: Interpreter Core
keywords: 3.3regression
messages: 198460
nosy: Arfrever
priority: normal
severity: normal
status: open
title: sys.setrecursionlimit(2**30) breaks interactive shell
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19098>
_______________________________________

From report at bugs.python.org  Fri Sep 27 04:22:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Sep 2013 02:22:13 +0000
Subject: [issue19098] sys.setrecursionlimit(2**30) breaks interactive shell
In-Reply-To: <1380246264.16.0.783990166061.issue19098@psf.upfronthosting.co.za>
Message-ID: <3cmGx05mv2z7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset c3df31cbcd0a by Benjamin Peterson in branch '3.3':
don't scale compiler stack frames if the recursion limit is huge (closes #19098)
http://hg.python.org/cpython/rev/c3df31cbcd0a

New changeset 9a7ec433bf59 by Benjamin Peterson in branch 'default':
merge 3.3 (#19098)
http://hg.python.org/cpython/rev/9a7ec433bf59

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19098>
_______________________________________

From report at bugs.python.org  Fri Sep 27 07:21:49 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 27 Sep 2013 05:21:49 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380259309.63.0.110431179333.issue19094@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

What about this one?

>>> urljoin(['a'], [])
['a']
>>> urljoin(['a'], ['b'])
..... omitted ......
AttributeError: 'list' object has no attribute 'decode'

Is this desirable? Both patches missed this case. Should we only accept str and bytes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Fri Sep 27 07:40:12 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 27 Sep 2013 05:40:12 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1380260412.85.0.284956427649.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Here's the obvious minimal patch that removes the non-public 'root' attribute. Please apply it for Py3.4 and then set the version tag of this ticket to Py3.5 (instead of closing it, because it's not resolved yet).

As I said, the expected thing to do (and what lxml.etree will do in its next release) is to behave like XMLParser. Reverting the new patch for Py3.5 and applying the old one will achieve that nicely, including the proper test adaptations.

----------
Added file: http://bugs.python.org/file31880/xmlpullparser_remove_public_root_attr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Fri Sep 27 10:05:55 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Sep 2013 08:05:55 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
 as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1380269155.35.0.821563351098.issue9325@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Fri Sep 27 10:22:07 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Sep 2013 08:22:07 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1380270127.65.0.390533486661.issue18864@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Fri Sep 27 10:28:07 2013
From: report at bugs.python.org (Musashi Tamura)
Date: Fri, 27 Sep 2013 08:28:07 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
Message-ID: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>


New submission from Musashi Tamura:

C:\>python
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack(u'B',1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not unicode
>>> struct.pack(u'B',1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not unicode
>>> struct.pack('B',1) # this is ok
'\x01'
>>> struct.pack(u'B',1)
'\x01'

----------
components: Unicode
messages: 198464
nosy: ezio.melotti, miwa
priority: normal
severity: normal
status: open
title: struct.pack fails first time with unicode fmt
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Fri Sep 27 13:05:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 11:05:10 +0000
Subject: [issue19100] Use backslashreplace in pprint
Message-ID: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently pprint.pprint() fails on unencodable characters.

$ LANG=en_US.utf8 ./python -c "import pprint; pprint.pprint('\u20ac')"
'?'
$ LANG= ./python -c "import pprint; pprint.pprint('\u20ac')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pprint.py", line 56, in pprint
    printer.pprint(object)
  File "/home/serhiy/py/cpython/Lib/pprint.py", line 137, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/home/serhiy/py/cpython/Lib/pprint.py", line 274, in _format
    write(rep)
UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 1: ordinal not in range(128)

This is a regression from Python 2 in which repr() always returns ascii string.

$ LANG= python2.7 -c "import pprint; pprint.pprint(u'\u20ac')"
u'\u20ac'

Perhaps pprint() should use the backslashreplace error handler (as sys.displayhook()). With the proposed patch:

$ LANG= ./python -c "import pprint; pprint.pprint('\u20ac')"
'\u20ac'

----------
components: Library (Lib), Unicode
files: pprint_unencodable.patch
keywords: patch
messages: 198465
nosy: ezio.melotti, fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use backslashreplace in pprint
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31881/pprint_unencodable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Fri Sep 27 13:15:34 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Sep 2013 11:15:34 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
Message-ID: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Can you fix this before I tag 3.4a3 please?

----------
assignee: pitrou
components: Build
keywords: buildbot
messages: 198466
nosy: larry, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 13:41:08 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Sep 2013 11:41:08 +0000
Subject: [issue19102] Add tests for CLI of the tabnanny module
Message-ID: <1380282068.15.0.580247887303.issue19102@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I was trying to use the argparse module instead of getopt and I couldn't find any tests for CLI of the tabnanny module.

----------
components: Tests
files: test_tabnanny.diff
keywords: patch
messages: 198467
nosy: berker.peksag
priority: low
severity: normal
stage: patch review
status: open
title: Add tests for CLI of the tabnanny module
versions: Python 3.4
Added file: http://bugs.python.org/file31882/test_tabnanny.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19102>
_______________________________________

From report at bugs.python.org  Fri Sep 27 13:41:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 11:41:47 +0000
Subject: [issue19103] Use pprint in displayhook
Message-ID: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint.pprint() produces more human readable output than print(repr()) which is used in sys.displayhook(). The proposed patch changes sys.displayhook in site.py. You still can access original displayhook as sys.__displayhook__.

----------
files: displayhook_pprint.patch
keywords: patch
messages: 198468
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use pprint in displayhook
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31883/displayhook_pprint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19103>
_______________________________________

From report at bugs.python.org  Fri Sep 27 13:53:48 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 27 Sep 2013 11:53:48 +0000
Subject: [issue19009] Enhance HTTPResponse.readline() performance
In-Reply-To: <1379079570.46.0.352920817481.issue19009@psf.upfronthosting.co.za>
Message-ID: <1380282828.95.0.0161488709501.issue19009@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

A new patch set, in response to Serhiy's comments on Rietveld.

----------
Added file: http://bugs.python.org/file31884/httpresponse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19009>
_______________________________________

From report at bugs.python.org  Fri Sep 27 13:59:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Sep 2013 11:59:46 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>
Message-ID: <1380283186.18.0.575734287018.issue19101@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

When pointing to a buildbot, please remember posting a URL, it makes things easier :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 14:01:00 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Sep 2013 12:01:00 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>
Message-ID: <1380283260.27.0.0801420849676.issue19101@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Sorry, here:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 14:13:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Sep 2013 12:13:04 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>
Message-ID: <1380283984.56.0.232047655367.issue19101@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Haha, thank you. So, this is the exact same problem that running "hg touch" on the buildbots was supposed to prevent :-)

Well, at least the fix should be next to trivial.

----------
components: +Demos and Tools -Build
keywords: +easy
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 15:12:18 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Sep 2013 13:12:18 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>
Message-ID: <1380287538.5.0.596097092157.issue19101@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

ac5343148fb3

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 15:40:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 13:40:51 +0000
Subject: [issue19104] pprint produces invalid output for long strings
Message-ID: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The documentation says:
"""The pprint module provides a capability to ?pretty-print? arbitrary Python data structures in a form which can be used as input to the interpreter."""

But #since issue17150 long lines are splitted on shorter lines without continuation character and the result can't be used as input to the interpreter.

>>> pprint.pprint('abc '*20)
'abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc abc '\
'abc '

----------
components: Library (Lib)
keywords: easy
messages: 198474
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: pprint produces invalid output for long strings
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 15:50:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 13:50:34 +0000
Subject: [issue19105] pprint doesn't use all width
Message-ID: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint not only adds indentation, but also increases right margin for nested items.

>>> pprint.pprint([' '.join(str(i) for i in range(30))]*2)
['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 '
 '28 29',
 '0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 '
 '28 29']
>>> pprint.pprint([[[[[[[[[[[[' '.join(str(i) for i in range(30))]]]]]]]]]]]]*2)
[[[[[[[[[[[['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 '
            '21 22 23 24 25 26 27 28 29']]]]]]]]]]],
 [[[[[[[[[[['0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 '
            '21 22 23 24 25 26 27 28 29']]]]]]]]]]]]

As you can see in second example there is a place for at least '21 22 23 ' at the right. In case of multiline representation of nested items pprint can reserve space only at the end of last line and continue inner lines to full width.

----------
components: Library (Lib)
messages: 198475
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: pprint doesn't use all width
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19105>
_______________________________________

From report at bugs.python.org  Fri Sep 27 16:07:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Sep 2013 14:07:52 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>
Message-ID: <1380290872.44.0.530222909365.issue19101@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This should be fixed in 2.7 too.

----------
assignee: pitrou -> benjamin.peterson
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 16:11:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 14:11:59 +0000
Subject: [issue19103] Use pprint in displayhook
In-Reply-To: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>
Message-ID: <1380291119.64.0.589906981643.issue19103@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In second patch the COLUMNS environment variable is used to determine pprint's width.

----------
Added file: http://bugs.python.org/file31885/displayhook_pprint_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19103>
_______________________________________

From report at bugs.python.org  Fri Sep 27 16:20:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Sep 2013 14:20:22 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380291622.96.0.679122730551.issue19104@psf.upfronthosting.co.za>


R. David Murray added the comment:

FYI this defect was mentioned (by Antoine) in Issue17530, though that issue is about bytes.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:06:35 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Sep 2013 15:06:35 +0000
Subject: [issue19101] "make touch" broke "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1380280534.57.0.0092887507305.issue19101@psf.upfronthosting.co.za>
Message-ID: <1380294395.01.0.00487300759459.issue19101@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

2.7 doesn't have hgtouch.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19101>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:09:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 15:09:22 +0000
Subject: [issue17530] pprint could use line continuation for long bytes
 literals
In-Reply-To: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za>
Message-ID: <1380294562.2.0.0250437923489.issue17530@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17530>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:11:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 15:11:11 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380294671.54.0.453486178105.issue19104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you David. In any case this is worth a separate issue.

Here is a patch. Personally I prefer to add continuation backslash even for inner wrapped lines, but I'm not sure that most core developers will agreed with it.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31886/pprint_str_evaluable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:12:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 15:12:04 +0000
Subject: [issue19103] Use pprint in displayhook
In-Reply-To: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>
Message-ID: <1380294724.75.0.668056880061.issue19103@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Use backslashreplace in pprint, pprint produces invalid output for long strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19103>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:13:40 2013
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 27 Sep 2013 15:13:40 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <1380294820.42.0.226826227579.issue19030@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Note: there is a comment explaining the point of _RouteClassAttributeToGetattr right above the Enum.name and Enum.value methods you changed (now at line 474). You may want to update that comment now.

----------
nosy: +mjpieters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:25:57 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Sep 2013 15:25:57 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
Message-ID: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

Background: we'd like to enable running 'make touch' on the bots before 'make -jN', to avoid problems with scripts that auto-generate code for the Python build (bootstrapping). pydev thread: https://mail.python.org/pipermail/python-dev/2013-September/128992.html

A couple of issues are prerequisites:

1. Fix the asdl dependencies in .hgtouch:

Include/ast.h: Parser/Python.asdl Parser/asdl.py Parser/asdl_c.py
Python/Python-ast.c: Include/ast.h

The file Include/ast.h is not, in fact, auto-generated. But Include/Python-ast.h *is*, and it does not appear in this file.

2. Make sure 'hg touch' itself runs on Python 2.4 because that's what some bots have (and other older systems like RHEL 5)

----------
assignee: eli.bendersky
components: Build
messages: 198482
nosy: eli.bendersky, ezio.melotti, loewis, pitrou
priority: normal
severity: normal
status: open
title: Prepare .hgtouch and Tools/hg/hgtouch.py to run on the bots
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:45:18 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 27 Sep 2013 15:45:18 +0000
Subject: [issue19107] CSV output of benchmark runner tries to write to binary
 file
Message-ID: <1380296718.47.0.355256132109.issue19107@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The perf.py script opens the file for CSV output in binary mode, which no longer works in Py3:

Index: perf.py
===================================================================
--- perf.py     (Revision 80409)
+++ perf.py     (Arbeitskopie)
@@ -2443,7 +2448,7 @@
         raise ValueError("Invalid output_style: %r" % options.output_style)
 
     if options.csv:
-        with open(options.csv, "wb") as f:
+        with open(options.csv, "w") as f:
             writer = csv.writer(f)
             writer.writerow(['Benchmark', 'Base', 'Changed'])
             for name, result in results:

----------
components: Benchmarks
messages: 198483
nosy: scoder
priority: normal
severity: normal
status: open
title: CSV output of benchmark runner tries to write to binary file
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19107>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:45:44 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 27 Sep 2013 15:45:44 +0000
Subject: [issue19107] CSV output of benchmark runner tries to write to binary
 file
In-Reply-To: <1380296718.47.0.355256132109.issue19107@psf.upfronthosting.co.za>
Message-ID: <1380296744.14.0.425921044571.issue19107@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +brett.cannon, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19107>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:48:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Sep 2013 15:48:26 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <3cmcqF6bVNz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset ac19ff225280 by Eli Bendersky in branch 'default':
Fix .hgtouch to list the dependencies for auto-generated AST code correctly.
http://hg.python.org/cpython/rev/ac19ff225280

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:49:35 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Sep 2013 15:49:35 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <1380296975.36.0.414074993497.issue19016@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg198484

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:52:16 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Sep 2013 15:52:16 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380297136.27.0.295297158621.issue19106@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

.hgtouch fixed in ac19ff225280 (I specified the issue number incorrectly so this one wasn't notified).

Curiously, `make touch` seems to think there's still things to do even after the first round of "touching":

$ touch Parser/asdl_c.py 
$ make touch
hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
Touching Include/Python-ast.h
Touching Python/Python-ast.c
$ make touch
hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
Touching Python/Python-ast.c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Fri Sep 27 17:53:51 2013
From: report at bugs.python.org (Michael Foord)
Date: Fri, 27 Sep 2013 15:53:51 +0000
Subject: [issue19016] autospecced namedtuples should be truthy by default
In-Reply-To: <1379151405.44.0.0889223840628.issue19016@psf.upfronthosting.co.za>
Message-ID: <1380297231.36.0.159380524213.issue19016@psf.upfronthosting.co.za>


Michael Foord added the comment:

I dislike adding namedtuple specific code to mock. How many different types should we special case here and in other places?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19016>
_______________________________________

From report at bugs.python.org  Fri Sep 27 18:00:36 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 27 Sep 2013 16:00:36 +0000
Subject: [issue19108] Benchmark runner tries to execute external Python
 command and fails on error reporting
Message-ID: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

In changeset 88b6ef9aa9e9, a new function ported_lib() was added that crashes on error reporting in Py3 because it tries to do this:

    raise RuntimeError("Benchmark died: " + err)

"err" is a bytes object that comes straight from the subprocess pipe.

The reason why I noticed this is because the new function assumes that it can run "python" with the "-c" option and pass an arbitrary Python command string. That may not be true if it is actually executing some wrapper script (as we do for Cython, for example). Currently, the only requirement for the external Python command is that it can run a Python script that it receives on the command line. We shouldn't unnecessarily extend that interface.

I'm not sure how to best fix this, but the only way I can currently see is to run an external Python script that prints the requested information.

----------
components: Benchmarks
messages: 198487
nosy: brett.cannon, pitrou, scoder
priority: normal
severity: normal
status: open
title: Benchmark runner tries to execute external Python command and fails on error reporting
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19108>
_______________________________________

From report at bugs.python.org  Fri Sep 27 18:11:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Sep 2013 16:11:46 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380298306.18.0.216259795162.issue19104@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

According to PEP 8, parentheses should be used for multi-line expressions, not backslashes:

"""The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation."""

Also, please note that in both cases it adds a character to the lines, which must be taken into account in the algorithm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 18:20:33 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Sep 2013 16:20:33 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380298833.48.0.742991843527.issue19106@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Ooh, I think that's because the "# try processing all rules in topological order" in do_touch doesn't actually topo-sort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Fri Sep 27 19:00:26 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Sep 2013 17:00:26 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380301226.19.0.659298990138.issue19106@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The problem in this case is different, actually. It's the comparison:

        if o_time <= i_time:
            # generated file is older, touch
            need_touch = True

In check_rule. The script is pretty quick so when it touches both Python-ast.h and .c they get the same stat time exactly. In the next run, then, this comparison succeeds and .c is touched again.

I'm not sure what's the right way to go about this? Changing the comparison to < may theoretically miss cases in which the input was updated an epsilon after it auto-generated its output, and the change will go unnoticed. A different solution would be to introduce a micro-wait between each 'touch' to make sure that transitive dependencies don't need to be revisited in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Fri Sep 27 19:01:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 17:01:55 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380301315.23.0.995654576085.issue19104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Second path uses parentheses. It is more complicated than first patch.

I prefer first patch, because it is simple, because second variant wastes more width, because parentheses looks too similar to tuple, and because "implicit string literal concatenation considered harmful"[1].

http://comments.gmane.org/gmane.comp.python.ideas/20525

----------
Added file: http://bugs.python.org/file31887/pprint_str_evaluable_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 19:17:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Sep 2013 17:17:46 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380302266.03.0.360863681752.issue19104@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> "implicit string literal concatenation considered harmful"

Both patches rely on implicit string literal concatenation.

Another possibility is not fixing this issue, and deciding it is normal behaviour. It is trivial to add parentheses if you need them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 19:40:02 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 27 Sep 2013 17:40:02 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380303602.87.0.161397822687.issue19094@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I don't mind the AttributeError - that's a reasonable exception when passing invalid types in, and that's in fact the current behavior. The example of (['a'], []) does bother me though. Those inputs are also seemingly invalid, though somewhat more compatible from a 'urljoin' perspective than two different types.

You've given me reason to re-consider your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:12:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 18:12:23 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380305543.11.0.339323038259.issue19104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Both patches rely on implicit string literal concatenation.

But with backslash it *looks* less implicit.

> Another possibility is not fixing this issue, and deciding it is normal behaviour. It is trivial to add parentheses if you need them.

It would be safer just do not wrap long line on first level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:22:29 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Sep 2013 18:22:29 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380306149.92.0.548693764965.issue19089@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Brain Curtin]
> Ctrl-Z and Ctrl-D simply have different meanings 
> on the different platforms, outside of what Python does.
> We already can't make Ctrl-Z on Windows do what it does
> on Linux, and Ctrl-D is not natural to Windows users.

I concur.

It would be a mistake to violate the O/S standards and norms.
I recommend this issue be closed.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:22:48 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Sep 2013 18:22:48 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380306168.09.0.612641458547.issue19089@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low
type:  -> enhancement
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:23:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Sep 2013 18:23:58 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>
Message-ID: <1380306238.61.0.942767691986.issue19086@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:32:25 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 27 Sep 2013 18:32:25 +0000
Subject: [issue19089] Windows: Make Ctrl-D exit key combination cross-platform
In-Reply-To: <1380126755.68.0.168934663193.issue19089@psf.upfronthosting.co.za>
Message-ID: <1380306745.69.0.201932551638.issue19089@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Closing as rejected.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19089>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:40:39 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Sep 2013 18:40:39 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>
Message-ID: <1380307239.45.0.484925032555.issue19086@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, the reason for __builtin__.sum() having a start argument was so that it could change the base datatype:   sum(iterable, start=Fraction(0)).

[Oscar Benjamin]
> Although fsum is internally very accurate 
> it always discards information on output.

A "start" argument won't help you, because you will discard information on input.  A sequence like [1E100, 0.1, -1E100, 0.1] wouldn't work when split into subtotal=fsum([1E100, 0.1]) and fsum([-1E100, 0.1], start=subtotal).

> My motivation for this is that I want to be able to write 
> an efficient sum function that is accurate for a mix of ints
> and floats

FWIW, fsum() already works well with integers as long as they don't exceed 53bits of precision.  For such exotic use cases, the decimal module would be a better alternative.  Now that the decimal module has a C implementation, there is no reason not to use it for high precision applications.

It is possible to extent the current fsum() implementation to separately track integers and combine it with the float results at the end.   That said, the probability that any user (other than yourself) will need this can only be expressed as a denormal number ;-)

I'm not rejecting the request; rather, I'm questioning the need for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Fri Sep 27 20:50:24 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Sep 2013 18:50:24 +0000
Subject: [issue19109] 'TestTCPServer' is not defined
Message-ID: <1380307824.33.0.292776020503.issue19109@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The Win32 buildbots just started failing:

http://buildbot.python.org/all/waterfall?category=3.x.stable

They fail with this traceback:

test test_logging crashed -- Traceback (most recent call last):
  File "../lib/test/regrtest.py", line 1269, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\importlib\__init__.py", line 95, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1613, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1594, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1561, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 607, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1056, in load_module
  File "<frozen importlib._bootstrap>", line 926, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _call_with_frames_removed
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_logging.py", line 1365, in <module>
    class SocketHandlerTest(BaseTest):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_logging.py", line 1369, in SocketHandlerTest
    server_class = TestTCPServer
NameError: name 'TestTCPServer' is not defined

I took a quick look at it and the code seemed fine... but obviously there's something going on.

Can you try to fix this before I cut 3.4a3 tomorrow?

----------
assignee: vinay.sajip
components: Tests
keywords: buildbot
messages: 198498
nosy: larry, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: 'TestTCPServer' is not defined
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19109>
_______________________________________

From report at bugs.python.org  Fri Sep 27 21:15:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Sep 2013 19:15:21 +0000
Subject: [issue19053] read1() from zipfile returns empty data
In-Reply-To: <1379604556.3.0.19871630565.issue19053@psf.upfronthosting.co.za>
Message-ID: <3cmjQ02Zvvz7Ljq@mail.python.org>


Roundup Robot added the comment:

New changeset 460b0ccbab7f by Serhiy Storchaka in branch '3.3':
Issue #19053: ZipExtFile.read1() with non-zero argument no more returns empty
http://hg.python.org/cpython/rev/460b0ccbab7f

New changeset f1c6e7f86bbc by Serhiy Storchaka in branch 'default':
Issue #19053: ZipExtFile.read1() with non-zero argument no more returns empty
http://hg.python.org/cpython/rev/f1c6e7f86bbc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19053>
_______________________________________

From report at bugs.python.org  Fri Sep 27 21:34:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Sep 2013 19:34:32 +0000
Subject: [issue19053] read1() from zipfile returns empty data
In-Reply-To: <1379604556.3.0.19871630565.issue19053@psf.upfronthosting.co.za>
Message-ID: <1380310472.64.0.347203457385.issue19053@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19053>
_______________________________________

From report at bugs.python.org  Fri Sep 27 21:46:53 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Fri, 27 Sep 2013 19:46:53 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1380311213.35.0.67630667276.issue18314@psf.upfronthosting.co.za>


Kim Gr?sman added the comment:

_delete_junction_point currently shells out to a command-line tool, junction.exe, from SysInternals. That ran fine on XP.

As I understand it, RemoveDirectoryW on XP also takes care of junction points, but I'll find a machine to verify.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Fri Sep 27 22:34:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Sep 2013 20:34:22 +0000
Subject: [issue5710] ctypes should return composite types from callbacks
In-Reply-To: <1239038926.27.0.792638874347.issue5710@psf.upfronthosting.co.za>
Message-ID: <1380314062.61.0.640511382344.issue5710@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: theller -> 
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5710>
_______________________________________

From report at bugs.python.org  Fri Sep 27 22:51:28 2013
From: report at bugs.python.org (Mason Bially)
Date: Fri, 27 Sep 2013 20:51:28 +0000
Subject: [issue5710] ctypes should return composite types from callbacks
In-Reply-To: <1239038926.27.0.792638874347.issue5710@psf.upfronthosting.co.za>
Message-ID: <1380315088.52.0.652839903491.issue5710@psf.upfronthosting.co.za>


Mason Bially added the comment:

I agree with Amaury that this is purely a user side concern. While I think it's important to note the behaviour of ctypes in the case that Thomas describes, I believe it's more important to fully support the range of behaviours allowed by C function callbacks.

I see the use cases for complex return types that don't fall under the concerns raised by Thomas as the following:

* Returning a pointer to already existing memory.
* Returning complex value types (structs of ints, doubles, chars, ect). This is especially important from a compatibility standpoint for C libraries which expect such return types.

Because I need this for my current project I will work on writing a patch.

----------
nosy: +Mason.Bially

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5710>
_______________________________________

From report at bugs.python.org  Fri Sep 27 22:53:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Sep 2013 20:53:08 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380305543.11.0.339323038259.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380315185.2508.0.camel@fsol>


Antoine Pitrou added the comment:

> > Another possibility is not fixing this issue, and deciding it is
> normal behaviour. It is trivial to add parentheses if you need them.
> 
> It would be safer just do not wrap long line on first level.

That would defeat the whole point of pprint().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Fri Sep 27 23:10:41 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 27 Sep 2013 21:10:41 +0000
Subject: [issue19109] 'TestTCPServer' is not defined
In-Reply-To: <1380307824.33.0.292776020503.issue19109@psf.upfronthosting.co.za>
Message-ID: <1380316241.77.0.128285704769.issue19109@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

It's to do whether threading is available or not (not Windows related, AFAICT) ... I have corrected the code and it now seems to be OK - the few buildbots that are red seem to be failing on other things.

I'll leave it to you to verify this and close this issue, but will try to keep an eye out for any further information on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19109>
_______________________________________

From report at bugs.python.org  Sat Sep 28 05:46:35 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 28 Sep 2013 03:46:35 +0000
Subject: [issue19067] Built-in range docstrings are not PEP-8 compatible
In-Reply-To: <1379833275.25.0.770459256521.issue19067@psf.upfronthosting.co.za>
Message-ID: <1380339995.22.0.911848130274.issue19067@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19067>
_______________________________________

From report at bugs.python.org  Sat Sep 28 05:46:41 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 28 Sep 2013 03:46:41 +0000
Subject: [issue19069] Built-in float docstrings are not PEP-8 compatible
In-Reply-To: <1379834291.01.0.660875879281.issue19069@psf.upfronthosting.co.za>
Message-ID: <1380340001.77.0.99812787942.issue19069@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19069>
_______________________________________

From report at bugs.python.org  Sat Sep 28 05:47:15 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 28 Sep 2013 03:47:15 +0000
Subject: [issue19068] Some built-in complex docstrings are not PEP-8 compatible
In-Reply-To: <1379833742.32.0.289149108308.issue19068@psf.upfronthosting.co.za>
Message-ID: <1380340035.86.0.487935887504.issue19068@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19068>
_______________________________________

From report at bugs.python.org  Sat Sep 28 06:35:29 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 Sep 2013 04:35:29 +0000
Subject: [issue19069] Built-in float docstrings are not PEP-8 compatible
In-Reply-To: <1379834291.01.0.660875879281.issue19069@psf.upfronthosting.co.za>
Message-ID: <1380342929.25.0.970749672461.issue19069@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please don't flood the tracker with these individual reports.  Present a single consolidated patch in Issue 19069.

----------
nosy: +rhettinger
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19069>
_______________________________________

From report at bugs.python.org  Sat Sep 28 06:38:03 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 Sep 2013 04:38:03 +0000
Subject: [issue19067] Built-in range docstrings are not PEP-8 compatible
In-Reply-To: <1379833275.25.0.770459256521.issue19067@psf.upfronthosting.co.za>
Message-ID: <1380343083.8.0.134364805515.issue19067@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19067>
_______________________________________

From report at bugs.python.org  Sat Sep 28 07:58:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 05:58:23 +0000
Subject: [issue19011] Enum should have a __getattr__ that makes all the
 instances available from an instance
In-Reply-To: <1379091343.71.0.460469461761.issue19011@psf.upfronthosting.co.za>
Message-ID: <3cmzgy5WBfz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 47fb6b078b5f by Ethan Furman in branch 'default':
Close #19011:  Add documentation on some of the non-standard Enum behavior.
http://hg.python.org/cpython/rev/47fb6b078b5f

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19011>
_______________________________________

From report at bugs.python.org  Sat Sep 28 07:59:24 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 28 Sep 2013 05:59:24 +0000
Subject: [issue19040] Problems with overriding Enum.__new__
In-Reply-To: <1379412637.64.0.0140304446713.issue19040@psf.upfronthosting.co.za>
Message-ID: <1380347964.55.0.0904700326167.issue19040@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19040>
_______________________________________

From report at bugs.python.org  Sat Sep 28 08:02:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 06:02:11 +0000
Subject: [issue19030] inspect.getmembers and inspect.classify_class_attrs
 mishandle descriptors
In-Reply-To: <1379289654.59.0.452504541982.issue19030@psf.upfronthosting.co.za>
Message-ID: <3cmzmL3wXgz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 96081e7526f0 by Ethan Furman in branch 'default':
Issue19030: fixed comment that was still referring to a changed descriptor.
http://hg.python.org/cpython/rev/96081e7526f0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19030>
_______________________________________

From report at bugs.python.org  Sat Sep 28 08:32:35 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 28 Sep 2013 06:32:35 +0000
Subject: [issue14365] argparse: subparsers,
 argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1380349955.82.0.292203483103.issue14365@psf.upfronthosting.co.za>


paul j3 added the comment:

I think the correction to the problem that I noted in the previous post is to return 'None, arg_string, None', rather than 'action, arg_string, None' in the case where the action is found in a subparser.

This is what '_parse_optional' does at the end:

        # it was meant to be an optional but there is no such option
        # in this parser (though it might be a valid option in a subparser)
        return None, arg_string, None

An input like '--foo baz' would then produce an 'invalid choice' error.  Since '--foo' is an optional that the primary parser does not recognize, 'baz' in interpreted as a positional, in this case an invalid subparser choice.

I'm working on cleaning up a test script.

----------
Added file: http://bugs.python.org/file31888/subparser_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Sat Sep 28 08:35:15 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 28 Sep 2013 06:35:15 +0000
Subject: [issue14365] argparse: subparsers,
 argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1380350115.68.0.269530001395.issue14365@psf.upfronthosting.co.za>


paul j3 added the comment:

In the last patch, 'parser.scan = True' is needed to activate this fix.  I left that switch in for testing convenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Sat Sep 28 10:37:16 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 28 Sep 2013 08:37:16 +0000
Subject: [issue19110] PEP-0 history link is broken
Message-ID: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

See http://www.python.org/dev/peps/, click Last-Modified.

----------
assignee: docs at python
components: Documentation
messages: 198509
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: PEP-0 history link is broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19110>
_______________________________________

From report at bugs.python.org  Sat Sep 28 11:02:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 28 Sep 2013 09:02:46 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380358966.63.0.984289401772.issue19094@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I modified the patch to handle the last case using your way as well.

Anyway, I found out that urlsplit and urlparse got the same issue as well.

>>> urlparse('python.org', b'http://')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sky/Code/python/programming_language/cpython/Lib/urllib/parse.py", line 292, in urlparse
    url, scheme, _coerce_result = _coerce_args(url, scheme)
  File "/home/sky/Code/python/programming_language/cpython/Lib/urllib/parse.py", line 109, in _coerce_args
    raise TypeError("Cannot mix str and non-str arguments")
TypeError: Cannot mix str and non-str arguments
>>> urlparse('python.org', b'')
ParseResult(scheme=b'', netloc='', path='python.org', params='', query='', fragment='')
>>> urlparse('python.org', 0)
ParseResult(scheme=0, netloc='', path='python.org', params='', query='', fragment='')

Same thing happens in urlsplit. Fortunately, urlunsplit and urlunparse don't have this issue.

----------
Added file: http://bugs.python.org/file31889/urljoin_throws_type_error_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Sat Sep 28 11:23:39 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 Sep 2013 09:23:39 +0000
Subject: [issue18990] Return root element from
 ElementTree.XMLPullParser.close() to match ElementTree.XMLParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1380360219.58.0.205345227167.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Eli didn't explicitly comment on the patch so far, but let me quote some of his earlier comments:

> if the reader discards parts of the tree (by deleting subtrees), then returning the root from close() becomes even more meaningless, because it's no longer the root and we have no idea what it actually is.

Meaning: ".root" is definitely the wrong name for this attribute.

> The API is well defined by the documentation. All the rest is implementation details.

Meaning: ".root" is not a public attribute, the existing (functionally equivalent and therefore redundant) "._root" is enough and makes it clear(er) for readers of the source code that the attribute is really non-public.

I read these as a clear expression of consensus that the public ".root" attribute is not supposed to exist at all. So, given that the next alpha release is due tomorrow, I'd like to see my latest patch applied by then in order to finally move at least a tiny step forward with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 28 15:43:17 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Sep 2013 13:43:17 +0000
Subject: [issue19001] test_gdb fails on Fedora buildbot
In-Reply-To: <1379836572.1.0.0817147078781.issue19001@psf.upfronthosting.co.za>
Message-ID: <20130928134318.GA16214@sleipnir.bytereef.org>


Stefan Krah added the comment:

Nick Coghlan <report at bugs.python.org> wrote:
> My F19 system (which works) shows gdb-7.6-34, while the new debugging output Antoine added shows 7.3.50.20110722-16.fc16 on F16
> 
> Maybe the new gdb version check needs to be looking for 7.4+ rather than 7.3+?

Yes, probably. We've already had another problem with the strange gdb version
on Fedora 16.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19001>
_______________________________________

From report at bugs.python.org  Sat Sep 28 15:47:31 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Sep 2013 13:47:31 +0000
Subject: [issue18990] Remove root attribute from XMLPullParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1380376051.12.0.441779306547.issue18990@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Return root element from ElementTree.XMLPullParser.close() to match ElementTree.XMLParser -> Remove root attribute from XMLPullParser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 28 15:50:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 13:50:56 +0000
Subject: [issue18990] Remove root attribute from XMLPullParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <3cnB9D03cdz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset c5e206b9df2e by Nick Coghlan in branch 'default':
Close #18990: remove root attribute from XMLPullParser
http://hg.python.org/cpython/rev/c5e206b9df2e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 28 15:54:18 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Sep 2013 13:54:18 +0000
Subject: [issue18990] Remove root attribute from XMLPullParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1380376458.57.0.659099505936.issue18990@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

We're not changing XMLPullParser.close() to return anything other than None, so the unit tests now check for this, and this behaviour is explicitly documented with users redirected towards read_events() instead.

This is consistent with the XMLParser.close() API, since what to return is up to the target, and the implicit custom target for XMLPullParser is designed for the events to be consumed in a stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:02:44 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 Sep 2013 14:02:44 +0000
Subject: [issue18990] Remove root attribute from XMLPullParser
In-Reply-To: <1378755153.57.0.030045234206.issue18990@psf.upfronthosting.co.za>
Message-ID: <1380376964.34.0.829024644049.issue18990@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Thanks, Nick. Your changes look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18990>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:28:27 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Sep 2013 14:28:27 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380378507.57.0.378544631949.issue19078@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Yes, len() should return the number of items. +1 for making reversed()
work.

NumPy does this:

>>> x = numpy.array([1,2,3,4,5,6,7,8])
>>> list(reversed(x))
[8, 7, 6, 5, 4, 3, 2, 1]
>>>
>>> x = numpy.array([[1,2,3], [4,5,6]])
>>> list(reversed(x))
[array([4, 5, 6]), array([1, 2, 3])]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:29:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 14:29:15 +0000
Subject: [issue18596] enable usage of AddressSanitizer in CPython [PATCH]
In-Reply-To: <1375174359.28.0.546907495292.issue18596@psf.upfronthosting.co.za>
Message-ID: <3cnC1Q5wDKz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset f6792f734fcc by Nick Coghlan in branch 'default':
Close #18596: Support address sanity checking in clang/GCC
http://hg.python.org/cpython/rev/f6792f734fcc

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18596>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:30:09 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Sep 2013 14:30:09 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380378609.56.0.898994659504.issue19078@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Hmm, I meant: Number of items in the first dimension, thus 4 in
Claudiu's example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:31:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Sep 2013 14:31:00 +0000
Subject: [issue18596] enable usage of AddressSanitizer in CPython [PATCH]
In-Reply-To: <1375174359.28.0.546907495292.issue18596@psf.upfronthosting.co.za>
Message-ID: <1380378660.66.0.468868745175.issue18596@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Incorporated, but as Charles-Fran?ois noted, a buildbot running with it enabled would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18596>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:46:27 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Sat, 28 Sep 2013 14:46:27 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380307239.45.0.484925032555.issue19086@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxSN-ps8LA48+U3qRWtMpMCYhdQkZj9QHOmc4Cavq7-89w@mail.gmail.com>


Oscar Benjamin added the comment:

Thanks for responding Raymond.

Raymond Hettinger wrote:
> A "start" argument won't help you, because you will discard information
on input.  A sequence like [1E100, 0.1, -1E100, 0.1] wouldn't work when
split into subtotal=fsum([1E100, 0.1]) and fsum([-1E100, 0.1],
start=subtotal).

I'm not sure if you've fully understood the proposal.

The algorithm underlying fsum is (I think) called distillation. It
compresses a list of floats into a shorter list of non-overlapping floats
having the same exact sum. Where fsum deviates from this idea is that it
doesn't return a list of floats, rather it returns only the largest float.
My proposal is that there be a way to tell fsum to return the list of
floats whose sum is exact and not rounded. Specifically the subtotal that
is returned and fed back into fsum would be a list of floats and no
information would be discarded. So fsum(numbers, []) would return a list of
floats and that list can be passed back in again.

> > My motivation for this is that I want to be able to write
> > an efficient sum function that is accurate for a mix of ints
> > and floats
>
> FWIW, fsum() already works well with integers as long as they don't
exceed 53bits of precision.

I was simplifying the use-case somewhat. I would also like this sum
function to work with fractions and decimals neither of which coerces
exactly to float (and potentially I want some non-stdlib types also).

>  For such exotic use cases, the decimal module would be a better
alternative.  Now that the decimal module has a C implementation, there is
no reason not to use it for high precision applications.

It is possible to coerce to Decimal and exactly sum a list of ints, floats
and decimals (by trapping inexact and increasing the context precision). I
have tried this under CPython 3.3 and it was 20-50x slower than fsum
depending on how it manages the arithmetic context and whether it can be
used safely with a generator that also manipulates the context - the safe
version that doesn't build a list is 50x slower. It is also not possible to
use Decimal exactly with Fractions.

I believe that there are other use-cases for having fsum be usable
incrementally. This would make it usable for accurate summation in
incremental, parallel and distributed computation also. Unfortunately fsum
itself already isn't used as much as it should be and I agree that probably
all the use cases for this extension would be relatively obscure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:52:33 2013
From: report at bugs.python.org (Peter)
Date: Sat, 28 Sep 2013 14:52:33 +0000
Subject: [issue19111] 2to3 should remove from future_builtins import *
Message-ID: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za>


New submission from Peter:

The 2to3 script should remove lines like this:

from future_builtins import zip

after running the zip fixer which respects the meaning of this command (issue 217). It does not, which results in an ImportError when trying to use the converted code under Python 3.

Similarly for lines like this after running the map fixer etc:

from future_builtins import map

Background:

Python 2.6 and 2.7 have an iterator-style zip function in future_builtins (and other things):

$ python2.6
Python 2.6.8 (unknown, Sep 28 2013, 12:09:28) 
[GCC 4.6.3] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
>>> dir(future_builtins)
['__doc__', '__file__', '__name__', '__package__', 'ascii', 'filter', 'hex', 'map', 'oct', 'zip']
>>> quit()

$ python2.7
Python 2.7.1 (r271:86832, Dec 26 2010, 19:03:20) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
>>> dir(future_builtins)
['__doc__', '__file__', '__name__', '__package__', 'ascii', 'filter', 'hex', 'map', 'oct', 'zip']
>>> quit()

The future_builtins module does not exist under Python 3, in particular its zip and map functions do not exist.

$ python3.3
Python 3.3.2 (default, Sep 28 2013, 12:00:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import future_builtins
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'future_builtins'

--------------------------------------------------

Sample script using zip which works under Python 2.6 and 2.7,

$ more zip_2to3_bug.py 
from future_builtins import zip
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print "Done"

$ python2.6 zip_2to3_bug.py 
Done

$ python2.7 zip_2to3_bug.py 
Done

Now let's use the 2to3 script (in place):

$ 2to3 -w zip_2to3_bug.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored zip_2to3_bug.py
--- zip_2to3_bug.py	(original)
+++ zip_2to3_bug.py	(refactored)
@@ -1,3 +1,3 @@
 from future_builtins import zip
 assert next(zip("abc", [1, 2, 3])) == ("a", 1)
-print "Done"
+print("Done")

Here's the (broken) output:

$ more zip_2to3_bug.py
from future_builtins import zip
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print("Done")

This breaks:

$ python3.3 zip_2to3_bug.py
Traceback (most recent call last):
  File "zip_2to3_bug.py", line 1, in <module>
    from future_builtins import zip
ImportError: No module named 'future_builtins'

Expected output should respect the fact I am using "from future_builtins import zip" therefore zip as an iterator already (this is working), and then remove the line "from future_builtins import zip":

$ more zip_2to3_bug.py
assert next(zip("abc", [1, 2, 3])) == ("a", 1)
print("Done")

--------------------------------------------------


Sample script using zip which works under Python 2.6 and 2.7,

$ more map_2to3_bug.py 
from future_builtins import map
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print "Done"

$ python2.6 map_2to3_bug.py 
Done

$ python2.7 map_2to3_bug.py 
Done

Now let's use the 2to3 script (in place):

$ 2to3 -w map_2to3_bug.py 
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored map_2to3_bug.py
--- map_2to3_bug.py	(original)
+++ map_2to3_bug.py	(refactored)
@@ -2,4 +2,4 @@
 x = [-2, -1, 0, 1, 2, 3]
 y = next(map(abs, x))
 assert y == 2 
-print "Done"
+print("Done")
RefactoringTool: Files that were modified:
RefactoringTool: map_2to3_bug.py

Here's the (broken) output:

$ more map_2to3_bug.py
from future_builtins import map
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print("Done")

This breaks:

$ python3.3 map_2to3_bug.py
Traceback (most recent call last):
  File "map_2to3_bug.py", line 1, in <module>
    from future_builtins import map
ImportError: No module named 'future_builtins'


Expected output should respect the fact I am using "from future_builtins import map" and therefore treat map according (this is working), and then remove the line "from future_builtins import map":

$ more zip_2to3_bug.py
x = [-2, -1, 0, 1, 2, 3]
y = next(map(abs, x))
assert y == 2 
print("Done")

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 198521
nosy: maubp
priority: normal
severity: normal
status: open
title: 2to3 should remove from future_builtins import *
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19111>
_______________________________________

From report at bugs.python.org  Sat Sep 28 16:59:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Sep 2013 14:59:44 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
 correctly
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1380380384.25.0.599326338786.issue10042@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated patch that includes the simplified OrderedEnum example in the enum docs and also updates the enum tests to check that type errors are correctly raised between different kinds of ordered enum.

----------
nosy: +ethan.furman
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:03:25 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 28 Sep 2013 15:03:25 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
 correctly
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1380380605.56.0.249708251396.issue10042@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Raymond, I'm happy to leave this until alpha 4, but I'm raising the priority a bit since I think the inclusion of Enum in the standard library increases the chances of people wanting to use functools.total_ordering to avoid writing out the comparison methods in situations where incompatible types may encounter each other.

----------
Added file: http://bugs.python.org/file31890/issue10042_with_enum_updates.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:10:59 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 28 Sep 2013 15:10:59 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380381059.19.0.0514836845158.issue18594@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:11:35 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 28 Sep 2013 15:11:35 +0000
Subject: [issue19010] Make XMLPullParser in ElementTree inherit from XMLParser
In-Reply-To: <1379088212.34.0.0740514839917.issue19010@psf.upfronthosting.co.za>
Message-ID: <1380381095.08.0.881380371018.issue19010@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19010>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:13:15 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 Sep 2013 15:13:15 +0000
Subject: [issue19010] Make XMLPullParser in ElementTree inherit from XMLParser
In-Reply-To: <1379088212.34.0.0740514839917.issue19010@psf.upfronthosting.co.za>
Message-ID: <1380381195.52.0.904749789341.issue19010@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Any comment and/or reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19010>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:28:26 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 15:28:26 +0000
Subject: [issue16079] list duplicate test names with patchcheck
In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za>
Message-ID: <1380382106.33.0.0604098478261.issue16079@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

duplicate_code_names_2.py uses tokenize to print duplicate code names
within the same scope, excluding property setter/getter/deleter
duplicates, excluding duplicates of nested classes or functions, and
ignoring duplicates listed in a file (run with --help for more
details).  With the attached ignored_duplicates file, it prints the
following output on the root of the current default branch (in about 1
mn on an old laptop):

$ ./duplicate_code_names_2.py --ignore ignored_duplicates .
Duplicate function or class names:
./Lib/test/_test_multiprocessing.py:3047 _TestProcess
./Lib/test/test_os.py:1290 Win32ErrorTests

Duplicate method names:
./Lib/ctypes/test/test_functions.py:316 FunctionTestCase.test_errors
./Lib/distutils/tests/test_cmd.py:80 CommandTestCase.test_ensure_string_list
./Lib/lib2to3/tests/test_fixers.py:1467 Test_dict.test_14
./Lib/lib2to3/tests/test_fixers.py:1472 Test_dict.test_15
./Lib/lib2to3/tests/test_fixers.py:1477 Test_dict.test_17
./Lib/lib2to3/tests/test_fixers.py:1482 Test_dict.test_18
./Lib/lib2to3/tests/test_fixers.py:1487 Test_dict.test_19
./Lib/test/test_complex.py:104 ComplexTest.test_truediv
./Lib/test/test_dis.py:250 DisTests.test_big_linenos
./Lib/test/test_dis.py:294 DisTests.test_dis_object
./Lib/test/test_ftplib.py:537 TestFTPClass.test_mkd
./Lib/test/test_heapq.py:366 TestErrorHandling.test_get_only
./Lib/test/test_import.py:255 ImportTests.test_import_name_binding
./Lib/test/test_regrtest.py:210 ParseArgsTestCase.test_findleaks
./Lib/test/test_smtplib.py:249 DebuggingServerTests.testNotImplemented
./Lib/test/test_webbrowser.py:161 OperaCommandTest.test_open_new
./Lib/unittest/test/testmock/testmock.py:1381 MockTest.test_attribute_deletion
./Lib/xml/dom/minidom.py:379 Attr._get_name
./Mac/Tools/Doc/setup.py:123 DocBuild.makeHelpIndex

----------
Added file: http://bugs.python.org/file31891/duplicate_code_names_2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16079>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:28:48 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 15:28:48 +0000
Subject: [issue16079] list duplicate test names with patchcheck
In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za>
Message-ID: <1380382128.59.0.346130418169.issue16079@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


Added file: http://bugs.python.org/file31892/ignored_duplicates

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16079>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:42:25 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 Sep 2013 15:42:25 +0000
Subject: [issue18902] Make ElementTree event handling more modular to allow
 custom targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1380382945.86.0.97462585018.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Closing #18990 defines the API of the new XMLPullParser that 3.4 will ship with, so this ticket becomes an enhancement for future versions.

----------
type: behavior -> enhancement
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18902>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:51:29 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 28 Sep 2013 15:51:29 +0000
Subject: [issue19010] Make XMLPullParser in ElementTree inherit from XMLParser
In-Reply-To: <1379088212.34.0.0740514839917.issue19010@psf.upfronthosting.co.za>
Message-ID: <1380383489.1.0.00376802829569.issue19010@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Discussed in #18990

Future discussions of this class belong in #18902

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19010>
_______________________________________

From report at bugs.python.org  Sat Sep 28 17:51:47 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 15:51:47 +0000
Subject: [issue19112] tests of _TestProcess are not run by the multiprocessing
 test suite
Message-ID: <1380383507.04.0.708798356972.issue19112@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

class _TestProcess in Lib/test/_test_multiprocessing.py is
overshadowed by a function of the same name.  And test_current is its
first method:

$ ./python -m test -v test_multiprocessing_fork | grep test_current
$

With the attached patch:

$ ./python -m test -v test_multiprocessing_fork | grep test_current
test_current (test.test_multiprocessing_fork.WithProcessesTestProcess) ... ok
test_current (test.test_multiprocessing_fork.WithThreadsTestProcess) ... ok
$

----------
components: Library (Lib)
files: testprocess.patch
keywords: patch
messages: 198528
nosy: jnoller, xdegaye
priority: normal
severity: normal
status: open
title: tests of _TestProcess are not run by the multiprocessing test suite
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31893/testprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19112>
_______________________________________

From report at bugs.python.org  Sat Sep 28 18:23:39 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 16:23:39 +0000
Subject: [issue19113] duplicate test names in Lib/ctypes/test/test_functions.py
Message-ID: <1380385419.52.0.767012097586.issue19113@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

After renaming the first test_errors method to test_errors_1 and the
second one to test_errors_2:

$ /bin/sh -c "cd Lib/ctypes/test; ../../../python runtests.py test_functions.py"
....F................
======================================================================
FAIL: test_errors_1 (ctypes.test.test_functions.FunctionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/ctypes/test/test_functions.py", line 227, in test_errors_1
    self.assertRaises(TypeError, f, X()) #cannot convert parameter
AssertionError: TypeError not raised by _testfunc_p_p

----------------------------------------------------------------------
Ran 21 tests in 0.007s

FAILED (failures=1)

----------
components: Library (Lib)
messages: 198529
nosy: amaury.forgeotdarc, belopolsky, meador.inge, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/ctypes/test/test_functions.py
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19113>
_______________________________________

From report at bugs.python.org  Sat Sep 28 18:28:06 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 28 Sep 2013 16:28:06 +0000
Subject: [issue19112] tests of _TestProcess are not run by the multiprocessing
 test suite
In-Reply-To: <1380383507.04.0.708798356972.issue19112@psf.upfronthosting.co.za>
Message-ID: <1380385686.39.0.673545902202.issue19112@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19112>
_______________________________________

From report at bugs.python.org  Sat Sep 28 18:34:45 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 28 Sep 2013 16:34:45 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1380386085.4.0.671663723532.issue11344@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Sat Sep 28 18:37:12 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 16:37:12 +0000
Subject: [issue19114] duplicate test names in Lib/distutils/tests/test_cmd.py
Message-ID: <1380386232.47.0.0199023087976.issue19114@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

$ ./python -m unittest -v Lib/distutils/tests/test_cmd.py 2>&1 | grep test_ensure_string_list
test_ensure_string_list (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
$

And after renaming the first test_ensure_string_list to
test_ensure_string_list_1 and the second one to
test_ensure_string_list_2:

$ ./python -m unittest -v Lib/distutils/tests/test_cmd.py 2>&1 | grep test_ensure_string_list
test_ensure_string_list_1 (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
test_ensure_string_list_2 (Lib.distutils.tests.test_cmd.CommandTestCase) ... ok
$

----------
components: Library (Lib)
messages: 198530
nosy: eric.araujo, tarek, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/distutils/tests/test_cmd.py
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19114>
_______________________________________

From report at bugs.python.org  Sat Sep 28 18:52:57 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 16:52:57 +0000
Subject: [issue19115] duplicate test names in Lib/lib2to3/tests/test_fixers.py
Message-ID: <1380387177.92.0.945417073814.issue19115@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

There are 5 duplicate test names in this file.

$ ./python -m unittest Lib/lib2to3/tests/test_fixers.py
......................................................................
----------------------------------------------------------------------
Ran 451 tests in 8.770s

OK

With the patch applied:

$ ./python -m unittest Lib/lib2to3/tests/test_fixers.py
......................................................................
----------------------------------------------------------------------
Ran 456 tests in 8.810s

OK

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198531
nosy: benjamin.peterson, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/lib2to3/tests/test_fixers.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31894/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19115>
_______________________________________

From report at bugs.python.org  Sat Sep 28 19:13:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 17:13:13 +0000
Subject: [issue19107] CSV output of benchmark runner tries to write to binary
 file
In-Reply-To: <1380296718.47.0.355256132109.issue19107@psf.upfronthosting.co.za>
Message-ID: <3cnGfc6n4lz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 07a8440b3987 by Antoine Pitrou in branch 'default':
Issue #19107: fix csv output with Python 3
http://hg.python.org/benchmarks/rev/07a8440b3987

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19107>
_______________________________________

From report at bugs.python.org  Sat Sep 28 19:13:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Sep 2013 17:13:55 +0000
Subject: [issue19107] CSV output of benchmark runner tries to write to binary
 file
In-Reply-To: <1380296718.47.0.355256132109.issue19107@psf.upfronthosting.co.za>
Message-ID: <1380388435.87.0.480693786312.issue19107@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19107>
_______________________________________

From report at bugs.python.org  Sat Sep 28 19:16:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 17:16:48 +0000
Subject: [issue19108] Benchmark runner tries to execute external Python
 command and fails on error reporting
In-Reply-To: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za>
Message-ID: <3cnGkl6D6Mz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 921177a65386 by Antoine Pitrou in branch 'default':
Issue #19108: fix str/bytes mismatch when raising exception under Python 3
http://hg.python.org/benchmarks/rev/921177a65386

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19108>
_______________________________________

From report at bugs.python.org  Sat Sep 28 19:18:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Sep 2013 17:18:21 +0000
Subject: [issue19108] Benchmark runner tries to execute external Python
 command and fails on error reporting
In-Reply-To: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za>
Message-ID: <1380388701.16.0.710461381938.issue19108@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've fixed the str/bytes mismatch. I don't have any strong feelings about the rest, other than whoever wants perf.py to work with wrapper scripts should probably propose a patch. I'll let Brett decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19108>
_______________________________________

From report at bugs.python.org  Sat Sep 28 19:20:50 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 Sep 2013 17:20:50 +0000
Subject: [issue19108] Benchmark runner tries to execute external Python
 command and fails on error reporting
In-Reply-To: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za>
Message-ID: <1380388850.11.0.693454982305.issue19108@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Well, it worked before, so the current state is clearly a regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19108>
_______________________________________

From report at bugs.python.org  Sat Sep 28 19:43:11 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 28 Sep 2013 17:43:11 +0000
Subject: [issue18902] Make ElementTree event handling more modular to allow
 custom targets for the non-blocking parser
In-Reply-To: <1378080221.59.0.577633252217.issue18902@psf.upfronthosting.co.za>
Message-ID: <1380390191.02.0.747216876195.issue18902@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Copying a relevant comment by Eli from http://bugs.python.org/issue18990#msg198145 and replying inline.

"""
The way the APIs are currently defined, XMLParser and XMLPullParser are different animals. XMLParser can be considered to only have one "front" in the API - feed() and close(). You feed() until the document is done and then you close() and get the parsed tree. There's no other way to get the parsed tree (unless you use a custom builder, I guess).

On the other hand XMLPullParser has two clear "fronts" - an input front with feed() and close() and an output front with read_events(). For XMLPullParser, close() is just an input signal. The canonical way to get output from XMLPullParser is read_events(). close() has no better reason to return output than feed(). When we decided to change the method names (recall that Antoine's originals were completely different), we perhaps forgot this detail.
"""

No, we didn't.


"""
Even though XMLPullParser's method is named close(), it's *not* like XMLParser's close(). If someone is using XMLPullParser for its close() he's likely using the class incorrectly.

Just as an example: consider that in a lot of use cases the programmer will want to discard parts of the tree that's parsed iteratively (similarly to the main use case of iterparse()), because the XML itself is too huge. It's a convenient streaming API, in other words. Now, if the reader discards parts of the tree (by deleting subtrees), then returning the root from close() becomes even more meaningless, because it's no longer the root and we have no idea what it actually is.
"""

Let me repeat that this was already the case before the new class was added and that it's a feature. If the target decides to discard parts of the tree, or not build a tree at all and (say) instead count elements and return their total number on close(), then that's what the user asked for by selecting that target.

Let's agree to disagree on your conclusions, but I still can't see any advantages of making the separation between the two classes. The way I see it, making XMLPullParser inherit from XMLParser makes it very easy to explain what the difference is: the read_events() method, i.e. the additional way to receive the parse events that the combination of parser and target generate. Essentially, it's the target that does all the work here and the parser only collects the results and presents them to the user. Thus my intention to keep the parser as "stupid" as it looks from the user's side, instead of adding something new right next to it.

That being said, if ElementTree keeps them separate and decides to *never* return anything from XMLPullParser.close(), then that's sufficiently compatible with lxml.etree, so I won't object to it. lxml has a long history of extending what's there in order to make it easier to use.

As long as we can find a way to keep both libraries compatible for users, I think we should be able to both move forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18902>
_______________________________________

From report at bugs.python.org  Sat Sep 28 20:34:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 18:34:29 +0000
Subject: [issue18950] Miscellaneous fixes for the sunau module
In-Reply-To: <1378502694.18.0.563332968903.issue18950@psf.upfronthosting.co.za>
Message-ID: <3cnJSP15zhzRhx@mail.python.org>


Roundup Robot added the comment:

New changeset 41ed98a93236 by Serhiy Storchaka in branch '3.3':
Issue #18950: Fix miscellaneous bugs in the sunau module.
http://hg.python.org/cpython/rev/41ed98a93236

New changeset 9e54def97a5e by Serhiy Storchaka in branch 'default':
Issue #18950: Fix miscellaneous bugs in the sunau module.
http://hg.python.org/cpython/rev/9e54def97a5e

New changeset fdbbbc7b40d7 by Serhiy Storchaka in branch '2.7':
Issue #18950: Fix miscellaneous bugs in the sunau module.
http://hg.python.org/cpython/rev/fdbbbc7b40d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18950>
_______________________________________

From report at bugs.python.org  Sat Sep 28 20:56:06 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 18:56:06 +0000
Subject: [issue19116] duplicate test names in Lib/test/test_complex.py
Message-ID: <1380394566.75.0.788169311559.issue19116@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

$ ./python -m test -v test_complex | grep test_truediv
test_truediv (test.test_complex.ComplexTest) ... ok

After renaming the first test_truediv to test_truediv_1 and the second
one to test_truediv_2:

$ ./python -m test -v test_complex | grep test_truediv
test_truediv_1 (test.test_complex.ComplexTest) ... ok
test_truediv_2 (test.test_complex.ComplexTest) ... ok

----------
components: Library (Lib)
messages: 198539
nosy: xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/test/test_complex.py
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19116>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:10:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 19:10:41 +0000
Subject: [issue19110] PEP-0 history link is broken
In-Reply-To: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>
Message-ID: <3cnKG85xRHz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset aba730d39749 by Ned Deily in branch 'default':
Issue #19110: Surpress Last-Modified link in PEP 0 html
http://hg.python.org/peps/rev/aba730d39749

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19110>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:13:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 19:13:32 +0000
Subject: [issue19115] duplicate test names in Lib/lib2to3/tests/test_fixers.py
In-Reply-To: <1380387177.92.0.945417073814.issue19115@psf.upfronthosting.co.za>
Message-ID: <3cnKKR5mpyz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 39bb7421cb69 by Benjamin Peterson in branch '2.7':
fix duplicate test names (closes #19115)
http://hg.python.org/cpython/rev/39bb7421cb69

New changeset 6bf37e2cbe83 by Benjamin Peterson in branch '3.3':
fix duplicate test names (closes #19115)
http://hg.python.org/cpython/rev/6bf37e2cbe83

New changeset 9f1694c2d47f by Benjamin Peterson in branch 'default':
merge 3.3 (#19115)
http://hg.python.org/cpython/rev/9f1694c2d47f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19115>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:13:56 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 19:13:56 +0000
Subject: [issue19117] duplicate test names in Lib/test/test_dis.py
Message-ID: <1380395636.95.0.580453095292.issue19117@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_dis.py:250 DisTests.test_big_linenos
./Lib/test/test_dis.py:294 DisTests.test_dis_object

The attached patch fixes this.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198542
nosy: ncoghlan, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/test/test_dis.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31895/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19117>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:19:06 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 19:19:06 +0000
Subject: [issue19118] duplicate test names in Lib/test/test_ftplib.py
Message-ID: <1380395946.78.0.131314342439.issue19118@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_ftplib.py:537 TestFTPClass.test_mkd

The attached patch fixes this.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198543
nosy: giampaolo.rodola, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test names in Lib/test/test_ftplib.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31896/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19118>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:23:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 28 Sep 2013 19:23:29 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380396209.45.0.00880772508639.issue19058@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Here is a patch. It uses same algorithm to obtain encodable
> non-ASCII string as for FS_NONASCII, but with locale encoding.
> It also adds new tests and simplifies existing tests.

I don't like your patch. The purpose of PYTHONIOENCODING is to set sys.stdin/stdout/stderr encodings. Your patch does not check sys.stdout.encoding, but check directly the codec. Two codecs may encode the same character as the same byte sequence.

Your test is skipped if the locale encoding is ASCII, whereas the purpopse of PYTHONIOENCODING is to write non-ASCII characters without having to care of the locale encoding.

I would really prefer to simply check sys.stdin.encoding, sys.stdout.encoding and sys.stderr.encoding attributes.

If you really want to check the codec itself, you should use known sequence, ex: 'h?llo?'.encode('cp1252') gives b'h\xe9llo\x80'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:30:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 19:30:42 +0000
Subject: [issue19060] docs: note that subprocess doesn't replace os.exec*
In-Reply-To: <1379748595.57.0.00736365306091.issue19060@psf.upfronthosting.co.za>
Message-ID: <1380396642.85.0.857227999019.issue19060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The problem with the current text is 'such as', implying that there are other unlisted items that could have (should have?) been added to make the list complete. If the list is complete, 'such as' could just be removed. If a sentence were added, I would simplify it to
"It does not replace os.exec*." or perhaps "os.fork and os.exec*.".

----------
keywords: +easy
nosy: +loewis, terry.reedy
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19060>
_______________________________________

From report at bugs.python.org  Sat Sep 28 21:39:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 19:39:20 +0000
Subject: [issue19066] os.execv fails with spaced names on  Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380397160.76.0.285634890807.issue19066@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Please stop marking all versions. Use cntl-left click to select the appropriate ones (currently at most 2.7, 3.3, 3.4 for users). Which version did you run your file with?

----------
nosy: +loewis, terry.reedy
stage:  -> test needed
type:  -> behavior
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:05:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Sep 2013 20:05:14 +0000
Subject: [issue18950] Miscellaneous fixes for the sunau module
In-Reply-To: <1378502694.18.0.563332968903.issue18950@psf.upfronthosting.co.za>
Message-ID: <1380398714.08.0.233699335473.issue18950@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18950>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:17:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:17:15 +0000
Subject: [issue19067] Built-in range docstrings are not PEP-8 compatible
In-Reply-To: <1379833275.25.0.770459256521.issue19067@psf.upfronthosting.co.za>
Message-ID: <1380399435.24.0.0934445577978.issue19067@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

PEP8 just says "PEP 257 describes good docstring conventions."
PEP 257 is what says '''It [the one line docstring] prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ...". '''

I strongly prefer the rule, but we do not usually patch purely for PEP8 compliance. However, a docstring patch is safer than a code patch.

----------
nosy: +terry.reedy
stage:  -> patch review
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19067>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:18:43 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sat, 28 Sep 2013 20:18:43 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>
Message-ID: <1380399523.66.0.035059633079.issue19092@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

Here is the updated patch, with a very minor improvement (no longer unnecessarily holds on to original exc_info), and with new tests. The tests test for the non-suppression of exit-exception (which fails without the fix) and for the correct suppression of body-exception by an outer CM. It was not necessary to write a test for suppression of exit-exception, since this is already tested by test_exit_exception_chaining_suppress().

There is one problem, however: applying my patch mysteriously breaks the existing test_exit_exception_chaining(). It breaks in a peculiar way: the correct exception is propagated , but the exception's context is wrong. Instead of to KeyError, it points to ZeroDivisionError, despite its having been correctly suppressed.

I placed prints in _fix_exception_context right before assignment to __context__, to make sure it wasn't broken by my patch, and the assignment appears correct, it sets the context of IndexError to KeyError instance. The __context__ is correct immediately before the raise statement. However, after the IndexError is caught inside test_exit_exception_chaning(), its __context__ is unexpectedly pointing to ZeroDivisionError.

It would seem that the difference is in the raise syntax. The old code used "raise", while the new code uses "raise exc[1]", which I assume changes the exception's __context__. Changing "raise exc[1]" to "raise exc[1] from None" didn't help.

----------
Added file: http://bugs.python.org/file31897/exitstack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:37:00 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:37:00 +0000
Subject: [issue19067] Built-in range docstrings are not PEP-8 compatible
In-Reply-To: <1379833275.25.0.770459256521.issue19067@psf.upfronthosting.co.za>
Message-ID: <1380400620.78.0.799963838487.issue19067@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I asked on py-dev whether to do this.
#19068 and #19069 are similar issues for complex and float docstrings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19067>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:37:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:37:22 +0000
Subject: [issue19068] Some built-in complex docstrings are not PEP-8 compatible
In-Reply-To: <1379833742.32.0.289149108308.issue19068@psf.upfronthosting.co.za>
Message-ID: <1380400642.63.0.825954629497.issue19068@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19068>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:37:55 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:37:55 +0000
Subject: [issue19069] Built-in float docstrings are not PEP-8 compatible
In-Reply-To: <1379834291.01.0.660875879281.issue19069@psf.upfronthosting.co.za>
Message-ID: <1380400675.79.0.183558079135.issue19069@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19069>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:42:41 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:42:41 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380400961.25.0.761512278248.issue19072@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:48:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:48:54 +0000
Subject: [issue19075] Add sorting algorithm visualization to turtledemo
In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>
Message-ID: <1380401334.05.0.852258532014.issue19075@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19075>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:52:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 20:52:59 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380401579.33.0.612427615326.issue19078@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:53:22 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Sep 2013 20:53:22 +0000
Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py
Message-ID: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

There are two test_get_only methods. The patch provides a partial
fix, but removes the following two lines from the first method as the
execution of these lines fails:

  for f in (self.module.nlargest, self.module.nsmallest):
      self.assertRaises(TypeError, f, 2, GetOnly())

because heapq.nlargest is stuck in an infinite loop when the sequence
does not have a length. This seems to be a bug in nlargest. See the
following test that runs with 100 % cpu usage.

$ ./python
Python 3.4.0a2+ (default:f6792f734fcc, Sep 28 2013, 17:09:46) 
[GCC 4.3.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class GetOnly:
...     "Dummy sequence class defining __getitem__ but not __len__."
...     def __getitem__(self, ndx):
...         return 10
... 
>>> import heapq
>>> heapq.nlargest(2, GetOnly())
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Lib/heapq.py", line 455, in nlargest
    result = _nlargest(n, it)
  File "<stdin>", line 3, in __getitem__
KeyboardInterrupt
>>>

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198550
nosy: rhettinger, stutzbach, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_heapq.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31898/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19119>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:53:43 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 28 Sep 2013 20:53:43 +0000
Subject: [issue18978] Allow urllib.request.Request subclasses to override
 method
In-Reply-To: <1378658488.73.0.640329823015.issue18978@psf.upfronthosting.co.za>
Message-ID: <1380401623.33.0.621512830014.issue18978@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the this change, Jason. Docs could be updated to reflect this change (using ..versionchanged: directive). Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18978>
_______________________________________

From report at bugs.python.org  Sat Sep 28 22:56:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Sep 2013 20:56:59 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380401819.69.0.620074525543.issue19058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which directly checks sys.std* attributes.

----------
Added file: http://bugs.python.org/file31899/sys_test_ioencoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:02:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Sep 2013 21:02:10 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380402130.93.0.124522634149.issue19058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Your test is skipped if the locale encoding is ASCII, whereas the purpopse of PYTHONIOENCODING is to write non-ASCII characters without having to care of the locale encoding.

This case was tested in previous test.

> If you really want to check the codec itself, you should use known sequence, ex: 'h?llo?'.encode('cp1252') gives b'h\xe9llo\x80'.

We can't be sure that OS supports cp1252 (or any other non-default) locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:06:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Sep 2013 21:06:28 +0000
Subject: [issue19058] test_sys.test_ioencoding_nonascii() fails with ASCII
 locale encoding
In-Reply-To: <1379712575.68.0.606220974648.issue19058@psf.upfronthosting.co.za>
Message-ID: <1380402388.5.0.754495239099.issue19058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Your patch does not check sys.stdout.encoding, but check directly the codec. Two codecs may encode the same character as the same byte sequence.

Checking encoding name is too rigid. Python interpreter can normalize encoding name before assigning it to standard streams. This is implementation detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19058>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:11:39 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 21:11:39 +0000
Subject: [issue19080] Enrich SyntaxError with additional information
In-Reply-To: <1379968925.72.0.669299760684.issue19080@psf.upfronthosting.co.za>
Message-ID: <1380402699.05.0.0883562353701.issue19080@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Currently,
>>> * 2 # or * a
SyntaxError: can use starred expression only as assignment target
This conflicts with your desired message. It cannot change because *a, at least, is a valid statement prefix in a way that '/ a' is not.

Most other things give an uninformative generic 'invalid syntax' message (plus a more informative location indicator). If you can find a way to improve this, lots of people would be happy ;-).

----------
nosy: +terry.reedy
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19080>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:25:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 21:25:49 +0000
Subject: [issue19091] ast.parse gives wrong position for some Names when
 non-ascii characters occur before
In-Reply-To: <1380133709.64.0.537787667021.issue19091@psf.upfronthosting.co.za>
Message-ID: <1380403549.78.0.475057865004.issue19091@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19091>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:28:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 21:28:10 +0000
Subject: [issue19094] urljoin should raise a TypeError if URL is not a string
In-Reply-To: <1380142541.83.0.560775690833.issue19094@psf.upfronthosting.co.za>
Message-ID: <1380403690.02.0.779021782137.issue19094@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +orsenthil
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19094>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:52:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 21:52:05 +0000
Subject: [issue19103] Use pprint in displayhook
In-Reply-To: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>
Message-ID: <1380405125.83.0.734415614729.issue19103@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(in the patch, import of sys and pprint should be done once at module level and not repeated with every line of interactive output).

> pprint.pprint() produces more human readable output than print(repr()) which is used in sys.displayhook()

Only sometimes, and when it is not, the result can be *much* worse. For instance, try list(range(40)) with the two options. On windows, pprint.pprint(list(range(300))) will not even fit in the default 300 line output buffer of the standard interpreter. This is not to mention doctest and other test breakage. I believe the majority consensus on python-ideas was to reject this until pprint is much improved, and then reconsider. I agree with that.

As I said on the list, I think this is more feasible for environments (like Idle) where it could be turned on and off, or invoked to re-display an output where pprint *would* be better.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19103>
_______________________________________

From report at bugs.python.org  Sat Sep 28 23:52:43 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Sep 2013 21:52:43 +0000
Subject: [issue19103] Use pprint in displayhook
In-Reply-To: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>
Message-ID: <1380405163.29.0.101350422246.issue19103@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19103>
_______________________________________

From report at bugs.python.org  Sun Sep 29 01:51:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Sep 2013 23:51:43 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <3cnRVQ3CRYz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 48d28de5bdf8 by Antoine Pitrou in branch '3.3':
Issue #4366: Fix building extensions on all platforms when --enable-shared is used.
http://hg.python.org/cpython/rev/48d28de5bdf8

New changeset d6e35146ae53 by Antoine Pitrou in branch 'default':
Issue #4366: Fix building extensions on all platforms when --enable-shared is used.
http://hg.python.org/cpython/rev/d6e35146ae53

New changeset 28e6c23c8ae6 by Antoine Pitrou in branch '2.7':
Issue #4366: Fix building extensions on all platforms when --enable-shared is used.
http://hg.python.org/cpython/rev/28e6c23c8ae6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Sun Sep 29 01:55:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Sep 2013 23:55:36 +0000
Subject: [issue4366] cannot find -lpythonX.X when building Python on FreeBSD
 with --enable-shared
In-Reply-To: <1227202019.4.0.606199376498.issue4366@psf.upfronthosting.co.za>
Message-ID: <1380412536.61.0.679648393684.issue4366@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, let's mark this bug fixed.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4366>
_______________________________________

From report at bugs.python.org  Sun Sep 29 02:13:42 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Sep 2013 00:13:42 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380399523.66.0.035059633079.issue19092@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eWMNQYXUyc1zZPLa170k6BM8BvOKFfagq-pdKTVOt8gA@mail.gmail.com>


Nick Coghlan added the comment:

Moving the context fixing into an exception handler may work. Something
like:

    try:
        raise exc[1]
     except BaseException as fix_exc:
        ...
        raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Sun Sep 29 02:23:54 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 29 Sep 2013 00:23:54 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1380414234.85.0.634177183006.issue18857@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Hi Joshua, I did not setup a php server to test the html form that you uploaded. We cannot test this in browsers because HTML does not have None as values, it is simple empty strings and that is correct. 
I think that the cost of making this change is higher than the value that it will give and I am inclined to close this bug report as wont fix. If you strongly disagree, please feel free to reopen it (and can possibly discuss at python-dev). Thank you!

----------
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Sun Sep 29 04:35:13 2013
From: report at bugs.python.org (Daniel)
Date: Sun, 29 Sep 2013 02:35:13 +0000
Subject: [issue19120] shlex.shlex.lineno reports a different number depending
 on the previous token
Message-ID: <1380422113.39.0.502795028764.issue19120@psf.upfronthosting.co.za>


New submission from Daniel:

See the example below (also attached).

First example: The lineno reported just after "word2" is pulled is 2.
Second example: The lineno reported just after "," is pulled is still 1.

This behaviour seems inconsistent. The lineno should increment either when the last token of a line is pulled, or after the first token from the next line (in my opinion preferably the former). It should not have different bahaviour depending on what type of token that is (alpha vs. comma).

I have repeated this on 

Also, does Issue 16121 relate to this?


#!/usr/bin/env python
import shlex

first = shlex.shlex("word1 word2\nword3")
print (first.get_token())
print (first.get_token())
print ("line no", first.lineno)
print ("")

second = shlex.shlex("word1 word2,\nword3")
print (second.get_token())
print (second.get_token())
print (second.get_token())
print ("line no", second.lineno)


# Output:
# word1
# word2
# line no 2
#
# word1
# word2
# ,
# line no 1

----------
files: shlex_line.py
messages: 198561
nosy: daniel-s
priority: normal
severity: normal
status: open
title: shlex.shlex.lineno reports a different number depending on the previous token
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31900/shlex_line.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19120>
_______________________________________

From report at bugs.python.org  Sun Sep 29 04:38:09 2013
From: report at bugs.python.org (Daniel)
Date: Sun, 29 Sep 2013 02:38:09 +0000
Subject: [issue19120] shlex.shlex.lineno reports a different number depending
 on the previous token
In-Reply-To: <1380422113.39.0.502795028764.issue19120@psf.upfronthosting.co.za>
Message-ID: <1380422289.42.0.40082062684.issue19120@psf.upfronthosting.co.za>


Daniel added the comment:

>From the unfinished sentence:

I have repeated this on all versions of shlex on which I have tried. Including Python 2.6, 2.7, 3.2 and 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19120>
_______________________________________

From report at bugs.python.org  Sun Sep 29 06:24:10 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 29 Sep 2013 04:24:10 +0000
Subject: [issue14365] argparse: subparsers,
 argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1380428650.03.0.751269865734.issue14365@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Removed file: http://bugs.python.org/file31888/subparser_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Sun Sep 29 06:30:28 2013
From: report at bugs.python.org (paul j3)
Date: Sun, 29 Sep 2013 04:30:28 +0000
Subject: [issue14365] argparse: subparsers,
 argument abbreviations and ambiguous option
In-Reply-To: <1332102480.28.0.401837291603.issue14365@psf.upfronthosting.co.za>
Message-ID: <1380429028.31.0.956192338488.issue14365@psf.upfronthosting.co.za>


paul j3 added the comment:

This the argparse patch as described in the previous post, along with test_argparse tests.  

For now the tests handle both subparser required cases and not required ones ( http://bugs.python.org/issue9253 ).  While error messages can differ based on this requirement, it does not affect the 'ambiguity' that underlies the current issue.

----------
Added file: http://bugs.python.org/file31901/subparser_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14365>
_______________________________________

From report at bugs.python.org  Sun Sep 29 07:51:10 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 29 Sep 2013 05:51:10 +0000
Subject: [issue19110] PEP-0 history link is broken
In-Reply-To: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>
Message-ID: <1380433870.89.0.83398646157.issue19110@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19110>
_______________________________________

From report at bugs.python.org  Sun Sep 29 08:09:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 06:09:09 +0000
Subject: [issue19110] PEP-0 history link is broken
In-Reply-To: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>
Message-ID: <3cnbsx0RxMz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 281608674f63 by Ned Deily in branch 'default':
Issue #19110: Suppress PEP 0 Last-Modified link in pep2pyramid, too
http://hg.python.org/peps/rev/281608674f63

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19110>
_______________________________________

From report at bugs.python.org  Sun Sep 29 08:19:27 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Sep 2013 06:19:27 +0000
Subject: [issue19110] PEP-0 history link is broken
In-Reply-To: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>
Message-ID: <1380435567.19.0.98650766972.issue19110@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  The PEP 0 page now no longer contains a link: since it is automatically generated, there is no corresponding file for it in the peps repo.

----------
nosy: +ned.deily
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19110>
_______________________________________

From report at bugs.python.org  Sun Sep 29 08:22:21 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 29 Sep 2013 06:22:21 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380435741.38.0.210402392433.issue19078@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

For multidimensional arrays it doesn't seem to work (yet).

>>> x = numpy.array([[1,2,3], [4,5,6]])
>>> list(reversed(x))
[array([4, 5, 6]), array([1, 2, 3])]
>>> x.data
<memory at 0x8032d06b8>
>>> list(reversed(x.data))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: multi-dimensional sub-views are not implemented
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Sun Sep 29 09:06:42 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 07:06:42 +0000
Subject: [issue19110] PEP-0 history link is broken
In-Reply-To: <1380357436.7.0.673838286664.issue19110@psf.upfronthosting.co.za>
Message-ID: <1380438402.53.0.179675109658.issue19110@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Cool. Even if it is automatically generated, it may worth to commit this file anyway to get browsable HG history about PEP additions/removals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19110>
_______________________________________

From report at bugs.python.org  Sun Sep 29 09:13:55 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 07:13:55 +0000
Subject: [issue19066] os.execv fails with spaced names on  Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380438835.86.0.292250372225.issue19066@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

I tested with 2.7 and 3.3, but this is true for any version.

If the bug is actual for Python 2.6, 3.1 and 3.2 why should I uncheck them? Versions field description doesn't say that I should mark only latest change. In addition, people (unlikely, but still) may search for specific versions to see which bugs were reported against them and fixed in later releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 10:28:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Sep 2013 08:28:15 +0000
Subject: [issue19066] os.execv fails with spaced names on  Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380443295.94.0.240432864135.issue19066@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The versions are the versions that will be patched for the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 10:46:11 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 29 Sep 2013 08:46:11 +0000
Subject: [issue19010] Make XMLPullParser in ElementTree inherit from XMLParser
In-Reply-To: <1379088212.34.0.0740514839917.issue19010@psf.upfronthosting.co.za>
Message-ID: <1380444371.56.0.480743063356.issue19010@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Given that the inheritance chain has no real user impact, I can live with this difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19010>
_______________________________________

From report at bugs.python.org  Sun Sep 29 11:25:58 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 09:25:58 +0000
Subject: [issue19121] Documentation guidelines enhancements
Message-ID: <1380446758.24.0.414615784712.issue19121@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I'll raise some points and then suggest how to fix that.

issue19060 it appeared that list of functions that subprocess replaces imbues readers with uncertainty, because this list is not complete.

Current http://docs.python.org/devguide/documenting.html guide doesn't pay attention that information should be "complete and unambiguous". issue19060 is a good example of completeness requirement - user should not be left guessing what other functions can be or can not be replaced by subprocess. Unambiguous means that there should also be answer why they can or can not be replaced. For subprocess this info is partially provided in "replacing older functions" chapter. There also should not be a place for subjective judgement, fear and desperation. If something can not be done with subprocess, users should not be discouraged (left in fear) to use older functions. If there are valid points where subprocess is not good, they should be described in advanced section. If the description is too long to read, it should be linked.

Somebody may raise the point that subprocess docs is not the best place for such list. But between choice to be complete and structured, the former should take precedence. When documentation is complete enough, it's text can be restructured. This further raises a point about structure of docs. Both main docs and guidelines itself.


Main docs structure.

The more unambiguous, complete and concise documentation is, the better it is for understanding. Currently our docs really miss overviews and summaries. Some may argue that there is no place for that in official docs, especially if such summaries will contain info about history and changes between Python versions. But I'd say that if there is no place, we need to find it for them. Just two examples. MSDN and Python Cookbook both are examples of perfect documentation and these both include overview chapters before function reference. When where is a critical mass of info related to child process execution and management, it is worth to make an overview.


Guidelines structure.

ToC.
Sphinx ToCs are too narrow - they are hard to read. If ToC is present in side panel for navigation, it is not the reason not to include it below the page header for human readers to see the structure of the doc. I find it extremely hard (unnatural) to scan the side panel for the doc structure.

This should be split between markup and content guidelines. Right now the structure of docs is:

7. Documenting Python
7.1. Introduction
7.2. Style guide
7.2.1. Use of whitespace
7.2.2. Footnotes
7.2.3. Capitalization
7.2.4. Affirmative Tone
7.2.5. Economy of Expression
7.2.6. Code Examples
7.2.7. Code Equivalents
7.2.8. Audience
7.3. reStructuredText Primer
7.3.1. Paragraphs
7.3.2. Inline markup
7.3.3. Lists and Quotes
7.3.4. Source Code
7.3.5. Hyperlinks
7.3.5.1. External links
7.3.5.2. Internal links
7.3.6. Sections
7.3.7. Explicit Markup
7.3.8. Directives
7.3.9. Footnotes
7.3.10. Comments
7.3.11. Source encoding
7.3.12. Gotchas
7.4. Additional Markup Constructs
7.4.1. Meta-information markup
7.4.2. Module-specific markup
7.4.3. Information units
7.4.4. Showing code examples
7.4.5. Inline markup
7.4.6. Cross-linking markup
7.4.7. Paragraph-level markup
7.4.8. Table-of-contents markup
7.4.9. Index-generating markup
7.4.10. Grammar production displays
7.4.11. Substitutions
7.5. Differences to the LaTeX markup
7.5.1. Inline markup
7.5.2. Information units
7.5.3. Structure
7.6. Building the documentation
7.6.1. Using make
7.6.2. Without make

As you may see the 90% of the ToC is markup reference. Some topics like "Hyperlinks" are oversplit. Making two chapter for just one sentence is an obsession with structure. That's ok for coding, but for readability I would just make it into a list in one chapter, renamed to "Linking" and merged "cross-linking markup" section into it.


7.2.3. Capitalization
7.2.4. Affirmative Tone
7.2.5. Economy of Expression
7.2.6. Code Examples

As you may see, the "Content writing" is perfectly mixed with "Content formatting" into the mix of rules for proper whitespace formatting. This perfectly characterizes us coders, who often mix the concept of "good code which is bug-free" with concept of "good code which is PEP-8 compliant". I mean that it leaves expression that most of the document is about rules, regulations and nitpicking about how you should format the text, not how you should write. 

Let's make this unambiguous - "Content" of documentation is essential info that readers need to know. "Format" of docs is the markup, whitespace, examples, footnotes and other stuff. "Content guidelines" say that you should insert footnotes, "Format guidelines" show how to do this. "Content guidelines" should not distract from the content aspects.

So, the "Style Guide" should be split into "Content Writing" and "Formatting Guidelines" [ ]. Or moves into separate file at all.


The "Content Writing" chapter.
Should include chapter that docs should be complete and unambiguous, with the points raised above, probably with a link to the linked issue.

I don't get what "affirmative tone" is. I don't get it, because header "affirmative tone" for non-native non-speaker doesn't contain the answer what and why. To me chapters like "avoid uncertainty" are more concise and valid.

"Documentation is a place for facts. Make sure that facts are complete. That after reading the documentation users are not left with doubts and fears. Make sure that if is there is a recommendation, there is also a link to reasons."

"establishing confident knowledge" and "affirmative tone" are phrases from NLP psychotherapy courses. It looks like guideline to program the readers for positive emotions, not to provide them with facts. I am not saying that docs should be dry and lawfully correct. Just the focus should be on the side of facts.

I hope that this feedback is useful.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 198571
nosy: docs at python, ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: Documentation guidelines enhancements

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19121>
_______________________________________

From report at bugs.python.org  Sun Sep 29 11:29:56 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 09:29:56 +0000
Subject: [issue19060] docs: note that subprocess doesn't replace os.exec*
In-Reply-To: <1380396642.85.0.857227999019.issue19060@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xLMS8S6eh_773ORk_joXF7Jyq_RG7uzoGrV-V+z0YC4Gw@mail.gmail.com>


anatoly techtonik added the comment:

I would like to know if the list is complete too. It would be
extremely awesome if it was complete.

This raises a side issue that there seems no guideline to write
unambiguous and complete documentation. I spammed the tracker with
this stuff in issue19121.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19060>
_______________________________________

From report at bugs.python.org  Sun Sep 29 11:32:41 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 09:32:41 +0000
Subject: [issue19060] docs: note that subprocess doesn't replace os.exec*
In-Reply-To: <1380396642.85.0.857227999019.issue19060@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+CzqwHM9qe1BzEiPVpzWcKKZP1AtS5RvzKF3yyAgSJ8Q@mail.gmail.com>


anatoly techtonik added the comment:

On Sat, Sep 28, 2013 at 10:30 PM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> If a sentence were added, I would simplify it to
> "It does not replace os.exec*." or perhaps "os.fork and os.exec*.".

I prefer list. It is easier to scan:
http://www.nngroup.com/articles/how-users-read-on-the-web/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19060>
_______________________________________

From report at bugs.python.org  Sun Sep 29 11:34:59 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 09:34:59 +0000
Subject: [issue19066] os.execv fails with spaced names on  Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380447299.28.0.0585729260531.issue19066@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

It should be documented somehow then. At least in the field tooltip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 11:43:53 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 29 Sep 2013 09:43:53 +0000
Subject: [issue19121] Documentation guidelines enhancements
In-Reply-To: <1380446758.24.0.414615784712.issue19121@psf.upfronthosting.co.za>
Message-ID: <1380447833.74.0.0034289022395.issue19121@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19121>
_______________________________________

From report at bugs.python.org  Sun Sep 29 11:51:22 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 29 Sep 2013 09:51:22 +0000
Subject: [issue1764286] inspect.getsource does not work with decorated
 functions
Message-ID: <1380448282.94.0.37654193658.issue1764286@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello. Attached patch which uses the new inspect.unwrap, added in http://hg.python.org/cpython/rev/2aa6c1e35b8a.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31902/inspect_getsource.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1764286>
_______________________________________

From report at bugs.python.org  Sun Sep 29 12:13:38 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 29 Sep 2013 10:13:38 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380449618.02.0.392289792906.issue19072@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +daniel.urban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Sun Sep 29 12:15:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 10:15:53 +0000
Subject: [issue19122] duplicate test name in Lib/test/test_import.py
Message-ID: <1380449753.39.0.561923612283.issue19122@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_import.py:255 ImportTests.test_import_name_binding

Attached patch fixes it.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198576
nosy: brett.cannon, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_import.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31903/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19122>
_______________________________________

From report at bugs.python.org  Sun Sep 29 12:24:06 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 10:24:06 +0000
Subject: [issue19123] duplicate test name in Lib/test/test_regrtest.py
Message-ID: <1380450246.86.0.728804280049.issue19123@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_regrtest.py:210 ParseArgsTestCase.test_findleaks

Attached patch fixes it.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198577
nosy: ezio.melotti, michael.foord, pitrou, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_regrtest.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31904/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19123>
_______________________________________

From report at bugs.python.org  Sun Sep 29 12:46:42 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 10:46:42 +0000
Subject: [issue19124] os.execv executes in background on Windows
Message-ID: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

os.execv() starts process in background on Windows. Because it inherits stdin/stdout handlers from the process that launched Python interpreter, this becomes a source of numerous weird bugs, from polluting the stdout stream of parent to completely blocking its input.

Example session on Windows. Open cmd.exe and run attached testexecvchild.py. It starts child process with execv(). Child pauses for 2 seconds during which I type 'echo "Hello"' and hit Enter.

With Python 3 is pollutes parent output after 3 seconds:
    >python testexecvchild.py
    
    >echo "Hello"
    "Hello"
    
    >Traceback (most recent call last):
    File "testexecvchild.py", line 7, in <module>
    raw_input('xxx')
    NameError: name 'raw_input' is not defined

With Python 2 the stdin of cmd.exe is blocked:
    >py testexecvchild.py
    
    >echo "Hello"
    "Hello"
    
    >xxxecho "Hello"
    "Hello"
    
    >echo "Hello"
      testexecvchild.py
      passed
    echo "Hello"
    "Hello"

The same behavior on Linux:

    $ python testexecvchild.py
    echo "Hello"
    xxx  testexecvchild.py
      passed

----------
components: Library (Lib)
messages: 198578
nosy: techtonik
priority: normal
severity: normal
status: open
title: os.execv executes in background on Windows
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 12:47:58 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 10:47:58 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380451678.97.0.586797017273.issue19124@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

s/same behavior/same command/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 12:48:25 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 10:48:25 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380451705.94.0.736547332176.issue19124@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


Added file: http://bugs.python.org/file31905/testexecvchild.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:05:17 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 11:05:17 +0000
Subject: [issue19066] os.execv fails with spaced names on  Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380452717.22.0.825106716954.issue19066@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

See

    http://bugs.python.org/issue436259

This is a problem with Window's implementation of spawn*() and exec*().  Just use subprocess instead which gets this stuff right.

Note that on Windows exec*() is useless: it just starts a subprocess and exits the current process.  You can use subprocess to get the same effect.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:18:26 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 11:18:26 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1380452717.22.0.825106716954.issue19066@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xJecbMSyK0Z1vz7ASk3_Tuhd38p6YBVeBdFgpjeu0vfcw@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 2:05 PM, Richard Oudkerk <report at bugs.python.org> wrote:
> See  http://bugs.python.org/issue436259

I am not sure that I should see there. There is discussion of DOS,
which is not supported, also some complain about Windows execv
function, which deprecated since VC++ 2005 (which I hope also not
supported). Can you be more specific?

> This is a problem with Window's implementation of spawn*() and exec*().

> Note that on Windows exec*() is useless: it just starts a subprocess and exits the current process.  You can use subprocess to get the same effect.

Are you describing Windows implementation of _exec()
http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current
Python implementation?

> Just use subprocess instead which gets this stuff right.

subprocess doesn't replace os.exec*, see issue19060

----------
title: os.execv fails with spaced names on  Windows -> os.execv fails with spaced names on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:18:58 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:18:58 +0000
Subject: [issue19125] duplicate test name in Lib/test/test_smtplib.py
Message-ID: <1380453538.83.0.118703506889.issue19125@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_smtplib.py:249 DebuggingServerTests.testNotImplemented

Attached patch fixes this: the first method has been renamed to
testEHLO since the channel_class of the DebuggingServer is
SMTPChannel, and SMTPChannel does support EHLO.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198582
nosy: giampaolo.rodola, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_smtplib.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31906/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19125>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:24:09 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:24:09 +0000
Subject: [issue19126] duplicate test name in Lib/test/test_webbrowser.py
Message-ID: <1380453849.08.0.0119918411206.issue19126@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/test/test_webbrowser.py:161 OperaCommandTest.test_open_new

Attached patch fixes it.

----------
components: Library (Lib)
files: duplicate_test_name.patch
keywords: patch
messages: 198583
nosy: georg.brandl, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/test/test_webbrowser.py
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file31907/duplicate_test_name.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19126>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:35:45 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:35:45 +0000
Subject: [issue19127] duplicate test name in Lib/xml/dom/minidom.py
Message-ID: <1380454545.89.0.34264409001.issue19127@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Lib/xml/dom/minidom.py:379 Attr._get_name

----------
components: Library (Lib)
messages: 198584
nosy: xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Lib/xml/dom/minidom.py
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19127>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:39:03 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:39:03 +0000
Subject: [issue19128] duplicate test name in Mac/Tools/Doc/setup.py
Message-ID: <1380454743.3.0.0899741731446.issue19128@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Duplicate method names:
./Mac/Tools/Doc/setup.py:123 DocBuild.makeHelpIndex

----------
components: Library (Lib)
messages: 198585
nosy: hynek, ned.deily, ronaldoussoren, xdegaye
priority: normal
severity: normal
status: open
title: duplicate test name in Mac/Tools/Doc/setup.py
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19128>
_______________________________________

From report at bugs.python.org  Sun Sep 29 13:45:16 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 11:45:16 +0000
Subject: [issue16079] list duplicate test names with patchcheck
In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za>
Message-ID: <1380455116.95.0.0250222498209.issue16079@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The following issues have been entered for all the above duplicate
names found by duplicate_code_names_2.py:

issue 19112, issue 19113, issue 19114, issue 19115, issue 19116,
issue 19117, issue 19118, issue 19119, issue 19122, issue 19123,
issue 19125, issue 19126, issue 19127, issue 19128

except the following which should be added to ignored_duplicates:

    ./Lib/test/test_os.py:1290 Win32ErrorTests

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16079>
_______________________________________

From report at bugs.python.org  Sun Sep 29 14:03:26 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 12:03:26 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380456206.36.0.261451077717.issue19066@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I am not sure that I should see there. There is discussion of DOS,
> which is not supported, also some complain about Windows execv
> function, which deprecated since VC++ 2005 (which I hope also not
> supported). Can you be more specific?

_spawn*() and _exec*() are implemented by the C runtime library.  spawn*() and execv() are (deprecated) aliases.

The the first message is about someone's attempt to work around the problems with embedded spaces and double quotes by writing a function to escape each argument.  He says he had a partial success.

Surely this is basic reading comprehension?

> > Note that on Windows exec*() is useless: it just starts a subprocess and 
> > exits the current process.  You can use subprocess to get the same effect.
>
> Are you describing Windows implementation of _exec()
> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current
> Python implementation?

The Windows implementaion of _exec().

> > Just use subprocess instead which gets this stuff right.
>
> subprocess doesn't replace os.exec*, see issue19060

On Unix subprocess does not replace os.exec*().  That is because on Unix exec*() replaces the current process with a new process with the *same pid*.  subprocess cannot do this.

But on Windows os.exec*() just starts an independent process with a *different pid* and exits the current process.  The line

    os.execv(path, args)

is equivalent to

    os.spawnv(os.P_NOWAIT, path, args)
    os._exit(0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 15:57:43 2013
From: report at bugs.python.org (Mathieu Sornay)
Date: Sun, 29 Sep 2013 13:57:43 +0000
Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request --
 fine with urllib, wget, or curl
In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za>
Message-ID: <1380463063.73.0.295377292649.issue14044@psf.upfronthosting.co.za>


Changes by Mathieu Sornay <msornay at gmail.com>:


----------
nosy: +lechfeck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14044>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:02:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:02:44 +0000
Subject: [issue19122] duplicate test name in Lib/test/test_import.py
In-Reply-To: <1380449753.39.0.561923612283.issue19122@psf.upfronthosting.co.za>
Message-ID: <3cnpNM5CLqz7Lkj@mail.python.org>


Roundup Robot added the comment:

New changeset a25fe5675ea4 by Benjamin Peterson in branch '3.3':
remove duplicate test from test_import (closes #19122)
http://hg.python.org/cpython/rev/a25fe5675ea4

New changeset 026cfc382a13 by Benjamin Peterson in branch 'default':
merge 3.3 (#19122)
http://hg.python.org/cpython/rev/026cfc382a13

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19122>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:47:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:47:15 +0000
Subject: [issue19123] duplicate test name in Lib/test/test_regrtest.py
In-Reply-To: <1380450246.86.0.728804280049.issue19123@psf.upfronthosting.co.za>
Message-ID: <3cnqMk2hRdz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 39f9adc8ad5b by Benjamin Peterson in branch 'default':
delete duplicate test (closes #19123)
http://hg.python.org/cpython/rev/39f9adc8ad5b

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19123>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:47:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:47:15 +0000
Subject: [issue19125] duplicate test name in Lib/test/test_smtplib.py
In-Reply-To: <1380453538.83.0.118703506889.issue19125@psf.upfronthosting.co.za>
Message-ID: <3cnqMl0zLsz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset f501475d88de by Benjamin Peterson in branch '3.3':
fix test to run and test that smtpd does support ELHO (closes #19125)
http://hg.python.org/cpython/rev/f501475d88de

New changeset d55f911c4c9d by Benjamin Peterson in branch 'default':
merge 3.3 (#19125)
http://hg.python.org/cpython/rev/d55f911c4c9d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19125>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:58:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:58:35 +0000
Subject: [issue19118] duplicate test names in Lib/test/test_ftplib.py
In-Reply-To: <1380395946.78.0.131314342439.issue19118@psf.upfronthosting.co.za>
Message-ID: <3cnqcq0qzVzP0J@mail.python.org>


Roundup Robot added the comment:

New changeset 9b3088bc24f1 by Benjamin Peterson in branch '3.3':
remove duplicate test_mkd (closes #19118)
http://hg.python.org/cpython/rev/9b3088bc24f1

New changeset c27f036e7b48 by Benjamin Peterson in branch 'default':
merge 3.3 (#19118)
http://hg.python.org/cpython/rev/c27f036e7b48

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19118>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:58:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:58:36 +0000
Subject: [issue19117] duplicate test names in Lib/test/test_dis.py
In-Reply-To: <1380395636.95.0.580453095292.issue19117@psf.upfronthosting.co.za>
Message-ID: <3cnqcq6hTyzP0J@mail.python.org>


Roundup Robot added the comment:

New changeset 9922b2cda52c by Benjamin Peterson in branch '3.3':
fix duplicate test names in test_dis (closes #19117)
http://hg.python.org/cpython/rev/9922b2cda52c

New changeset 971965daadfb by Benjamin Peterson in branch 'default':
merge 3.3 (#19117)
http://hg.python.org/cpython/rev/971965daadfb

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19117>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:58:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:58:37 +0000
Subject: [issue19126] duplicate test name in Lib/test/test_webbrowser.py
In-Reply-To: <1380453849.08.0.0119918411206.issue19126@psf.upfronthosting.co.za>
Message-ID: <3cnqcr5JwqzP0J@mail.python.org>


Roundup Robot added the comment:

New changeset aaa00c0e825d by Benjamin Peterson in branch '3.3':
fix duplicate test name (closes #19126)
http://hg.python.org/cpython/rev/aaa00c0e825d

New changeset c5b3d86535e1 by Benjamin Peterson in branch 'default':
merge 3.3 (#19126)
http://hg.python.org/cpython/rev/c5b3d86535e1

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19126>
_______________________________________

From report at bugs.python.org  Sun Sep 29 16:58:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 14:58:38 +0000
Subject: [issue19116] duplicate test names in Lib/test/test_complex.py
In-Reply-To: <1380394566.75.0.788169311559.issue19116@psf.upfronthosting.co.za>
Message-ID: <3cnqcs40njz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset cddb3e1e5054 by Benjamin Peterson in branch '3.3':
combine two tests to avoid duplicate names (closes #19116)
http://hg.python.org/cpython/rev/cddb3e1e5054

New changeset d87ef944ddcc by Benjamin Peterson in branch 'default':
merge 3.3 (#19116)
http://hg.python.org/cpython/rev/d87ef944ddcc

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19116>
_______________________________________

From report at bugs.python.org  Sun Sep 29 17:11:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 15:11:21 +0000
Subject: [issue19112] tests of _TestProcess are not run by the multiprocessing
 test suite
In-Reply-To: <1380383507.04.0.708798356972.issue19112@psf.upfronthosting.co.za>
Message-ID: <3cnqvX2Br0z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 414ccf20d182 by Benjamin Peterson in branch '3.3':
move helper function into its test method (closes #19112)
http://hg.python.org/cpython/rev/414ccf20d182

New changeset 959e894dc794 by Benjamin Peterson in branch '2.7':
move helper function into its test method (closes #19112)
http://hg.python.org/cpython/rev/959e894dc794

New changeset ea54a55a21a1 by Benjamin Peterson in branch 'default':
merge 3.3 (#19112)
http://hg.python.org/cpython/rev/ea54a55a21a1

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19112>
_______________________________________

From report at bugs.python.org  Sun Sep 29 17:14:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 15:14:00 +0000
Subject: [issue19114] duplicate test names in Lib/distutils/tests/test_cmd.py
In-Reply-To: <1380386232.47.0.0199023087976.issue19114@psf.upfronthosting.co.za>
Message-ID: <3cnqyb4ZYgz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 9d4d9e945f29 by Benjamin Peterson in branch '3.3':
condense two tests with the same name (closes #19114)
http://hg.python.org/cpython/rev/9d4d9e945f29

New changeset 61ae31665ee1 by Benjamin Peterson in branch '2.7':
condense two tests with the same name (closes #19114)
http://hg.python.org/cpython/rev/61ae31665ee1

New changeset 0a5ce192ba8a by Benjamin Peterson in branch 'default':
merge 3.3 (#19114)
http://hg.python.org/cpython/rev/0a5ce192ba8a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19114>
_______________________________________

From report at bugs.python.org  Sun Sep 29 17:16:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 15:16:46 +0000
Subject: [issue19127] duplicate test name in Lib/xml/dom/minidom.py
In-Reply-To: <1380454545.89.0.34264409001.issue19127@psf.upfronthosting.co.za>
Message-ID: <3cnr1n6bVDz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset b76e1b58ed45 by Benjamin Peterson in branch '3.3':
remove duplicate method (closes #19127)
http://hg.python.org/cpython/rev/b76e1b58ed45

New changeset 792006307d6d by Benjamin Peterson in branch '2.7':
remove duplicate method (closes #19127)
http://hg.python.org/cpython/rev/792006307d6d

New changeset 815780593826 by Benjamin Peterson in branch 'default':
merge 3.3 (#19127)
http://hg.python.org/cpython/rev/815780593826

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19127>
_______________________________________

From report at bugs.python.org  Sun Sep 29 17:27:14 2013
From: report at bugs.python.org (Peter)
Date: Sun, 29 Sep 2013 15:27:14 +0000
Subject: [issue19111] 2to3 should remove from future_builtins import *
In-Reply-To: <1380379953.79.0.934483665034.issue19111@psf.upfronthosting.co.za>
Message-ID: <1380468434.72.0.0560845262564.issue19111@psf.upfronthosting.co.za>


Peter added the comment:

Thinking about this, perhaps the bug is that Python 3 doesn't have a future_builtins module? Consider:


$ python2.6
Python 2.6.8 (unknown, Sep 28 2013, 12:09:28) 
[GCC 4.6.3] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import with_statement
>>> from __future__ import print_function
>>> from future_builtins import map, zip
>>> quit()


versus:


$ python3.3
Python 3.3.2 (default, Sep 28 2013, 12:00:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import with_statement
>>> from __future__ import print_function
>>> from future_builtins import map, zip
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'future_builtins'
>>> quit()


The expectation from the __future__ imports is that once a feature is part of Python, the import is a harmless no-op. You could expect the same from  future_builtins as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19111>
_______________________________________

From report at bugs.python.org  Sun Sep 29 17:39:51 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 15:39:51 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380469191.4.0.160231867501.issue19124@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

As I wrote in http://bugs.python.org/issue19066, on Windows execv() is equivalent to

    os.spawnv(os.P_NOWAIT, ...)
    os._exit(0)

This means that control is returned to cmd when the child process *starts* (and afterwards you have cmd and the child connected to the same console).

On Unix control is returned to the shell only once the child process *ends*.

Although it might be less memory efficient, you would actually get something closer to Unix behaviour by replacing os.execv(...) with

    sts = os.spawnv(os.P_WAIT, ...)
    _exit(sts)

or

    sts = subprocess.call(...)
    _exit(sts)

This is why I said that execv() is useless on Windows and that you should just use subprocess instead.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 18:09:07 2013
From: report at bugs.python.org (Jason Smestad)
Date: Sun, 29 Sep 2013 16:09:07 +0000
Subject: [issue19129] 6.2.1. Regular Expression Syntax flags
Message-ID: <1380470947.27.0.0292455287204.issue19129@psf.upfronthosting.co.za>


New submission from Jason Smestad:

In the Python 3.3.2 documentation in the section "6.2.1. Regular Expression Syntax" subsection "(?aiLmsux)" it describes flags that are set by extention notation. 6 of the flags are described in detail with links for each flag, but the "u" flag is not described or linked to in this subsection. 

When reading this subsection, you may be confused as to what the "u" flag is for, or if it even belongs there, since there is no link. I suggest that a link be added in that subsection to the re.A section in 6.2.2, and that re.U be added as a title for the re.A subsection in 6.2.2.

----------
assignee: docs at python
components: Documentation
messages: 198600
nosy: docs at python, endoalir
priority: normal
severity: normal
status: open
title: 6.2.1. Regular Expression Syntax flags
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19129>
_______________________________________

From report at bugs.python.org  Sun Sep 29 18:34:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 16:34:34 +0000
Subject: [issue19112] tests of _TestProcess are not run by the multiprocessing
 test suite
In-Reply-To: <1380383507.04.0.708798356972.issue19112@psf.upfronthosting.co.za>
Message-ID: <3cnslY5tBJz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset a3dd2ccdccf6 by Richard Oudkerk in branch '2.7':
Issue #19112: avoid using function defined in method.
http://hg.python.org/cpython/rev/a3dd2ccdccf6

New changeset 74752bfa6357 by Richard Oudkerk in branch '3.3':
Issue #19112: avoid using function defined in method.
http://hg.python.org/cpython/rev/74752bfa6357

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19112>
_______________________________________

From report at bugs.python.org  Sun Sep 29 18:58:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 16:58:41 +0000
Subject: [issue19130] PCbuild/readme.txt not up-to-date
Message-ID: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PCbuild/readme.txt mentions VS2008 while VS2010 is required to build 3.4. Am I missing something?

----------
assignee: docs at python
components: Documentation
messages: 198602
nosy: brian.curtin, docs at python, loewis, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: PCbuild/readme.txt not up-to-date
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19130>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:00:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 29 Sep 2013 17:00:49 +0000
Subject: [issue19130] PCbuild/readme.txt not up-to-date
In-Reply-To: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>
Message-ID: <1380474049.61.0.209239818985.issue19130@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It also mentions VS 10.0 which is 2010 ... I'm fixing it now.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19130>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:02:54 2013
From: report at bugs.python.org (Tim Golden)
Date: Sun, 29 Sep 2013 17:02:54 +0000
Subject: [issue19130] PCbuild/readme.txt not up-to-date
In-Reply-To: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>
Message-ID: <52485D3A.4030807@timgolden.me.uk>


Tim Golden added the comment:

Nope. Looks like a mistake. Confusingly, the header refers to VC++ 10.0 
which is VS 2010 (I think). AFAICT a global s/2008/2010/ would be the 
thing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19130>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:05:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 17:05:34 +0000
Subject: [issue19130] PCbuild/readme.txt not up-to-date
In-Reply-To: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>
Message-ID: <3cntRK61xfz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset 69bb4bf24b07 by Christian Heimes in branch '3.3':
Issue #19130: Correct PCbuild/readme.txt, Python 3.3 and 3.4 require VS 2010
http://hg.python.org/cpython/rev/69bb4bf24b07

New changeset f5a7090e16b7 by Christian Heimes in branch 'default':
Issue #19130: Correct PCbuild/readme.txt, Python 3.3 and 3.4 require VS 2010
http://hg.python.org/cpython/rev/f5a7090e16b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19130>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:09:00 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 17:09:00 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1380456206.36.0.261451077717.issue19066@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xLwsC27PuOYs315G8OjQ8mEqEwAtDyHm2yW0X+AAahCeA@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 3:03 PM, Richard Oudkerk <report at bugs.python.org> wrote:
>
> _spawn*() and _exec*() are implemented by the C runtime library.  spawn*() and execv() are (deprecated) aliases.

It is said that execv() is deprecated, but it is not said that it is
alias of _execv(). It is only said that _execv() is C++ compliant.
http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx

> The the first message is about someone's attempt to work around the problems with embedded spaces and double quotes by writing a function to escape each argument.  He says he had a partial success.

Don't we have such function already? I don't see the problem in
quoting the string.

> Surely this is basic reading comprehension?

I am mentally crippled. Sorry about that.

>> > Note that on Windows exec*() is useless: it just starts a subprocess and
>> > exits the current process.  You can use subprocess to get the same effect.
>>
>> Are you describing Windows implementation of _exec()
>> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current
>> Python implementation?
>
> The Windows implementaion of _exec().

Does it start child process in foreground or in background? Did you
compile examples on
http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
And I believe that compiling with GCC may lead to different results.

>> > Just use subprocess instead which gets this stuff right.
>>
>> subprocess doesn't replace os.exec*, see issue19060
>
> On Unix subprocess does not replace os.exec*().  That is because on Unix exec*() replaces the current process with a new process with the *same pid*.  subprocess cannot do this.
>
> But on Windows os.exec*() just starts an independent process with a *different pid* and exits the current process.  The line
>
>     os.execv(path, args)
>
> is equivalent to
>
>     os.spawnv(os.P_NOWAIT, path, args)
>     os._exit(0)

I don't mind if it runs child process with different pid, but why it
runs new process in background. Unix version doesn't do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:10:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 17:10:28 +0000
Subject: [issue19130] PCbuild/readme.txt not up-to-date
In-Reply-To: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>
Message-ID: <3cntXz45K1z7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset b602edf9b100 by Christian Heimes in branch '3.3':
Issue #19130: mention historic VS 2008 build dir, too
http://hg.python.org/cpython/rev/b602edf9b100

New changeset a16b83ff7fb1 by Christian Heimes in branch 'default':
Issue #19130: mention historic VS 2008 build dir, too
http://hg.python.org/cpython/rev/a16b83ff7fb1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19130>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:22:01 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 29 Sep 2013 17:22:01 +0000
Subject: [issue19130] PCbuild/readme.txt not up-to-date
In-Reply-To: <1380473921.46.0.878582120992.issue19130@psf.upfronthosting.co.za>
Message-ID: <1380475321.14.0.139504948011.issue19130@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Issue17326 can now be closed as a duplicate of this issue.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19130>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:24:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 17:24:18 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1380475458.49.0.878765814812.issue10241@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm closing this issue as fixed though I'm not entirely sure the fix is right. The alpha cycle will allow us to get feedback on potential incompatibilities with third-party software.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10241>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:24:58 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 29 Sep 2013 17:24:58 +0000
Subject: [issue16037] httplib: header parsing is not unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1380475498.11.0.293789227593.issue16037@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

As we discussed in other issues regarding the similar problem, I don't really want to introduce a new exception in a point release of 2.6.  Is there any reason not to just raise HTTPException with the error message text?  Code that has to work across multiple 2.6.X versions won't be able to import the new exception, and thus cannot rely on it anyway.

If you agree, I'll make that change when I apply this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:26:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 17:26:06 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1380475566.09.0.355225937607.issue18674@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think the "new new module initialization scheme", if it takes steam, is much more promising to solve the underlying issue. I'm inclined to close this entry as "won't fix", what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18674>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:28:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 17:28:01 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380475681.96.0.942759567302.issue19078@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Stefan, what do you think about Claudiu's patch? Should a test be added to test_buffer as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:29:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 17:29:29 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>
Message-ID: <1380475769.92.0.99670967581.issue19095@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:31:36 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 17:31:36 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380469191.4.0.160231867501.issue19124@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+y+HLB7bQA7xK79OSeDYwfUqxBbgLJvkQRJFTWkYHArg@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 6:39 PM, Richard Oudkerk <report at bugs.python.org> wrote:
>
> Richard Oudkerk added the comment:
>
> As I wrote in http://bugs.python.org/issue19066, on Windows execv() is equivalent to
>
>     os.spawnv(os.P_NOWAIT, ...)
>     os._exit(0)

Where did you get that info? MSDN is silent about that.
http://msdn.microsoft.com/en-us/library/886kc0as(v=vs.90).aspx

> This means that control is returned to cmd when the child process *starts* (and afterwards you have cmd and the child connected to the same console).
>
> On Unix control is returned to the shell only once the child process *ends*.

That was my conclusion also.

> Although it might be less memory efficient, you would actually get something closer to Unix behaviour by replacing os.execv(...) with
>
>     sts = os.spawnv(os.P_WAIT, ...)
>     _exit(sts)
>
> or
>
>     sts = subprocess.call(...)
>     _exit(sts)
>
> This is why I said that execv() is useless on Windows and that you should just use subprocess instead.

The problem is not in what I should or should not use. The problem
that existing scripts that work on Unix and use os.execv() to launch
interactive scripts, on Windows behave absolutely weird and unusable
behavior. I previously experienced this with SCons, but couldn't get
the reason. Now I experience this with basic Android development tools
and dug down to this. It is clearly a big mess from this side of
Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:48:49 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 17:48:49 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380476929.95.0.0410734716769.issue19066@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> It is said that execv() is deprecated, but it is not said that it is
> alias of _execv(). It is only said that _execv() is C++ compliant.
> http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx

Microsoft seems to have decided that all functions in the C runtime which don't begin with an underscore, and are not included in the ANSI C standard should be deprecated.  This includes all the fd functions like read(), write(), open(), close(), ...  There is no difference in behaviour between these and the underscore versions.

...

> Don't we have such function already? I don't see the problem in
> quoting the string.

No one seems to know how to write such a quoting function.

...

> Does it start child process in foreground or in background? Did you
> compile examples on
> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
> VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
> And I believe that compiling with GCC may lead to different results.

There is no such thing as a background task in Windows.  A process is either attached to a console, or it isn't.  When you use execv() to start a process, it inherits the parent's console.

On Unix try replacing os.execv(...) by

    os.spawnv(os.P_NOWAIT, ...)
    os._exit(0)

and you will probably get the same behaviour where the shell and the child process both behave as conflicting foreground tasks.

..

> I don't mind if it runs child process with different pid, but why it
> runs new process in background. Unix version doesn't do this.

The point is that the shell waits for its child process to finish by using waitpid() (or something similar) on the child's pid.  If the child uses execv() then the child is replaced by a grandchild process with the same pid.  From the point of view of the shell, the child and the grandchild are the same process, and waitpid() will not stop until the grandchild terminates.

This issue should be closed: just use subprocess instead.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:50:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 17:50:59 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>
Message-ID: <3cnvRl1TtQz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset ddcdf7f7eac8 by Antoine Pitrou in branch 'default':
Issue #19095: SSLSocket.getpeercert() now raises ValueError when the SSL handshake hasn't been done.
http://hg.python.org/cpython/rev/ddcdf7f7eac8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:53:56 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 17:53:56 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380477236.73.0.592881006747.issue19124@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Where did you get that info? MSDN is silent about that.
> http://msdn.microsoft.com/en-us/library/886kc0as(v=vs.90).aspx

Reading the source code for the C runtime included with Visual Studio.

> The problem is not in what I should or should not use. The problem
> that existing scripts that work on Unix and use os.execv() to launch
> interactive scripts, on Windows behave absolutely weird and unusable
> behavior. I previously experienced this with SCons, but couldn't get
> the reason. Now I experience this with basic Android development tools
> and dug down to this. It is clearly a big mess from this side of
> Windows.

As said before (more than once), os.exec*() is useless on Windows: just use subprocess.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:55:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 17:55:16 +0000
Subject: [issue19095] Document SSLSocket.getpeercert always returns None
 without do_handshake
In-Reply-To: <1380151982.82.0.304891420803.issue19095@psf.upfronthosting.co.za>
Message-ID: <1380477316.82.0.486053474277.issue19095@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Change committed in 3.4. Thanks for reporting!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19095>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:55:20 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 29 Sep 2013 17:55:20 +0000
Subject: [issue16037] httplib: header parsing is not unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1380477320.06.0.866622825913.issue16037@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

I'm fine with not introducing a new exception for 2.6 (or any other version for that matter), so go for it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 29 19:58:39 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 29 Sep 2013 17:58:39 +0000
Subject: [issue16037] httplib: header parsing is not unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1380477519.02.0.911016424108.issue16037@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I'm just going to go ahead and commit this patch to 2.6 with the change I mentioned.  Does anything else need to be done for 2.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:01:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 18:01:31 +0000
Subject: [issue16037] httplib: header parsing is not unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <3cnvgt4BGLz7LkD@mail.python.org>


Roundup Robot added the comment:

New changeset 582e5072ff89 by Barry Warsaw in branch '2.6':
- Issue #16037: HTTPMessage.readheaders() raises an HTTPException when more
http://hg.python.org/cpython/rev/582e5072ff89

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:02:43 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 29 Sep 2013 18:02:43 +0000
Subject: [issue16037] httplib: header parsing is not unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1380477763.87.0.378500104564.issue16037@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Thanks!

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:16:57 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 29 Sep 2013 18:16:57 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1380478617.14.0.76851771208.issue18674@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18674>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:26:49 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 29 Sep 2013 18:26:49 +0000
Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in
 __exit__ callbacks of inner context managers
In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za>
Message-ID: <1380479209.2.0.551719797564.issue19092@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

Indeed, that works, thanks. Here is the updated patch for review, passing all tests.

----------
Added file: http://bugs.python.org/file31908/exitstack.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19092>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:47:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 18:47:29 +0000
Subject: [issue19128] duplicate test name in Mac/Tools/Doc/setup.py
In-Reply-To: <1380454743.3.0.0899741731446.issue19128@psf.upfronthosting.co.za>
Message-ID: <3cnwhx005Jz7Lkr@mail.python.org>


Roundup Robot added the comment:

New changeset c865187aa14d by Ned Deily in branch 'default':
Issue #19128: Remove nonfunctional, unused Mac help indexing tool from repo.
http://hg.python.org/cpython/rev/c865187aa14d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19128>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:48:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Sep 2013 18:48:35 +0000
Subject: [issue19128] duplicate test name in Mac/Tools/Doc/setup.py
In-Reply-To: <1380454743.3.0.0899741731446.issue19128@psf.upfronthosting.co.za>
Message-ID: <1380480515.49.0.984430694926.issue19128@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19128>
_______________________________________

From report at bugs.python.org  Sun Sep 29 20:49:54 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 18:49:54 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380480594.08.0.699498498156.issue19066@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Hey. This ticket is about os.execv failing on spaced paths on Windows. It is not a duplicate of issue19124.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:03:26 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 19:03:26 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1380476929.95.0.0410734716769.issue19066@psf.upfronthosting.co.za>
Message-ID: <CAPkN8xJEBKbkzGit0MzUBpceL8z9zbGhateaM_W=M9yJBKviuw@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 8:48 PM, Richard Oudkerk <report at bugs.python.org> wrote:
>
>> Don't we have such function already? I don't see the problem in
>> quoting the string.
>
> No one seems to know how to write such a quoting function.

Why escape quotes with slash and surrounding in quotes doesn't help?
http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx
How does Linux and subprocess on Windows survive then?
If I am not mistaken both subprocess and execv on Windows use
CreateProcess. Does subprocess fail as well?

>> Does it start child process in foreground or in background? Did you
>> compile examples on
>> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
>> VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
>> And I believe that compiling with GCC may lead to different results.
>
> There is no such thing as a background task in Windows.  A process is either attached to a console, or it isn't.  When you use execv() to start a process, it inherits the parent's console.

All right. Then why does it start to interfere with running cmd.exe
(in issue19124)? If it inherits console, it should continue to "own"
it exclusively, and not return it back to parent cmd.exe

> On Unix try replacing os.execv(...) by
>
>     os.spawnv(os.P_NOWAIT, ...)
>     os._exit(0)
>
> and you will probably get the same behaviour where the shell and the child process both behave as conflicting foreground tasks.

Maybe Python code doesn't use _execv() at all on Windows and uses
these spawnv's?

> ..
>
>> I don't mind if it runs child process with different pid, but why it
>> runs new process in background. Unix version doesn't do this.
>
> The point is that the shell waits for its child process to finish by using waitpid() (or something similar) on the child's pid.  If the child uses execv() then the child is replaced by a grandchild process with the same pid.  From the point of view of the shell, the child and the grandchild are the same process, and waitpid() will not stop until the grandchild terminates.

I can not accept your point when you don't know for sure how cmd.exe
waits for child process to exit. Are you sure that it doesn't use some
blocking CreateProcess call? Are you sure that Python on Windows calls
exactly _execv and not some spawn surrogate?

> This issue should be closed: just use subprocess instead.

We need some quorum on this. I'd like to hear two more people that can
confirm and agree with your position. I don't want to think that
usability of execv() on Windows can not be improved, because people
who love Linux doesn't think that this OS deserves some care. I'd like
to run Python scripts with the same base behaviour regardless of
platform. If that's impossible, that should be documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:08:26 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 19:08:26 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380477236.73.0.592881006747.issue19124@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+7ViQ+pJNsFRCx5vs38fr8F4ACLVErrA+rHwVeQr_G9A@mail.gmail.com>


anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 8:53 PM, Richard Oudkerk <report at bugs.python.org> wrote:
>
> Richard Oudkerk added the comment:
>
>> Where did you get that info? MSDN is silent about that.
>> http://msdn.microsoft.com/en-us/library/886kc0as(v=vs.90).aspx
>
> Reading the source code for the C runtime included with Visual Studio.

Visual Studio 10+ ? Is it available somewhere for a reference?

>> The problem is not in what I should or should not use. The problem
>> that existing scripts that work on Unix and use os.execv() to launch
>> interactive scripts, on Windows behave absolutely weird and unusable
>> behavior. I previously experienced this with SCons, but couldn't get
>> the reason. Now I experience this with basic Android development tools
>> and dug down to this. It is clearly a big mess from this side of
>> Windows.
>
> As said before (more than once), os.exec*() is useless on Windows: just use subprocess.

I value your expert opinion, but to increase the bus factor, I can not
leave it without asking for reasons.

Have you tried to run examples provided by MSDN - do they exhibit the
same behavior as Python script I attached earlier and described in the
first message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:10:05 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 19:10:05 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380481805.37.0.972848795554.issue19124@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

I can't use subprocess. These are official "business suite" scripts for Android development from Google.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:11:02 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 29 Sep 2013 19:11:02 +0000
Subject: [issue16037] httplib: header parsing is unlimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1380481862.5.0.854715914192.issue16037@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
title: httplib: header parsing is not unlimited -> httplib: header parsing is unlimited

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:11:10 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 29 Sep 2013 19:11:10 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380481870.68.0.374532698376.issue19124@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:12:05 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 19:12:05 +0000
Subject: [issue19123] duplicate test name in Lib/test/test_regrtest.py
In-Reply-To: <1380450246.86.0.728804280049.issue19123@psf.upfronthosting.co.za>
Message-ID: <1380481925.35.0.873306626371.issue19123@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

After the last changeset 39f9adc8ad5b there are still 3 methods named
test_findleaks. The proposed patch was also missing one of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19123>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:18:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 19:18:51 +0000
Subject: [issue19123] duplicate test name in Lib/test/test_regrtest.py
In-Reply-To: <1380450246.86.0.728804280049.issue19123@psf.upfronthosting.co.za>
Message-ID: <3cnxP63Pndz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 280d403434c4 by Benjamin Peterson in branch 'default':
rename some more tests to avoid duplicate names (#19123)
http://hg.python.org/cpython/rev/280d403434c4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19123>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:24:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 19:24:02 +0000
Subject: [issue19131] Broken support of compressed AIFC files
Message-ID: <1380482642.92.0.440951147189.issue19131@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In u-law and A-law compressed AIFC files the sampleSize field is equal to 8 (bits). The aifc module transparently compress/uncompress audio data to 16-bit, but doesn't support the samplewidth parameter in consistency. This causes two bugs:

1. On read getsampwidth() returns 1, but should return 2 (bytes per sample in uncompressed audio data). readframes() returns twice less data than expected.

>>> import aifc
>>> f = aifc.open('pluck-ulaw.aifc', 'r')
>>> f.getparams()
_aifc_params(nchannels=2, sampwidth=1, framerate=11025, nframes=3307, comptype=b'ulaw', compname=b'')
>>> f.readframes(1)
b',\x02'

f.readframes(1) should return 4 bytes (2 channels, 16-bit uncompressed data).

2. On write wrong value 2 is saved in the sampleSize field. Resulting file is invalid and can't be read in other programs.

Here is a patch and sample file. For tests see issue18919.

I'm sure G722 support is broken too, but I have no any testing files.

----------
components: Library (Lib)
files: aifc_sampwidth.patch
keywords: patch
messages: 198631
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Broken support of compressed AIFC files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31909/aifc_sampwidth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19131>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:24:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 19:24:56 +0000
Subject: [issue19131] Broken support of compressed AIFC files
In-Reply-To: <1380482642.92.0.440951147189.issue19131@psf.upfronthosting.co.za>
Message-ID: <1380482696.69.0.160557527962.issue19131@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31910/pluck-ulaw.aifc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19131>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:31:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 19:31:40 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1380483100.59.0.92034504844.issue18919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch updated. Now files created in external program (Audacity) are used for testing. This exposed yet one bug, in the aifc module (issue19131).

----------
dependencies: +Broken support of compressed AIFC files
Added file: http://bugs.python.org/file31911/audiotests_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18919>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:31:40 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Sun, 29 Sep 2013 19:31:40 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1380483100.85.0.0138585953636.issue18857@psf.upfronthosting.co.za>


Joshua Johnston added the comment:

Hi Senthil,
You can open the html file with a browser and inspect the data posting to itself without a web server running. That is how I tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:33:50 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Sun, 29 Sep 2013 19:33:50 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1380483230.44.0.168076233866.issue18857@psf.upfronthosting.co.za>


Joshua Johnston added the comment:

I still believe that since None represents the absence of a value it should not be urlencoded as the string 'None'. I am not sure what they best way to url encode it is, but I know that 'None' is not it.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:36:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 19:36:17 +0000
Subject: [issue18919] Unify audio modules tests
In-Reply-To: <1378293110.61.0.780572869606.issue18919@psf.upfronthosting.co.za>
Message-ID: <1380483377.92.0.237819966237.issue18919@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file31912/makeaudiotests.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18919>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:40:55 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 29 Sep 2013 19:40:55 +0000
Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py
In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za>
Message-ID: <1380483655.7.0.988711410146.issue19119@psf.upfronthosting.co.za>


Tim Peters added the comment:

Good catch!  Would like to hear from Raymond what the intent of these tests was - looks like "the real" test_get_only (which hasn't been executing) has multiple failures.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19119>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:41:03 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 19:41:03 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1380483663.8.0.704532177915.issue5845@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

There is a backward compatibility issue with changeset d5ef330bac50
that enables tab-completion in the interactive interpreter by default.

When a user is not aware of this new feature and has been implementing
up to now her/his PYTHONSTARTUP file with the first example given in
python 3.3 documentation at

http://docs.python.org/3/library/readline.html?highlight=readline#example

then each new interactive python 3.4 session reads (appending them)
both history files which are saved on exit. Thus those files double
their size after each interactive python 3.4 session and pretty soon
become few mega bytes long with a python start up time that becomes
quite noticeable.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:53:00 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 19:53:00 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380484380.3.0.0808703226538.issue19066@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Hey. This ticket is about os.execv failing on spaced paths on Windows. It 
> is not a duplicate of issue19124.

It is a duplicate of #436259 "[Windows] exec*/spawn* problem with spaces in args".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:53:59 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 19:53:59 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380484439.51.0.32225757477.issue19124@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Visual Studio 10+ ? Is it available somewhere for a reference?

Old versions of the relevant files are here:

http://www.controllogics.com/software/VB6/VC98/CRT/SRC/EXECVE.C
http://www.controllogics.com/software/VB6/VC98/CRT/SRC/SPAWNVE.C
http://www.controllogics.com/software/VB6/VC98/CRT/SRC/DOSPAWN.C

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:54:21 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 19:54:21 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380484461.96.0.988778723957.issue19066@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy:  -sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:54:28 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Sep 2013 19:54:28 +0000
Subject: [issue19124] os.execv executes in background on Windows
In-Reply-To: <1380451602.11.0.517013085188.issue19124@psf.upfronthosting.co.za>
Message-ID: <1380484468.78.0.414532289092.issue19124@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy:  -sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19124>
_______________________________________

From report at bugs.python.org  Sun Sep 29 21:57:09 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 29 Sep 2013 19:57:09 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1380484629.55.0.737650461728.issue16041@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Attached a patch for 2.6. 

Due to how tests are in 2.6, this adds one more test case with evil server, which basically just returns too long lines.

----------
Added file: http://bugs.python.org/file31913/issue16041_py26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:00:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 20:00:50 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1380483663.8.0.704532177915.issue5845@psf.upfronthosting.co.za>
Message-ID: <1380484846.2489.4.camel@fsol>


Antoine Pitrou added the comment:

> When a user is not aware of this new feature and has been implementing
> up to now her/his PYTHONSTARTUP file with the first example given in
> python 3.3 documentation at
> 
> http://docs.python.org/3/library/readline.html?highlight=readline#example
> 
> then each new interactive python 3.4 session reads (appending them)
> both history files which are saved on exit. Thus those files double
> their size after each interactive python 3.4 session and pretty soon
> become few mega bytes long with a python start up time that becomes
> quite noticeable.

Interesting. A way to avoid doing this would be to only load history if
no history is already present. Since the sys.__interactivehook__ is
executed after PYTHONSTARTUP, this would allow the latter to take
precedence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:05:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 20:05:50 +0000
Subject: [issue19132] Add compact mode to pprint
Message-ID: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

pprint produces not very nice output for collections with a large number of short elements (see msg198556). For example pprint.pprint(list(range(40))) outputs more than 40 short lines, while print(repr(list(range(40)))) takes only 2 lines on 80-column terminal.

I propose to add new boolean option "compact". With compact=True pprint will try combine as much short one-line subelements in one line as possible. Every multiline element will be printed on separated lines.

Examples:

>>> pprint.pprint(list(range(40)), width=50, compact=True)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
 38, 39]
>>> pprint.pprint(['one string', 'other string', 'very very long string which continued on several lines', 'and again', 'and again', 'and again', 'and again'], width=50, compact=True)
['one string', 'other string',
 'very very long string which is continued on '
 'several lines',
 'and again', 'and again', 'and again',
 'and again']

----------
components: Library (Lib)
messages: 198641
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add compact mode to pprint
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:06:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 20:06:57 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1380485217.59.0.266149313003.issue5845@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Attaching patch to only load history file if no history exists.

----------
keywords:  -needs review
resolution:  -> fixed
Added file: http://bugs.python.org/file31914/rl_history_guard.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:16:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 20:16:43 +0000
Subject: [issue19132] Add compact mode to pprint
In-Reply-To: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>
Message-ID: <1380485803.36.0.5403490738.issue19132@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think it looks good on the principle.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:17:09 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Sep 2013 20:17:09 +0000
Subject: [issue19066] os.execv fails with spaced names on Windows
In-Reply-To: <1379816488.54.0.686917374017.issue19066@psf.upfronthosting.co.za>
Message-ID: <1380485829.03.0.600771339809.issue19066@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Reminder: you are not supposed to re-open issues.

I agree with Richard that this is a duplicate as submitted. The difference is that we now have subprocess; that is our fix for several problems. I will re-close unless you make a *specific* suggestion for a doc change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19066>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:19:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Sep 2013 20:19:15 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <3cnykp3b3Mz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 687dd81cee3b by Antoine Pitrou in branch 'default':
Issue #5845: In site.py, only load readline history from ~/.python_history if no history has been read already.  This avoids double writes to the history file at shutdown.
http://hg.python.org/cpython/rev/687dd81cee3b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:22:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 20:22:18 +0000
Subject: [issue19103] Use pprint in displayhook
In-Reply-To: <1380282107.38.0.301660122877.issue19103@psf.upfronthosting.co.za>
Message-ID: <1380486138.19.0.292024315147.issue19103@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> (in the patch, import of sys and pprint should be done once at module level and not repeated with every line of interactive output).

See a comment at the start of the Lib/_sitebuiltins.py file. Yes, importing sys in the function is redundant.

> For instance, try list(range(40)) with the two options.

Well, I have opened issue19132 for this.

> This is not to mention doctest and other test breakage.

AFAIK doctests doesn't test output longer than 80 characters.

> I believe the majority consensus on python-ideas was to reject this until pprint is much improved, and then reconsider.

There are other pprint-related issue which are opened long time without any progress (e.g. issue7434). I intend making progress on issues which are required for fixing pprint enough to be reasonable replacement for displayhook.

----------
dependencies: +Add compact mode to pprint

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19103>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:34:28 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Sun, 29 Sep 2013 20:34:28 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1380486868.97.0.136800287751.issue18314@psf.upfronthosting.co.za>


Kim Gr?sman added the comment:

Attached is a patch that considers directory symlinks and junction points equivalent.

I'm struggling with the test -- would it be acceptable to only run this test on platforms that have mklink /j (Windows Vista and higher)?

I've looked at programmatic means of creating junction points, but it involves enough Win32 interop to make it a candidate for a module all by itself (it's REALLY messy.)

Any ideas?

Thanks!

----------
keywords: +patch
Added file: http://bugs.python.org/file31915/unlink_junction.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:43:44 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 29 Sep 2013 20:43:44 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1380487424.91.0.689642460736.issue5845@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch fixes the problem on my setup. A very minor glitch: after
manually emptying or removing the PYTHONSTARTUP history file, the
history is loaded with the content of ~/.python_history on the next
session.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Sep 29 22:59:55 2013
From: report at bugs.python.org (Tim Golden)
Date: Sun, 29 Sep 2013 20:59:55 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1380488395.37.0.311936265577.issue18314@psf.upfronthosting.co.za>


Tim Golden added the comment:

I'll try to pick this one up over the next few days. Feel free to ping me if it drops into silence!

----------
assignee:  -> tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:02:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 21:02:51 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1380488571.2.0.3843288381.issue12641@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Oscar, thanks for the patches. Two things:
- in the 2.7 patch, could you explicitly close the popen() file object instead of relying on deallocation to do it?
- have you signed a contributor's agreement? http://www.python.org/psf/contrib/

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:05:20 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 29 Sep 2013 21:05:20 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1380488720.17.0.398342492545.issue16041@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Looks good, although only the POP3 exception is actually tested.  The POP3_SSL exception isn't tested.  Any chance you could add a test for that (obviously, only if `import ssl` succeeds)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:11:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 21:11:13 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380489073.42.0.780447294453.issue19087@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Results under Windows:

- before:

PCbuild\amd64\python.exe -m timeit "b=bytearray(100000)" "while b: b[-1:] = b''"
10 loops, best of 3: 74.8 msec per loop

PCbuild\amd64\python.exe -m timeit "b=bytearray(100000)" "while b: b[:1] = b''"
10 loops, best of 3: 330 msec per loop

- after:

PCbuild\amd64\python.exe -m timeit "b=bytearray(100000)" "while b: b[-1:] = b''"
10 loops, best of 3: 73.9 msec per loop

PCbuild\amd64\python.exe -m timeit "b=bytearray(100000)" "while b: b[:1] = b''"
10 loops, best of 3: 73.8 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:13:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 21:13:22 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1380487424.91.0.689642460736.issue5845@psf.upfronthosting.co.za>
Message-ID: <1380489200.2489.5.camel@fsol>


Antoine Pitrou added the comment:

> The patch fixes the problem on my setup. A very minor glitch: after
> manually emptying or removing the PYTHONSTARTUP history file, the
> history is loaded with the content of ~/.python_history on the next
> session.

Yes, the only way to know if a history file has already been loaded with
readline seems to be to query the history itself. So, if the history is
empty, we consider no file has been loaded.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:33:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 21:33:10 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380490390.64.0.530685066126.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> A generic example is to parse messages out of a TCP stream. Basically
any protocol transported on TCP needs such a facility, or has to find
workarounds (which are either suboptimal or complicated).

Could you please show concrete code in which you are going to use this optimization?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:40:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 21:40:37 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380490837.02.0.919126354289.issue19087@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Could you please show concrete code in which you are going to use this 
> optimization?

There's no need to "use" this optimization. Any networking code that has to find message boundaries and split on them will benefit. If you don't understand that, I'm not willing to explain it for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:49:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 21:49:43 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380491383.51.0.329282138305.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Deleting a slice at the front of a bytearray have linear complexity from the size of a bytearray (in any case del b[:1] is a little faster than b[:1] = b''). I doubt than any performance critical code do it instead of increasing an index in constant time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:51:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 21:51:14 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380491383.51.0.329282138305.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380491472.2489.7.camel@fsol>


Antoine Pitrou added the comment:

> Deleting a slice at the front of a bytearray have linear complexity
> from the size of a bytearray (in any case del b[:1] is a little faster
> than b[:1] = b''). I doubt than any performance critical code do it
> instead of increasing an index in constant time.

Increasing an index requires that you compact the bytearray from time to
time, lest it fills the whole memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:54:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 21:54:48 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380491688.62.0.338062990879.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The same is true with your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Sun Sep 29 23:55:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 21:55:18 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380491688.62.0.338062990879.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380491716.2489.8.camel@fsol>


Antoine Pitrou added the comment:

> The same is true with your patch.

I don't understand. What is "true with my patch"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:01:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 22:01:27 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380492086.99.0.469592164643.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You increase internal index in a bytearray. A bytearray with small visible length can consume much hidden memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:03:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 22:03:26 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380492086.99.0.469592164643.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380492204.2489.10.camel@fsol>


Antoine Pitrou added the comment:

> You increase internal index in a bytearray. A bytearray with small
> visible length can consume much hidden memory.

No, because PyByteArray_Resize() is always called afterwards to ensure
that the buffer is resized when it gets below 50% usage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:11:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 22:11:27 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380492204.2489.10.camel@fsol>
Message-ID: <CAAuNNr4oGWhgFm_wC1eUgWfGjRm24sF-ot_sLpyw_Wxch0cmng@mail.gmail.com>


Serhiy Storchaka added the comment:

> No, because PyByteArray_Resize() is always called afterwards to ensure
> that the buffer is resized when it gets below 50% usage.
>

I.e. the bytearray is compacted from time to time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:18:19 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Sep 2013 22:18:19 +0000
Subject: [issue17326] Windows build docs still referring to VS 2008 in 3.3
In-Reply-To: <1362142705.89.0.367756520949.issue17326@psf.upfronthosting.co.za>
Message-ID: <1380493099.29.0.500990705837.issue17326@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> PCbuild/readme.txt not up-to-date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17326>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:19:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Sep 2013 22:19:05 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380493145.83.0.783008717589.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Serhiy: "I doubt than any performance critical code do it instead of increasing an index in constant time."

Sorry, I don't get your point. It's not become Python is inefficient that developers must develop workarounds. Antoine's patch is simple, elegant, and offer better performances for "free".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:22:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 22:22:46 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <CAAuNNr4oGWhgFm_wC1eUgWfGjRm24sF-ot_sLpyw_Wxch0cmng@mail.gmail.com>
Message-ID: <1380493364.2489.14.camel@fsol>


Antoine Pitrou added the comment:

> > No, because PyByteArray_Resize() is always called afterwards to ensure
> > that the buffer is resized when it gets below 50% usage.
> 
> I.e. the bytearray is compacted from time to time.

Is there a problem with that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:22:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Sep 2013 22:22:49 +0000
Subject: [issue16079] list duplicate test names with patchcheck
In-Reply-To: <1348827338.06.0.659343787847.issue16079@psf.upfronthosting.co.za>
Message-ID: <1380493369.6.0.331976159293.issue16079@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16079>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:41:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 22:41:15 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380494475.72.0.544283364206.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Is there a problem with that?

No more than with msg198657.

> Sorry, I don't get your point. It's not become Python is inefficient that developers must develop workarounds.

I'm not sure that "workarounds" are much worst than using this optimization. At least we still not seen real code which will benefit from this optimization.

> Antoine's patch is simple, elegant, and offer better performances for "free".

It offer better performances for "free" only for suboptimal code which currently have O(N) instead of O(1).

One of most used cases for bytearrays is accumulating. And the patch slow down this case.

$ ./python -m timeit  "b = bytearray(); a = b'x'"  "for i in range(10000): b += a"  "bytes(b)"

Without patch: 4.3 msec per loop
With patch: 4.62 msec per loops

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:48:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 22:48:04 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380494884.48.0.478521189828.issue19104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The whole point of pprint() is formatted output of containers such as list or dict. Before 3.4 it does not wrap long strings at all.

Of course I don't think this alternative is good. But at least it is better than producing illegal output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:51:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 22:51:40 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380494884.48.0.478521189828.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380495098.2489.16.camel@fsol>


Antoine Pitrou added the comment:

> The whole point of pprint() is formatted output of containers such as
> list or dict.

Well, the whole point of pprint is pretty-printing. Being restricted to
containers is a bug, not a feature...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:54:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Sep 2013 22:54:52 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1380495291.99.0.0251335987907.issue19104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I doubt we are able to fix it in maintained releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Mon Sep 30 00:56:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Sep 2013 22:56:37 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380495397.16.0.408848246366.issue19087@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> One of most used cases for bytearrays is accumulating.
> And the patch slow down this case.

I see no difference here. You are seeing a 10% slowdown, which is possibly a measurement glitch. The bottom line is that the performance remains approximately the same.

> It offer better performances for "free" only for suboptimal code
> which currently have O(N) instead of O(1).

The problem is the "suboptimal code" is also the natural way to write such code. If you know a simple and idiomatic way to write an optimal bytes FIFO, then please share it with us. Otherwise, I will happily ignore your line of argument here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 01:01:51 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Sep 2013 23:01:51 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380495711.48.0.369275000382.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> One of most used cases for bytearrays is accumulating. And the patch slow down this case.

Please don't use the raw timeit command for micro-benchmarks, it is not reliable. For example, I'm unable to reproduce your "slow down" (7% on a microbenchmark is not that large).

My micro-benchmark using my benchmark.py script:

Common platform:
Python version: 2.7.3 (default, Aug 9 2012, 17:23:57) [GCC 4.7.1 20120720 (Red Hat 4.7.1-5)]
Python unicode implementation: UCS-4
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Timer: time.time
Platform: Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow
Timer precision: 954 ns
CFLAGS: -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv
Bits: int=32, long=64, long long=64, size_t=64, void*=64

Platform of campaign original:
SCM: hg revision=687dd81cee3b tag=tip branch=default date="2013-09-29 22:18 +0200"
Date: 2013-09-30 00:59:42

Platform of campaign patched:
SCM: hg revision=687dd81cee3b+ tag=tip branch=default date="2013-09-29 22:18 +0200"
Date: 2013-09-30 00:59:07

------------+-------------+------------
Tests       |    original |     patched
------------+-------------+------------
10**1 bytes |  859 ns (*) |      864 ns
10**3 bytes | 55.8 us (*) |     56.4 us
10**5 bytes |     5.42 ms | 5.41 ms (*)
10**7 bytes |      578 ms |  563 ms (*)
------------+-------------+------------
Total       |      583 ms |  569 ms (*)
------------+-------------+------------

So performances are the same with the patch.

----------
Added file: http://bugs.python.org/file31916/bench_bytearray.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 01:03:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Sep 2013 23:03:17 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380495797.62.0.257709188461.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, by the way:

> $ ./python -m timeit  "b = bytearray(); a = b'x'"  "for i in range(10000): b += a"  "bytes(b)"

I'm not sure that it is what you expected: bytearray() is only initialized once ("setup" of timeit). You probably want to reinitialize at each loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 05:19:32 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 03:19:32 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380511172.83.0.668634158451.issue19072@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Mon Sep 30 05:27:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 03:27:04 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380511624.47.0.175702487084.issue19072@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think it was ever intended that decorators be chained together.  

The whole point is to control binding behavior during dotted look-up (when __getattribute__ is called) and not in other circumstances (such as a direct lookup in a class dictionary).

Note that classmethods typically wrap regular functions which have both __call__ and __get__ methods.   The classmethod object intentionally invokes the former instead of the latter which would unhelpfully create an inner bound or unbound method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Mon Sep 30 05:28:12 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 03:28:12 +0000
Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py
In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za>
Message-ID: <1380511692.75.0.839490695004.issue19119@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19119>
_______________________________________

From report at bugs.python.org  Mon Sep 30 05:36:56 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 03:36:56 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380512216.49.0.256289688659.issue18594@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 05:43:31 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 30 Sep 2013 03:43:31 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380512611.62.0.933925072888.issue19072@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

The classmethod __get__() method does:

static PyObject *
cm_descr_get(PyObject *self, PyObject *obj, PyObject *type)
{
    classmethod *cm = (classmethod *)self;

    if (cm->cm_callable == NULL) {
        PyErr_SetString(PyExc_RuntimeError,
                        "uninitialized classmethod object");
        return NULL;
    }
    if (type == NULL)
        type = (PyObject *)(Py_TYPE(obj));
    return PyMethod_New(cm->cm_callable,
                        type, (PyObject *)(Py_TYPE(type)));
}

So it isn't intentionally calling __call__(). If it still doing binding, but doing it by calling PyMethod_New() rather than using __get__() on the wrapped function. Where it wraps a regular function the result is same as if __get__() was called as __get__() for a regular function internally calls PyMethod_New() in the same way.

static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
    if (obj == Py_None)
        obj = NULL;
    return PyMethod_New(func, obj, type);
}

By not using __get__(), you deny the ability to have chained decorators that want/need the knowledge of the fact that binding was being done. The result for stacking multiple decorators which use regular functions (closures) is exactly the same, but you open up other possibilities of smarter decorators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Mon Sep 30 05:48:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Sep 2013 03:48:21 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>
Message-ID: <1380512901.67.0.924039421906.issue19017@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Charles-Francois, sorry to add you back to the bug, but (a) I thought you had agreed to a compromise patch that restarts signals in most cases but not for select(), poll() etc.; (b) I may have found a flaw in the idea.

The flaw (if it is one) is related to Py_AddPendingCall(). This "schedules" a pending callback, mostly for signals, but doesn't AFAICT interrupt the mainthread in any way. (TBH, I only understand the code for Python 2.7, and in that version I'm sure it doesn't.)

So is this a flaw? I'm nor sure. Can you think about it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Mon Sep 30 06:28:47 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 04:28:47 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380515327.52.0.565167209376.issue18594@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

A C-accelerator should ALWAYS be able to beat a pure python version if it does the same steps but without the overhead of the eval-loop.  And in special cases such as type(self)==Counter, it can do much better.

To resolve this report, the C accelerator needs to be fixed.  As Stefan pointed-out, the fast-path isn't being triggered because of PyDict_CheckExact test.  And, the fallback path can be sped-up as well (by doing the same steps in C as are being done with the pure python code).

----------
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 07:13:39 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 05:13:39 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
 correctly
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1380518019.19.0.549933147174.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Nick, the latest version of the patch looks like a correct solution.

Before applying, please add a block comment showing why these shenanigans are necessary (i.e. the use self.__lt__ instead of the less-than operator because the former doesn't fall into recursive operator flipping).

Also, please add a note to the docs indicating 1) that NotImplemented is now supported as of version 3.4 and 2) that when speed matters, it is always better to code all four ordering operators by hand rather than paying the cost of total_ordering's layers of indirection.

----------
assignee: rhettinger -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Mon Sep 30 07:52:05 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 05:52:05 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>
Message-ID: <1380520325.81.0.484241471973.issue19086@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Conceptually, I support the idea of having some way to avoid information loss by returning uncollapsed partial sums.  As you say, it would provide an essential primitive for parallel fsums and for cumulative subtotals.

If something along those lines were to be accepted, it would likely take one of two forms:
   
    fsum(iterable, detail=True) --> list_of_floats
    fsum_detailed(iterable) --> list_of_floats

Note, there is no need for a "carry" argument because the previous result can simply be prepended to the new data (for a running total) or combined in a final summation at the end (for parallel computation):

    detail = [0.0]
    for group in groups:
        detail = math.fsum_detailed(itertools.chain(detail, group))
        print('Running total', math.fsum(detail))

On the negative side, I think the use case is too exotic and no one will care about or learn to use this function.  Also, it usually isn't wise to expose the internals (we may want a completely different implementation someday).  Lastly, I think there is some virtue in keeping the API simple; otherwise, math.fsum() may ward-off some its potential users, resulting in even lower adoption than we have now.

With respect to the concerns about speed, I'm curious whether you've run your msum() edits under pypy or cython.  I would expect both to give excellent performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Mon Sep 30 08:05:09 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 06:05:09 +0000
Subject: [issue10042] functools.total_ordering fails to handle NotImplemented
 correctly
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1380521109.04.0.467350716719.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

One other thought:  The OrderedEnum example should not use the total ordering decorator.  

To the extent that the docs are trying to teach how to use Enum, they should focus on that task and not make a side-trip into the world of class decorators.   And to the extent that the docs are trying to show an example of production code, it would be better for speed and ease of tracing through a debugger to just define all four ordering comparisons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Mon Sep 30 08:11:37 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 06:11:37 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380521497.96.0.501168028698.issue19072@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll take a look at this in more detail in the next week or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Mon Sep 30 08:28:23 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 06:28:23 +0000
Subject: [issue19078] Allow reversed(memoryview), like memoryview
In-Reply-To: <1379953636.3.0.684645872717.issue19078@psf.upfronthosting.co.za>
Message-ID: <1380522503.19.0.701151245045.issue19078@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Claudiu's patch looks correct.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19078>
_______________________________________

From report at bugs.python.org  Mon Sep 30 09:11:02 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 30 Sep 2013 07:11:02 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1380525062.61.0.551862251385.issue18885@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

(replying to Guido's post in another thread)

> Charles-Francois, sorry to add you back to the bug, but (a) I thought you had agreed to a compromise patch that restarts signals in most cases but not for select(), poll() etc.; (b) I may have found a flaw in the idea.
> The flaw (if it is one) is related to Py_AddPendingCall(). This "schedules" a pending callback, mostly for signals, but doesn't AFAICT interrupt the mainthread in any way. (TBH, I only understand the code for Python 2.7, and in that version I'm sure it doesn't.)
>
> So is this a flaw? I'm nor sure. Can you think about it?

I don't think that's a problem: the way I was planning to tackle signals is to call PyErr_CheckSignals() before retrying upon EINTR: this runs signal handlers, and returns a non 0 value if an exception occured (e.g. KeyboardInterrupt): if that's the case, then we simply break out of the loop, and let the exception bubble up.
See e.g. http://hg.python.org/cpython/file/default/Modules/socketmodule.c#l3397

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Mon Sep 30 09:17:57 2013
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 30 Sep 2013 07:17:57 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1380525477.42.0.283898423251.issue19072@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

If you have the time, would be great if you can have a quick look at my wrapt package. That will give you an idea of where I am coming from in suggesting this change.

http://wrapt.readthedocs.org/en/latest/
http://wrapt.readthedocs.org/en/latest/issues.html
http://wrapt.readthedocs.org/en/latest/decorators.html
http://wrapt.readthedocs.org/en/latest/examples.html

In short, aiming to be able to write decorators which are properly transparent and aware of the context they are used in, so we don't have this silly situation at the moment where it is necessary to write distinct decorators for regular functions and instance methods. A classmethod around another decorator was the one place things will not work as would like to see them work.

I even did a talk about writing better decorators at PyCon NZ. Slides with notes at:

http://lanyrd.com/2013/kiwipycon/scpkbk/

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19072>
_______________________________________

From report at bugs.python.org  Mon Sep 30 09:30:18 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 07:30:18 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380526218.35.0.976781153571.issue18594@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31917/fix_counter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 09:39:24 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 07:39:24 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380526764.7.0.163658710732.issue18594@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: http://bugs.python.org/file31917/fix_counter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 09:39:45 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 07:39:45 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380526784.99.0.347541626199.issue18594@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file31918/fix_counter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 10:25:26 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 08:25:26 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380529526.13.0.326412436711.issue18594@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Repaired version
----------------
$ py -m timeit -s 'from random import seed, randrange; seed(8675309); data=[randrange(1000) for i in range(100000)]; from collections import Counter'  'Counter(data)'
100 loops, best of 3: 14.3 msec per loop
$ py -m timeit -s 'from random import seed, randrange; seed(8675309); data=[randrange(500000) for i in range(100000)]; from collections import Counter'  'Counter(data)'
10 loops, best of 3: 40.8 msec per loop

Current with accelerator
------------------------
$ py -m timeit -s 'from random import seed, randrange; seed(8675309); data=[randrange(1000) for i in range(100000)]; from collections import Counter'  'Counter(data)'
10 loops, best of 3: 61.7 msec per loop
$ py -m timeit -s 'from random import seed, randrange; seed(8675309); data=[randrange(500000) for i in range(100000)]; from collections import Counter'  'Counter(data)'
10 loops, best of 3: 118 msec per loop

Current without accelerator
---------------------------
$ py -m timeit -s 'from random import seed, randrange; seed(8675309); data=[randrange(1000) for i in range(100000)]; from collections import Counter'  'Counter(data)'
10 loops, best of 3: 54.9 msec per loop
$ py -m timeit -s 'from random import seed, randrange; seed(8675309); data=[randrange(500000) for i in range(100000)]; from collections import Counter'  'Counter(data)'
10 loops, best of 3: 80.8 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 10:34:56 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Sep 2013 08:34:56 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380530096.35.0.222668191617.issue19106@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I see two solutions, both involving to track the newest timestamp that needs to pass.
a) touch the file to have a time stamp in the future. make might complain, though.
b) sleep until a second has passed, then touch (actually, sleep of 100ms multiple times until the time stamp is new enough)

The key issue is that hg touch should use the same comparison as make. So if make thinks that something need to be done, hg touch should touch the files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 11:24:25 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 30 Sep 2013 09:24:25 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380533065.41.0.114893033304.issue18594@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Patch LGTM and seems to work well, according to your numbers.

Only minor nitpick would be that the method references could be decref-ed earlier, but that would complicate the code a bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 11:27:30 2013
From: report at bugs.python.org (koobs)
Date: Mon, 30 Sep 2013 09:27:30 +0000
Subject: [issue19133] Transient test failure: test_with_statement (test_ftplib)
Message-ID: <1380533250.94.0.739399137718.issue19133@psf.upfronthosting.co.za>


New submission from koobs:

Test failure observed on koobs-freebsd9 on default branch with changeset: 220b34cbd711c28938ea5d980636202c51ab1fbb

Subsequent forced rebuild succeeded with no failure.
 
======================================================================
FAIL: test_with_statement (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_ftplib.py", line 723, in test_with_statement
    self.assertEqual(self.server.handler_instance.last_received_cmd, 'quit')
AssertionError: 'noop' != 'quit'
- noop
+ quit

----------
components: Tests
messages: 198686
nosy: koobs
priority: normal
severity: normal
status: open
title: Transient test failure: test_with_statement (test_ftplib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19133>
_______________________________________

From report at bugs.python.org  Mon Sep 30 12:27:13 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 30 Sep 2013 10:27:13 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380520325.81.0.484241471973.issue19086@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxQgvQD5kazHXweWgT3LnDjAUDSPRMgfdfg4aQC=MhgdAQ@mail.gmail.com>


Oscar Benjamin added the comment:

I should be clearer about my intentions. I'm hoping to create an
efficient and accurate sum() function for the new stdlib statistics
module:
http://bugs.python.org/issue18606
http://www.python.org/dev/peps/pep-0450/

The sum() function currently proposed can be seen in this patch:
http://bugs.python.org/file31680/statistics_combined.patch

It uses Fractions to compute an exact sum and separately tries to keep
track of type coercion to convert the end result. It is accurate and
returns a result of the appropriate type for any mix of ints,
Fractions, Decimals and floats with the caveat that mixing Fractions
and Decimals is disallowed. I believe the most common use-cases will
be for ints/floats and for these cases it is 100x slower than
sum/fsum.

The discussion here:
http://bugs.python.org/issue18606#msg195630
resulted in the sum function that you can see in the above patch.
Following that I've had off-list discussions with the author of the
module about improving the speed of the sum function (which is a
bottleneck for half of the functions exposed by the module). He is
very much interested in speed optimisations but doesn't want to
compromise on accuracy.

My own interest is that I would like an efficient and accurate (for
all types) sum function *somewhere* in the stdlib. The addition of the
statistics module with its new sum() function is a good opportunity to
achieve this. If this were purely for myself I wouldn't bother this
much with speed optimisation since I've probably already spent more of
my own time thinking about this function than I ever would running it!
(If I did want to specifically speed this up in my own work I would,
as you say, use cython).

If fsum() were modified in the way that I describe that it would be
usable as a primitive for the statistics.sum() function and also for
parallel etc. computation. I agree that the carry argument is
unnecessary and that the main is just the exactness of the return
value: it seems a shame that fsum could so easily give me an exact
result but doesn't.

As for exposing the internals of fsum, is it not the case that a
*non-overlapping* set of floats having a given exact sum is a uniquely
defined set? For msum I believe it is only necessary to strip out
zeros in order to normalise the output so that it is uniquely defined
by the true value of the sum in question (the list is already in
ascending order once the zeros are removed).

Uniqueness: If a many-digit float is given by something like
(+-)abcdefghijkl * 2 ** x and we want to break it into non-overlapping
2-digit floats of the form ab*2**x. Since the first digit of each
2-digit float must be non-zero (consider denormals as a separate case)
the largest magnitude float is uniquely determined. Subtract that from
the many-digit total and then the next largest float is uniquely
determined and so on. There can be at most 1 denormal number in the
result and this is also uniquely determined once the larger numbers
are extracted. So the only way that the partials list can be
non-unique is by the inclusion of zeros (unless I've missed something
:).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Mon Sep 30 12:32:16 2013
From: report at bugs.python.org (gladman)
Date: Mon, 30 Sep 2013 10:32:16 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1380537136.24.0.192050348529.issue13674@psf.upfronthosting.co.za>


gladman added the comment:

On IDLE this:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> from datetime import datetime
>>> datetime(1878, 12, 31).strftime('%d %b %y')

causes a crash on Windows.  I am surprised that this bug still exists as it is not far off two years old now.

----------
nosy: +gladman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Mon Sep 30 12:57:10 2013
From: report at bugs.python.org (Mateusz Loskot)
Date: Mon, 30 Sep 2013 10:57:10 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1380538630.17.0.264161429683.issue17797@psf.upfronthosting.co.za>


Mateusz Loskot added the comment:

I have just tested Windows GUI application built against Python 3.2.1 with is_valid_fd patch according to http://hg.python.org/cpython/rev/f15943505db0/

All built using VS2012.

Again, I can confirm that is_valid_fd does NOT solve the problem.
Here is extract of execution flow in initstdio function:

1. fd = 0, despite it is GUI app, see https://connect.microsoft.com/VisualStudio/feedback/details/785119/

fd = fileno(stdin);

2. is_valid_fd will return __true__, so it moves to calling create_stdio()

if (!is_valid_fd(fd)) {
   ...
}
else {
   std = create_stdio(iomod, fd, 0, "<stdin>", encoding, errors);
   if (std == NULL)
       goto error;
}

3. The create_stdio() call fails though, causing error followed by abort


Still, the only solution that solves this problem in Windows GUI applications buitl using VS2012 is to use check_fd() function to check fd, instead of is_valid_fd(). The check_fd() is more reliable as it will return -1 due to errno == EBADF.

My previous attempt to analyse _PyVerify_fd() is not relevant for the problem, let's forget it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Mon Sep 30 13:08:28 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 30 Sep 2013 11:08:28 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1380488571.2.0.3843288381.issue12641@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxR8fkNBtzNpHnox6_JRPjT3oikTgEf58-gDUgZhsFOv8w@mail.gmail.com>


Oscar Benjamin added the comment:

Thanks for looking at this Antoine.

I've attached an updated patch for Python 2.7 called
check_mno_cywin_py27_2.patch. This explicitly closes the popen object
in the same way as the get_versions() function immediately above.

I've just signed an electronic contributor's agreement.

----------
Added file: http://bugs.python.org/file31919/check_mno_cywin_py27_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________
-------------- next part --------------
diff -r a7db9f505e88 Lib/distutils/cygwinccompiler.py
--- a/Lib/distutils/cygwinccompiler.py	Sun Jun 23 16:12:32 2013 -0400
+++ b/Lib/distutils/cygwinccompiler.py	Mon Sep 30 12:01:34 2013 +0100
@@ -319,13 +319,18 @@
         else:
             entry_point = ''
 
-        self.set_executables(compiler='gcc -mno-cygwin -O -Wall',
-                             compiler_so='gcc -mno-cygwin -mdll -O -Wall',
-                             compiler_cxx='g++ -mno-cygwin -O -Wall',
-                             linker_exe='gcc -mno-cygwin',
-                             linker_so='%s -mno-cygwin %s %s'
-                                        % (self.linker_dll, shared_option,
-                                           entry_point))
+        if self.gcc_version < '4' or is_cygwingcc():
+            no_cygwin = ' -mno-cygwin'
+        else:
+            no_cygwin = ''
+
+        self.set_executables(compiler='gcc%s -O -Wall' % no_cygwin,
+                             compiler_so='gcc%s -mdll -O -Wall' % no_cygwin,
+                             compiler_cxx='g++%s -O -Wall' % no_cygwin,
+                             linker_exe='gcc%s' % no_cygwin,
+                             linker_so='%s%s %s %s'
+                                    % (self.linker_dll, no_cygwin,
+                                       shared_option, entry_point))
         # Maybe we should also append -mthreads, but then the finished
         # dlls need another dll (mingwm10.dll see Mingw32 docs)
         # (-mthreads: Support thread-safe exception handling on `Mingw32')
@@ -447,3 +452,12 @@
     else:
         dllwrap_version = None
     return (gcc_version, ld_version, dllwrap_version)
+
+def is_cygwingcc():
+    '''Try to determine if the gcc that would be used is from cygwin.'''
+    out = os.popen('gcc -dumpmachine', 'r')
+    out_string = out.read()
+    out.close()
+    # out_string is the target triplet cpu-vendor-os
+    # Cygwin's gcc sets the os to 'cygwin'
+    return out_string.strip().endswith('cygwin')

From report at bugs.python.org  Mon Sep 30 13:13:30 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 30 Sep 2013 11:13:30 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <CAHVvXxR8fkNBtzNpHnox6_JRPjT3oikTgEf58-gDUgZhsFOv8w@mail.gmail.com>
Message-ID: <CAHVvXxRm_D85icozaffkE+=t-o-iP=NKBh-Z02ZJj3Ci95mWrw@mail.gmail.com>


Oscar Benjamin added the comment:

On 30 September 2013 12:08, Oscar Benjamin <report at bugs.python.org> wrote:
> I've attached an updated patch for Python 2.7 called
> check_mno_cywin_py27_2.patch.

To be clear: I retested this patch (using the setup described above)
and the results are unchanged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Sep 30 13:39:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Sep 2013 11:39:31 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1325149457.99.0.374098273588.issue13674@psf.upfronthosting.co.za>
Message-ID: <1380541171.51.0.0695425304229.issue13674@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I am surprised that this bug still exists as it is not far off two years old now.

You should report the bug to Microsoft who distributes a buggy C runtime library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Mon Sep 30 13:41:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Sep 2013 11:41:03 +0000
Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py
In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za>
Message-ID: <1380541263.81.0.153531472149.issue19119@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19119>
_______________________________________

From report at bugs.python.org  Mon Sep 30 14:08:07 2013
From: report at bugs.python.org (gladman)
Date: Mon, 30 Sep 2013 12:08:07 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <1380541171.51.0.0695425304229.issue13674@psf.upfronthosting.co.za>
Message-ID: <524969AC.3000707@gladman.plus.com>


gladman added the comment:

On 30/09/2013 12:39, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
>> I am surprised that this bug still exists as it is not far off two years old now.
> 
> You should report the bug to Microsoft who distributes a buggy C runtime library.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13674>
> _______________________________________
> 

Thank you for your suggestion.

But, given that this bug has been present for some two years, I would
hope that Python developers would have already done what you suggest and
this leads me to doubt that any approach that I made to Microsoft would
achieve any practical benefit.

In practice it is pretty well always necessary in building applications
on top of widely used compilers and libraries to have to workaround the
many bugs that they contain.

Since there is evidently no workaround for this issue in the Python
3.3.2 code, I have to assume that one is not considered to be
necessary, presumably because Microsoft has fixed (or intends to fix)
this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Mon Sep 30 14:14:16 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 30 Sep 2013 12:14:16 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <524969AC.3000707@gladman.plus.com>
Message-ID: <52496B15.3040102@timgolden.me.uk>


Tim Golden added the comment:

In reality (as I'm sure you can guess) it's just that no-one's got to
the point of fixing it. I did start off, but it's not a trivial fix and
clearly it got sidelined (with no-one shouting). Sometimes that's just
the way it is.

I'll see if I can dig out whatever code I had managed to change. I'm
certainly happy to review and apply a patch if someone wants to supply one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Mon Sep 30 15:33:37 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Sep 2013 13:33:37 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380548017.47.0.785819265683.issue19106@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Here is a patch that backdates outputs 1s after their youngest input (and sleeps if necessary to avoid producing files in the future).

With that, I get

lap-le:3k loewis$ touch Parser/asdl_c.py ;date;make touch;date
Mo 30 Sep 2013 15:29:21 CEST
hg --config extensions.touch=Tools/hg/hgtouch.py touch -v
Touching Include/Python-ast.h
Touching Python/Python-ast.c
Mo 30 Sep 2013 15:29:23 CEST
lap-le:3k loewis$ ls -lT Parser/asdl_c.py Include/Python-ast.h Python/Python-ast.c
-rw-r--r--  1 loewis  admin   19489 30 Sep 15:29:22 2013 Include/Python-ast.h
-rwxr-xr-x  1 loewis  admin   43732 30 Sep 15:29:21 2013 Parser/asdl_c.py
-rw-r--r--  1 loewis  admin  228785 30 Sep 15:29:23 2013 Python/Python-ast.c

BTW, I think the Python-ast.c issue could be solved by just having Python-ast.c depend on the same inputs as Python-ast.h; the C file isn't actually depending on the H file.

----------
keywords: +patch
Added file: http://bugs.python.org/file31920/touch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 15:45:19 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 30 Sep 2013 13:45:19 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380548719.44.0.817676575791.issue19106@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:10:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Sep 2013 14:10:21 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <3cpQVh4GW1zQLQ@mail.python.org>


Roundup Robot added the comment:

New changeset 477246839224 by Martin v. L?wis in branch '3.3':
Issue #19106: Touch generated files to be 1s newer than their youngest source.
http://hg.python.org/cpython/rev/477246839224

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:15:42 2013
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 30 Sep 2013 14:15:42 +0000
Subject: [issue19134] test_inspect.py failed if module _multiprocessing not
 available
Message-ID: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>


New submission from Remi Pointel:

When I run the regress tests on OpenBSD 5.4-current, the test test_inspect.py failed because the module _multiprocessing is not available, instead of skipping the test:

FAILED (errors=1)
Traceback (most recent call last):
  File "./Lib/test/test_inspect.py", line 2453, in <module>
    test_main()
  File "./Lib/test/test_inspect.py", line 2449, in test_main
    TestBoundArguments, TestGetClosureVars, TestUnwrap, TestMain
  File "/tmp/Python-3.4.0a3/Lib/test/support/__init__.py", line 1696, in run_unittest
    _run_suite(suite)
  File "/tmp/Python-3.4.0a3/Lib/test/support/__init__.py", line 1671, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_inspect.py", line 2411, in test_qualname_source
    module = importlib.import_module('concurrent.futures')
  File "/tmp/Python-3.4.0a3/Lib/importlib/__init__.py", line 95, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1613, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1594, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1561, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 607, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1056, in load_module
  File "<frozen importlib._bootstrap>", line 926, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _call_with_frames_removed
  File "/tmp/Python-3.4.0a3/Lib/concurrent/futures/__init__.py", line 17, in <module>
    from concurrent.futures.process import ProcessPoolExecutor
  File "/tmp/Python-3.4.0a3/Lib/concurrent/futures/process.py", line 53, in <module>
    from multiprocessing.queues import SimpleQueue, Full
  File "/tmp/Python-3.4.0a3/Lib/multiprocessing/queues.py", line 22, in <module>
    import _multiprocessing
ImportError: No module named '_multiprocessing'


Diff to skip test_qualname_source if _multiprocessing is not available is attached. Is it ok?

Remi.

----------
components: Tests
files: Lib_test_test_inspect_py.diff
keywords: patch
messages: 198698
nosy: rpointel
priority: normal
severity: normal
status: open
title: test_inspect.py failed if module _multiprocessing not available
versions: Python 3.4
Added file: http://bugs.python.org/file31921/Lib_test_test_inspect_py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19134>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:22:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Sep 2013 14:22:21 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <3cpQmX5jVRz7LkG@mail.python.org>


Roundup Robot added the comment:

New changeset 86eff5c4e698 by Martin v. L?wis in branch '3.3':
Issue #19106: Add buildbottouch target.
http://hg.python.org/cpython/rev/86eff5c4e698

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:24:00 2013
From: report at bugs.python.org (gladman)
Date: Mon, 30 Sep 2013 14:24:00 +0000
Subject: [issue13674] crash in datetime.strftime
In-Reply-To: <52496B15.3040102@timgolden.me.uk>
Message-ID: <52498984.1080600@gladman.plus.com>


gladman added the comment:

On 30/09/2013 13:14, Tim Golden wrote:
> 
> Tim Golden added the comment:
> 
> In reality (as I'm sure you can guess) it's just that no-one's got to
> the point of fixing it. I did start off, but it's not a trivial fix and
> clearly it got sidelined (with no-one shouting). Sometimes that's just
> the way it is.
> 
> I'll see if I can dig out whatever code I had managed to change. I'm
> certainly happy to review and apply a patch if someone wants to supply one.

Thank you for your comment Tim.

To be honest, Python is just so reliable that I was genuinely very
surprised to find something that actually crashes it :-)

It's hardly a priority but I thought it might be worth a comment in case
it was a bug that had simply been forgotten about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13674>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:28:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Sep 2013 14:28:56 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1380551336.5.0.789489179533.issue18857@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, Senthil is correct.

My original liking for this idea came from my mistaken impression that a value without an '=' was different from a value with an '='.  But clearly the practice in the industry (the de facto standard) is that they are the same, and indicate that the value of the parameter is the empty string.

So, urls do *not* have any way of representing a null value (as differentiated from an empty string).  All url values are strings.  This means that the correct value to use for a python value is always its string representation, which in the case of None is "None", just as the correct representation of a Python boolean value is "True" or "False" (since http also does not have any specifically boolean type, only string values).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:48:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Sep 2013 14:48:19 +0000
Subject: [issue19132] Add compact mode to pprint
In-Reply-To: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>
Message-ID: <1380552499.29.0.337523645901.issue19132@psf.upfronthosting.co.za>


R. David Murray added the comment:

I like it.  If it isn't too difficult, I'd suggest that compact mode also indent the string continuation lines:

['one string', 'other string',
 'very very long string which is continued on '
  'several lines',
 'and again', 'and again', 'and again',
 'and again']

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:49:38 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Sep 2013 14:49:38 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380552578.97.0.921856519213.issue19106@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I have now updated the master.cfg to make buildbottouch a separate build step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:53:01 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Sep 2013 14:53:01 +0000
Subject: [issue19134] test_inspect.py failed if module _multiprocessing not
 available
In-Reply-To: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>
Message-ID: <1380552781.68.0.687668430433.issue19134@psf.upfronthosting.co.za>


Brett Cannon added the comment:

test.support.import_module is typically meant for global imports as function-level imports are discouraged in general. I would instead use the unittest.skipIf decorator::

  @unittest.skipIf(not test.support.multiprocessing, "multiprocessing required") 
  def test_qualname_source(self):
    ...

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19134>
_______________________________________

From report at bugs.python.org  Mon Sep 30 16:59:16 2013
From: report at bugs.python.org (Joshua Johnston)
Date: Mon, 30 Sep 2013 14:59:16 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1380553156.27.0.223290978267.issue18857@psf.upfronthosting.co.za>


Joshua Johnston added the comment:

I agree with True == 'True' and False == 'False' but None should be empty since it represents the absence of a value akin to null, Nil, etc in other languages. Ultimately it is not my decision make so I can only agree to disagree.

Thanks for having this discussion with me. So far the python community has been a pleasant change from what I am used to!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 30 17:12:13 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Sep 2013 15:12:13 +0000
Subject: [issue18857] urlencode of a None value uses the string 'None'
In-Reply-To: <1377633255.35.0.29938622913.issue18857@psf.upfronthosting.co.za>
Message-ID: <1380553933.24.0.902934185857.issue18857@psf.upfronthosting.co.za>


R. David Murray added the comment:

If we were making this decision de novo, we might decide it that way.  However, the current behavior has been in place for a long time, so backward compatibility concerns raise the bar high enough that the costs of the change outweigh any benefits, even if we got general agreement that there was a benefit :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18857>
_______________________________________

From report at bugs.python.org  Mon Sep 30 17:23:47 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 30 Sep 2013 15:23:47 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380554627.78.0.0666370937072.issue19106@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

With your fix, `make touch` now behaves as expected. Also, I can see the step added to the bots (e.g. http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/2597/steps/shell/logs/stdio)

Thanks, I think the issue is resolved then. We should now be able to have modern Python code in scripts that generate code such as asdl[_c].py because bots and people will only old versions of Python don't ever need to run them.

Should we add a note about this to the dev guide?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 17:29:25 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 30 Sep 2013 15:29:25 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <1380554965.52.0.47753843067.issue19099@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here's the preliminary patch. I am assuming that we should accept unicode argument not reject it straight away.

Python3 does that.
>>> import struct
>>> struct.pack('b', 3)
b'\x03'
>>> struct.pack(b'b', 3)
b'\x03'
>>> struct.pack(b'\xff', 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: bad char in struct format

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31922/handle_ascii_range_unicode_in_struct_pack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Mon Sep 30 17:44:53 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 30 Sep 2013 15:44:53 +0000
Subject: [issue19106] Prepare .hgtouch and Tools/hg/hgtouch.py to run on the
 bots
In-Reply-To: <1380295557.39.0.230281055925.issue19106@psf.upfronthosting.co.za>
Message-ID: <1380555893.63.0.405271631042.issue19106@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

"make touch" (or "hg touch") certainly should be mentioned. Details of the buildbot configuration need not.

Publishing the buildbot configuration file might be useful, except that it also contains all the builder passwords, which should not be published. If that is done, it should be the "life" configuration file (rather than a static copy created now). It might be easiest to publish it through a symlink on buildbot.python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19106>
_______________________________________

From report at bugs.python.org  Mon Sep 30 18:43:21 2013
From: report at bugs.python.org (Xavier Combelle)
Date: Mon, 30 Sep 2013 16:43:21 +0000
Subject: [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1380559401.41.0.197504463358.issue19024@psf.upfronthosting.co.za>


Changes by Xavier Combelle <xavier.combelle at gmail.com>:


----------
nosy: +xcombelle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19024>
_______________________________________

From report at bugs.python.org  Mon Sep 30 19:33:11 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Mon, 30 Sep 2013 17:33:11 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1380562391.59.0.514349150875.issue16041@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Added a test for SSL, if SSL is available

----------
Added file: http://bugs.python.org/file31923/issue16041_py26_with_ssl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:07:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 18:07:15 +0000
Subject: [issue19132] Add compact mode to pprint
In-Reply-To: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>
Message-ID: <1380564435.04.0.427270990768.issue19132@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. Please review and correct the documentation.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file31924/pprint_compact.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:07:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 18:07:16 +0000
Subject: [issue18594] C accelerator for collections.Counter is slow
In-Reply-To: <1375166960.42.0.521563124847.issue18594@psf.upfronthosting.co.za>
Message-ID: <1380564436.41.0.687817728239.issue18594@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Benchmarking results look great.

But isn't _PyObject_LookupSpecial() more appropriate function for special methods lookup than PyObject_GetAttrString()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18594>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:09:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 18:09:10 +0000
Subject: [issue19132] Add compact mode to pprint
In-Reply-To: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>
Message-ID: <1380564550.74.0.919024400066.issue19132@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I'd suggest that compact mode also indent the string continuation lines:

Please open new issue for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:23:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 18:23:39 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <1380565419.08.0.486335978596.issue19099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Struct constructor accepts only str and not unicode. But struct.pack() uses caching and it found Struct('B') in the cache (because u'B' and 'B' are equal and have same hash).

I doubt we should fix this. Adding support of Unicode argument is new feature.

----------
nosy: +mark.dickinson, meador.inge, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:25:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 18:25:37 +0000
Subject: [issue19133] Transient test failure: test_with_statement (test_ftplib)
In-Reply-To: <1380533250.94.0.739399137718.issue19133@psf.upfronthosting.co.za>
Message-ID: <1380565537.64.0.615562008907.issue19133@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +giampaolo.rodola
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19133>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:33:58 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 30 Sep 2013 18:33:58 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>
Message-ID: <1380566038.44.0.467218135144.issue19086@psf.upfronthosting.co.za>


Tim Peters added the comment:

The possible use cases are so varied & fuzzy it seems better to use an object for this, rather than funk-ify `fsum`.  Say, class Summer.  Then methods could be invented as needed, with whatever state is required belonging to Summer objects rather than passed around in funky calling-sequence/return conventions.  Like,

s = Summer() # new object
s.add(3.1)   # add one number to running sum
s.sum()      # returns sum so far as float: 3.1
s.update(iterable_returning_numbers)  # add a bunch of numbers to sum
s.combine(another_Summer_object)  # add Summer's
s.sum_as_decimal(precision=None) # sum so far as Decimal
s.sum_as_fraction()  # exact sum so far as Fraction

Blah blah blah ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:40:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 18:40:39 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <1380566439.64.0.124979110907.issue19099@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Either way, the runtime inconsistency is a bug. Since we shouldn't break existing code, I would vote for always allowing unicode format strings, rather than always disallowing them.

Another argument is that str and unicode are generally substituible in 2.x when they are pure ASCII (which they are here).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Mon Sep 30 20:51:08 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Sep 2013 18:51:08 +0000
Subject: [issue19132] Add compact mode to pprint
In-Reply-To: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>
Message-ID: <1380567068.45.0.979925518584.issue19132@psf.upfronthosting.co.za>


R. David Murray added the comment:

As noted in the review, I'm not as keen on having dictionaries displayed in compact form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:00:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 19:00:32 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380567632.52.0.561385658366.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I'm not sure that it is what you expected: bytearray() is only initialized once ("setup" of timeit). You probably want to reinitialize at each loop.

There is no "setup" of timeit here. And you forgot bytes(b) after accumulating loop. bench_bytearray.py shows me 10% slowdown for 10**3 and 10**5 bytes tests.

Of course it can be a measurement glitch. On other hand, there are no measurements which show positive effect of the patch for real code. Currently we consider only hypothetic code and can't compare it with alternatives.

> The problem is the "suboptimal code" is also the natural way to write such code. If you know a simple and idiomatic way to write an optimal bytes FIFO, then please share it with us.

Please share this written in the "natural way" real code with us. I can't compare with alternatives a code which I don't see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:11:16 2013
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 30 Sep 2013 19:11:16 +0000
Subject: [issue19134] test_inspect.py failed if module _multiprocessing not
 available
In-Reply-To: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>
Message-ID: <1380568276.86.0.259842825797.issue19134@psf.upfronthosting.co.za>


Remi Pointel added the comment:

Yes, but it needs an import to use test.support.multiprocessing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19134>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:21:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Sep 2013 19:21:20 +0000
Subject: [issue19134] test_inspect.py failed if module _multiprocessing not
 available
In-Reply-To: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>
Message-ID: <3cpYPW3DPMz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset d7ba4ca59023 by Brett Cannon in branch 'default':
Issue #19134: Make a test in inspect conditional on multiprocessing
http://hg.python.org/cpython/rev/d7ba4ca59023

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19134>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:23:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Sep 2013 19:23:33 +0000
Subject: [issue19134] test_inspect.py failed if module _multiprocessing not
 available
In-Reply-To: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>
Message-ID: <1380569013.06.0.374963511233.issue19134@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The import doesn't matter for test.support.multiprocessing as it is conditional thanks to the try/except. If that fails then the skipIf will be triggered and nothing will be executed. If the import succeeds in test.support then the importlib.import_module() call will succeed without issue. The point is that it is much more obvious why the test may get skipped from reading the code rather than looking at the function name.

----------
assignee:  -> brett.cannon
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19134>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:33:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 19:33:57 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380567632.52.0.561385658366.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380569635.2508.23.camel@fsol>


Antoine Pitrou added the comment:

> > The problem is the "suboptimal code" is also the natural way to
> write such code. If you know a simple and idiomatic way to write an
> optimal bytes FIFO, then please share it with us.
> 
> Please share this written in the "natural way" real code with us. I
> can't compare with alternatives a code which I don't see.

I'm sorry, I don't want to spend more time on such a minor issue.  The
patch is simple and yields good benefits, and Victor seems to have
approved it, so I'm inclined to ignore your skepticism and commit.

I would have liked more constructive criticism (perhaps the patch is
inefficient or suboptimal, etc.), but it seems I'll have to do without
it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:42:45 2013
From: report at bugs.python.org (Remi Pointel)
Date: Mon, 30 Sep 2013 19:42:45 +0000
Subject: [issue19134] test_inspect.py failed if module _multiprocessing not
 available
In-Reply-To: <1380550542.93.0.175157800121.issue19134@psf.upfronthosting.co.za>
Message-ID: <1380570165.07.0.928911318359.issue19134@psf.upfronthosting.co.za>


Remi Pointel added the comment:

Thanks :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19134>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:55:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 19:55:08 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380570908.11.0.816267165997.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't understand why you avoid to show any examples which benefit. Shouldn't optimizing patches prove their efficient?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:55:36 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Sep 2013 19:55:36 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380105970.25.0.603787186965.issue19086@psf.upfronthosting.co.za>
Message-ID: <1380570936.2.0.348587876099.issue19086@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Let's close this one.  As Uncle Timmy says, it would be a mistake to "funkify" the signature for math.fsum.

If something like a Summer() class is born, it should start it life outside the standard library, gain a following, and let both the API and implementation mature.

I'm sympathic about the loss of information in the final step of math.fsum() but don't think the standard library is the place for this to be born.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:56:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 19:56:06 +0000
Subject: [issue19132] Add compact mode to pprint
In-Reply-To: <1380485149.97.0.648520685176.issue19132@psf.upfronthosting.co.za>
Message-ID: <1380570966.44.0.746425835812.issue19132@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses David's comments. Thank you David.

> As noted in the review, I'm not as keen on having dictionaries displayed in compact form.

This makes sense. If no one will argue for compactifying mappings I'll remove this part of the patch.

----------
Added file: http://bugs.python.org/file31925/pprint_compact_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19132>
_______________________________________

From report at bugs.python.org  Mon Sep 30 21:58:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Sep 2013 19:58:47 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <3cpZDk1FPVz7Lk5@mail.python.org>


Roundup Robot added the comment:

New changeset 7214e3324a45 by Barry Warsaw in branch '2.6':
- Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
http://hg.python.org/cpython/rev/7214e3324a45

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:00:03 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 30 Sep 2013 20:00:03 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1380571203.42.0.770417646908.issue16041@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:04:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 20:04:47 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380570908.11.0.816267165997.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380571485.2508.26.camel@fsol>


Antoine Pitrou added the comment:

> I don't understand why you avoid to show any examples which benefit.
> Shouldn't optimizing patches prove their efficient?

Many micro-optimizations get committed without proving themselves on a
high-level benchmark suite, as long as they produce a big enough
difference on micro-benchmarks. I think you have noticed that!

A 4x improvement on a micro-benchmark is very likely to make a
difference in at least some real-world code (while a 10% improvement
wouldn't).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:06:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 20:06:59 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1380571619.88.0.247816274479.issue12641@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: eric.araujo -> pitrou
stage:  -> commit review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:16:22 2013
From: report at bugs.python.org (Oscar Benjamin)
Date: Mon, 30 Sep 2013 20:16:22 +0000
Subject: [issue19086] Make fsum usable incrementally.
In-Reply-To: <1380570936.2.0.348587876099.issue19086@psf.upfronthosting.co.za>
Message-ID: <CAHVvXxT6oPUvFttha+QT3ZmY+EUTRvVZNL=cHFW2v6rP=Z72nw@mail.gmail.com>


Oscar Benjamin added the comment:

Fair enough.

Thanks again for taking the time to look at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19086>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:18:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 20:18:39 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380572319.35.0.744383379315.issue19087@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

However, the patch had a bug in the resizing logic. Here is a new patch fixing that (+ an additional test).

----------
Added file: http://bugs.python.org/file31926/bytea_slice2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:22:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 20:22:15 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380572535.88.0.151480383002.issue19087@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Other benchmarks for the new patch (exercising FIFO-like behaviour: some data is appended at one end, and popped at the other):

timeit -s "b=bytearray(100000);s=b'x'*100" "b[:100] = b''; b.extend(s)"
-> before: 4.07 usec per loop
-> after: 0.812 usec per loop

For comparison, popping from the end (LIFO-like):

timeit -s "b=bytearray(100000);s=b'x'*100" "b[-100:] = b''; b.extend(s)"
-> before: 0.894 usec per loop
-> after: 0.819 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:25:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Sep 2013 20:25:23 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <3cpZqQ5Y5Kz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 7d9a1aa8d95e by Antoine Pitrou in branch '2.7':
Issue #12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary.
http://hg.python.org/cpython/rev/7d9a1aa8d95e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:29:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Sep 2013 20:29:57 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <3cpZwh6tP5z7LkV@mail.python.org>


Roundup Robot added the comment:

New changeset 6b89176f1be5 by Antoine Pitrou in branch '3.3':
Issue #12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary.
http://hg.python.org/cpython/rev/6b89176f1be5

New changeset 8e180b2067e4 by Antoine Pitrou in branch 'default':
Issue #12641: Avoid passing "-mno-cygwin" to the mingw32 compiler, except when necessary.
http://hg.python.org/cpython/rev/8e180b2067e4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:30:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 20:30:31 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1380573031.67.0.772345108207.issue12641@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you Oscar! This issue can endly be fixed.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:31:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 30 Sep 2013 20:31:34 +0000
Subject: [issue18674] Store weak references in modules_by_index
In-Reply-To: <1375821531.36.0.318072139637.issue18674@psf.upfronthosting.co.za>
Message-ID: <1380573094.76.0.385954459569.issue18674@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, rejecting my own patch because of compatibility issues.

----------
resolution:  -> wont fix
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18674>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:37:07 2013
From: report at bugs.python.org (Dwayne Litzenberger)
Date: Mon, 30 Sep 2013 20:37:07 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1380573427.94.0.22305063848.issue16500@psf.upfronthosting.co.za>


Changes by Dwayne Litzenberger <dlitz at dlitz.net>:


----------
nosy: +DLitz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:40:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Sep 2013 20:40:36 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380573636.17.0.0111207067643.issue19087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> A 4x improvement on a micro-benchmark is very likely to make a
difference in at least some real-world code (while a 10% improvement
wouldn't).

If there is a code that uses the deleting from the beginning of a bytearray. I just pray to demonstrate this code. Perhaps you only intend to write a code that will use it. Wonderful. I want to look at it and make sure that the same problem can not be solved just as effective in another way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:41:49 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Sep 2013 20:41:49 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1380573709.48.0.498860125648.issue16041@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> New changeset 7214e3324a45 by Barry Warsaw in branch '2.6':
> - Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
> http://hg.python.org/cpython/rev/7214e3324a45
> ...
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> ...
> +- Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
> +  prevent readline() calls from consuming too much member.

Maybe s/member/memory/ ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Mon Sep 30 22:47:27 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 30 Sep 2013 20:47:27 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1380573709.48.0.498860125648.issue16041@psf.upfronthosting.co.za>
Message-ID: <20130930164726.138cada3@anarchist>


Barry A. Warsaw added the comment:

On Sep 30, 2013, at 08:41 PM, Arfrever Frehtes Taifersar Arahesis wrote:

>
>Arfrever Frehtes Taifersar Arahesis added the comment:
>
>> New changeset 7214e3324a45 by Barry Warsaw in branch '2.6':
>> - Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
>> http://hg.python.org/cpython/rev/7214e3324a45
>> ...
>> --- a/Misc/NEWS
>> +++ b/Misc/NEWS
>> ...
>> +- Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
>> +  prevent readline() calls from consuming too much member.
>
>Maybe s/member/memory/ ?

Good catch, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Mon Sep 30 23:02:23 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Mon, 30 Sep 2013 21:02:23 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1380574943.53.0.0828336253205.issue16040@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Regarding the implementation: all commands (even those returning multiple lines), use the same readline method.

I've attached a patch for 2.6, working on the 2.7+ too.

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file31927/issue16040_py26.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Mon Sep 30 23:07:44 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 30 Sep 2013 21:07:44 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1380575264.33.0.779013310454.issue16040@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Looks great, thanks!  I'll apply this to 2.6.9 but let others forward port it to 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Mon Sep 30 23:12:58 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Mon, 30 Sep 2013 21:12:58 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1380575578.57.0.440759658367.issue16040@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

The patch for 2.6 applies cleanly on 2.7 too and the tests pass there

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Mon Sep 30 23:43:48 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Mon, 30 Sep 2013 21:43:48 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1380577428.9.0.315939703111.issue16040@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Did a slight change to the patch, making the too long line to look like a valid line so that it does not raise a NNTPProtocolError otherwise. Thanks to Barry for catching this :)

I also wonder if there should be data error risen instead? Current docstrings of the errors are not that well fit.

----------
Added file: http://bugs.python.org/file31928/issue16040_py26_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Mon Sep 30 23:44:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Sep 2013 21:44:13 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380577453.08.0.227099502329.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I took me some time, but Antoine explained me the use case on IRC :-) The patch is useful is the bytearray is used as a FIFO: remove front, append tail. It can be seen as an implementation for BufferedReader. Consumer/producer is a common pattern, especially consuming one end (front) and produce at the other end (tail).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________

From report at bugs.python.org  Mon Sep 30 23:49:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Sep 2013 21:49:07 +0000
Subject: [issue19087] bytearray front-slicing not optimized
In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za>
Message-ID: <1380577747.06.0.730302634436.issue19087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I adapted my micro-benchmark to measure the speedup: bench_bytearray2.py. Result on  bytea_slice2.patch:

Common platform:
CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Platform: Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow
Python unicode implementation: PEP 393
Timer: time.perf_counter
Bits: int=32, long=64, long long=64, size_t=64, void*=64
Timer precision: 40 ns

Platform of campaign original:
Date: 2013-09-30 23:39:31
Python version: 3.4.0a2+ (default:687dd81cee3b, Sep 30 2013, 23:39:27) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)]
SCM: hg revision=687dd81cee3b tag=tip branch=default date="2013-09-29 22:18 +0200"

Platform of campaign patched:
Date: 2013-09-30 23:38:55
Python version: 3.4.0a2+ (default:687dd81cee3b+, Sep 30 2013, 23:30:35) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)]
SCM: hg revision=687dd81cee3b+ tag=tip branch=default date="2013-09-29 22:18 +0200"

------------------------+-------------+------------
non regression          |    original |     patched
------------------------+-------------+------------
concatenate 10**1 bytes |  1.1 us (*) |     1.14 us
concatenate 10**3 bytes |     46.9 us | 46.8 us (*)
concatenate 10**5 bytes | 4.66 ms (*) |     4.71 ms
concatenate 10**7 bytes |  478 ms (*) |      483 ms
------------------------+-------------+------------
Total                   |  482 ms (*) |      488 ms
------------------------+-------------+------------

----------------------------+-------------------+-------------
deleting front, append tail |          original |      patched
----------------------------+-------------------+-------------
buffer 10**1 bytes          |        639 ns (*) | 689 ns (+8%)
buffer 10**3 bytes          |        682 ns (*) | 723 ns (+6%)
buffer 10**5 bytes          |   3.54 us (+428%) |   671 ns (*)
buffer 10**7 bytes          | 900 us (+107128%) |   840 ns (*)
----------------------------+-------------------+-------------
Total                       |  905 us (+30877%) |  2.92 us (*)
----------------------------+-------------------+-------------

----------------------------+------------------+------------
Summary                     |         original |     patched
----------------------------+------------------+------------
non regression              |       482 ms (*) |      488 ms
deleting front, append tail | 905 us (+30877%) | 2.92 us (*)
----------------------------+------------------+------------
Total                       |       483 ms (*) |      488 ms
----------------------------+------------------+------------

@Serhiy: I see "zero" difference in the append loop micro-benchmark. I added the final cast to bytes()

@Antoine: Your patch rocks, 30x faster! (I don't care of the 8% slowdown in the nanosecond timing).

----------
Added file: http://bugs.python.org/file31929/bench_bytearray2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19087>
_______________________________________